什么是缓存雪崩
平常的时候我们缓存层承载大量请求做到保护数据层但是
当你redis 里面的key值大量过期（比方说我双十二的时候马上开始秒杀了我设置过期时间为1小时 那么一小时之后这些商品的信息是不是集体失效了）同时此时有大量请求直接访问到redis的时候此时缓存面是没有的，这些请求会直接并发请求到数据库 此时数据库可能会因为压力过大而崩掉这就是缓存雪崩
解决思路：
- 限流降级当大量请求直接访问我的时候我只让一个请求过去数据库查询，将查询到的数据放入redis
- 缓存预热可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间（比方说你卖的好的产品我的过期时间设置的长一点买的一般的我设计的短一点），让缓存失效的时间点尽量均匀。
缓存穿透
什么是缓存穿透 我们来想我们的正常流程，当我们前台发送一个请求的时候你通过redis缓存层来降低数据库的压力此时若是请求一个值你在redis中没有呢你是不是该去数据库查询了，这个时候有一些恶意攻击的人会通过穷举法去找到你redis里面没有缓存的数据 大量请求直接压到你的数据库 但是数据库也没有你要数据此时数据库压力是不是非常大 （它疯狂去找但就是找不到然后你又大量去请求数据库直接累死了）这就是缓存穿透
- 解决思路 我们可以通过布隆过滤器来解决
当你数据库没有一个数据的时候（就像你查订单号 若我没有这个订单号我给他一个状态为1 否则为0）
此时你请求到我的redis 访问一个数据我一看状态为0 代表我的数据库也没有我是不是可以直接驳回你的请求告诉你没有这一条数据呢
- 或者直接简单粗暴一点我若是没有查到数据直接返回一个null 存入redis 设置一个短一点的过期时间比方说60秒 这样你下一次来查的时候我直接告诉你这个是null
缓存击穿
什么是缓存击穿 就是一个热点key 在过期的时候被大量访问就像直接击穿了保护罩
解决方式：
- 你热点数据我是不是可以将他设置为不过期 简单粗暴 或者你设定一个定时的任务 你的这个建在30分钟之内过期我设置定时任务 在29分钟的时候更新你这个健 这个就是比较局限性若是key值比较固定还是有可行性
- 将缓存key的过期时间(绝对时间)一起保存到缓存中(可以拼接,可以添加新字段,可以采用单独的key保存…不管用什么方式,只要两者建立好关联关系就行).在每次执行get操作后,都将get出来的缓存过期时间与当前系统时间做一个对比,如果缓存过期时间-当前系统时间<=1分钟(自定义的一个值),则主动更新缓存.这样就能保证缓存中的数据始终是最新的(和方案一一样,让数据不过期.)，但是若是有极端的情况，就是你缓存马上过期了 ，此时就是没有请求过来你没办法调用get 然后更新缓存等你时间一过， key过期了，马上来一波高并发你直接完蛋
- 使用锁来实现
//创建一个锁
static Lock reenLock = new ReentrantLock();
public List<String> getData04() throws InterruptedException {
List<String> result = new ArrayList<String>();
// 从缓存读取数据
result = getDataFromCache();
//判断若是没有数据
if (result.isEmpty()) {
//判断是否获取到锁
if (reenLock.tryLock()) {
try {
System.out.println("我拿到锁了,从DB获取数据库后写入缓存");
// 从数据库查询数据
result = getDataFromDB();
// 将查询到的数据写入缓存
setDataToCache(result);
} finally {
reenLock.unlock();// 释放锁
}
} else {
result = getDataFromCache();// 先查一下缓存
if (result.isEmpty()) {
System.out.println("我没拿到锁,缓存也没数据,先小憩一下");
Thread.sleep(100);// 小憩一会儿
return getData04();// 再来一此
}
}
}
return result;
}
redis 持久化策略
-
RDB（数据快照模式），定期存储，保存的是数据本身，存储文件是紧凑的
-
AOF（追加模式），每次修改数据时，同步到硬盘(写操作日志)，保存的是数据的变更记录
-
如果只希望数据保存在内存中的话，俩种策略都可以关闭
-
也可以同时开启俩种策略，当Redis重启时，AOF文件会用于重建原始数据
RDB定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中恢复数据集。
优点
- 存储的文件是紧凑的
- 适合用于备份，方便恢复不同版本的数据
- 适合于容灾恢复，备份文件可以在其他服务器恢复
- 最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作 save 是让当前的线程进行快照保存 若是文件过大会阻塞线程（redis 是单线程的 用户体验性能不好 所以使用bgsave 会通过fork创建一个子线程自己慢慢搞阻塞线程微秒级）
- 数据保存比AOF要快
缺点
1如果Redis因为没有正确关闭而停止工作是，到上个保存点之间的数据将会丢失
2 由于需要经常fork子线程来进行备份操作，如果数据量很大的话，fork比较耗时，如果cpu性能不够，服务器可能是卡顿。属于数据量大的时候，一个服务器不要部署多个Redis服务。
创建快照有以下5种形式：
- 客户端发送BGSAVE指令，服务端会fork一条子线程将快照写入磁盘
- 客户端发送SAVE指令，服务端在主线程进行写入动作。一般不常使用，一般在内存不够去执行BGSVAE的时候才用
- 设置了SAVE配置项，如SAVE 300 100，那么当“300秒内有100次写入”时，Redus会自动触发BGSAVE命令。如果有多个配置项，任意一个满足，都会触发备份
- Redis通过SHUTDOWN(关机)命令接收到关闭服务器的请求、或者TERM信号时，会执行SAVE命令，这时候会阻塞所有客户端，不在执行客户端发送的任何命令
- 当一个Redis服务器连接另外一个Redis服务器，并像对方发送SYNC（同步）命令开始一次复制操作时，如果主服务器目前没有在执行BGSAVE操作，或者主服务器刚刚执行完，那么主服务器就会执行GBSAVE
AOF(append only file)
AOF记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行一遍，从而实现数据备份。当写操作集过大（比原有的数据集还大），Redis 会重写写操作集。
优点
- 使用AOF模式更加的灵活，因为可以有不同的fsync策略
- AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复
- 当AOF文件很大的，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作
- AOF包含一个又一个的操作命令，易于理解和解析
缺点
对于同样的数据集，AOF文件通常要大于RDB文件
AOF可能比RDB要慢，这取决于fsync策略。通常fsync(同步策略)设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
AOF1通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份）
Redis支持的数据类型？
String字符串：
格式: set key value
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
string类型是Redis最基本的数据类型，一个键最大能存储512MB。
Hash（哈希）
格式: hmset name key1 value1 key2 value2
Redis hash 是一个键值(key=>value)对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）
格式: lpush name value
在 key 对应 list 的头部添加字符串元素
格式: rpush name value
在 key 对应 list 的尾部添加字符串元素
格式: lrem name index
key 对应 list 中删除 count 个和 value 相同的元素
格式: llen name
返回 key 对应 list 的长度
Set（集合）
格式: sadd name value
Redis的Set是string类型的无序集合。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
zset(sorted set：有序集合)
格式: zadd name score value
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zset的成员是唯一的,但分数(score)却可以重复。
Redis 集群
从redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。
特点：
1、无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。
2、数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。
3、可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。
4、高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本
5、实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master 的角色提升。
缺点：
1、资源隔离性较差，容易出现相互影响的情况。
2、数据通过异步复制,不保证数据的强一致性
使用过Redis分布式锁实现
先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。
如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？
set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！
使用过Redis做异步队列么，你是怎么用的？有什么缺点？
一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。
缺点：
在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。
能不能生产一次消费多次呢？
使用pub/sub主题订阅者模式，可以实现1:N的消息队列。
