Redis缓存三兄弟（穿透、击穿、雪崩）

1 缓存穿透

缓存穿透：查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库

解决方案一：

缓存空数据，查询返回的数据为空，仍把这个空结果进行缓存

 {key:1,value:null}

例：一个get请求：api/blog/getById/1

优点：简单缺点：消耗内存，可能会发生不一致的问题

解决方案二：布隆过滤器

布隆过滤器是一种高效的数据结构，用于判断某个元素是否存在于集合中。可以将可能的查询键预先加载到布隆过滤器中，在查询缓存之前先通过布隆过滤器进行快速判断，从而避免无效的查询请求。

例：一个get请求：api/blog/getById/1

优点：内存占用较少，没有多余key缺点：实现复杂，存在误判

布隆过滤器介绍

bitmap（位图）：相当于是一个以（bit）位为单位的数组，数组中每个单元只能存储二进制数0或1

布隆过滤器作用：布隆过滤器可以用于检索一个元素是否在一个集合中。

布隆过滤器是一种用于快速判断一个元素是否属于某个集合的数据结构，它通过牺牲一定的准确性来换取高效的查询速度。下面是布隆过滤器的实现过程：

• 初始化：创建一个长度为m的位数组（bit array），并将所有位都初始化为0。同时选择k个不同的哈希函数。
• 插入元素：对于要插入的元素x，使用k个哈希函数分别计算出k个哈希值（h1(x), h2(x), …, hk(x)）。然后将位数组中对应位置的位设置为1，即将索引为h1(x)、h2(x)、…、hk(x)的位设置为1。
• 查询元素：对于要查询的元素y，同样使用k个哈希函数计算出k个哈希值（h1(y), h2(y), …, hk(y)）。然后检查位数组中对应位置的位是否都为1，如果有任何一个位为0，则确定元素y不在布隆过滤器中；如果所有位都为1，则元素y可能在布隆过滤器中。

误判率：数组越小误判率就越大，数组越大误判率就越小，但是同时带来了更多的内存消耗。

布隆过滤器实现方案

• Redisson
• Guava

1.2 缓存穿透面试

面试官：什么是缓存穿透 ? 怎么解决 ?

候选人：

缓存穿透是指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。这种情况大概率是遭到了攻击。

解决方案的话，我们通常都会用布隆过滤器来解决它

面试官：好的，你能介绍一下布隆过滤器吗？

候选人：

布隆过滤器主要是用于检索一个元素是否在一个集合中。我们当时使用的是redisson实现的布隆过滤器。

它的底层主要是先去初始化一个比较大数组，里面存放的二进制0或1。在一开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标然后把数组中原来的0改为1，这样的话，三个数组的位置就能标明一个key的存在。查找的过程也是一样的。

当然是有缺点的，布隆过滤器有可能会产生一定的误判，我们一般可以设置这个误判率，大概不会超过5%，其实这个误判是必然存在的，要不就得增加数组的长度，其实已经算是很划分了，5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。

2. 缓存击穿

缓存击穿：给某个热点key设置了过期时间，当某个热点key失效的瞬间，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮,而这样的key也被叫做热key!

解决方案一：互斥锁(分布式锁)

在缓存失效时，使用分布式锁，只允许一个线程去查询数据库，其他线程等待。查询到数据后，刷新到缓存，释放锁。这样可以确保只有一个线程去查询数据库，避免了大量请求同时涌入数据库。

在并发的情况下，对于热Key失效的情况，大量的请求则会直接打到数据库上并试图重建缓存，很有可能打停数据库，导致服务中断。

对于这样的情况往往是在未命中缓存时，最佳的处理点就在于业务中判断缓存是否命中之后的那一步操作，即“多余”的请求对数据库的访问与否。

思考:互斥锁情况下，同一个接口，在并发情况下，缓存未命中情况下，是否可以有多个线程同时访问数据库

不能，只有加锁的线程才可以访问数据库

思考:线程什么时候可以访问数据库

在线程释放锁之后，才可以访问

思考:其他线程拿不到锁在干什么

拿不到锁的线程在等待

互斥锁优缺点

优点：

强数据一致性：互斥锁可以保证在缓存失效时，只有一个线程去查询数据库，并在查询到数据后刷新到缓存，确保缓存中的数据是最新的。

简单实现：互斥锁的实现相对简单，可以通过分布式锁工具或者数据库的行级锁来实现，减少了业务代码的复杂性。

缺点：

性能开销：获取和释放锁都需要一定的性能开销，如果锁的粒度太细或者并发量太高，可能会导致性能问题。此外，分布式锁的实现可能涉及网络通信，也可能引入额外的延迟。

并发性下降：由于在缓存失效时只允许一个线程去查询数据库，可能导致并发性下降，特别是在高并发的场景中。

。

解决方案二：逻辑过期

逻辑过期:  逻辑过期不是真正的过期，对于对应的Key我们并不需要去redis设置TTL，而是通过业务逻辑来达到一个类似于“过期”的效果。其本质还是限制落到数据库的请求数量！但前提是牺牲一致性保证可用性，还是上一个业务的接口，通过使用逻辑过期来解决缓存击穿

看完上面这一段，相信大家还很迷惑。既然没有在Redis设置过期时间，那你为什么还要判断逻辑过期时间，怎么还存在过不过期的问题？

其实，这里所谓的逻辑过期时间只是一个类的属性字段，根本没有上升到Redis，上升到缓存的层面，是用来辅助判断查询对象的，也就是说，所谓的过期时间与缓存数据是剥离开的，所以根本不存在缓存过期的问题，自然数据库也不会有压力。

@Data
public class RedisData {
    private LocalDateTime expireTime;
    private Object data;  //这里用Object是因为以后可能还要缓存别的数据
}

2.2 缓存击穿面试

面试官：什么是缓存击穿 ? 怎么解决 ?

候选人：

缓存击穿的意思是对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好这时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。

解决方案有两种方式：

第一可以使用互斥锁：当缓存失效时，不立即去load db，先使用如 Redis 的 setnx 去设置一个互斥锁，当操作成功返回时再进行 load db的操作并回设缓存，否则重试get缓存的方法

第二种方案可以设置当前key逻辑过期，大概是思路如下：

• 1. 在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前key设置过期时间
• 2. 当查询的时候，从redis取出数据后判断时间是否过期
• 3. 如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新

当然两种方案各有利弊：

如果选择数据的强一致性，建议使用分布式锁的方案，性能上可能没那么高，锁需要等，也有可能产生死锁的问题

如果选择key的逻辑删除，则优先考虑的高可用性，性能比较高，但是数据同步这块做不到强一致

3. 缓存雪崩

缓存雪崩：是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

3.1. 解决方案：

1. 给不同的Key的TTL添加随机值
2. 利用Redis集群提高服务的可用性哨兵模式、集群模式
3. 给缓存业务添加降级限流策略ngxin或spring cloud gateway
4. 给业务添加多级缓存Guava或Caffeine

3.2.  缓存雪崩面试

面试官：什么是缓存雪崩 ? 怎么解决 ?

候选人：

缓存雪崩意思是设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。

解决方案主要是可以将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

给缓存业务添加降级限流策略 降级可做为系统的保底策略，适用于穿透、击穿、雪崩

给业务添加多级缓存