redis缓存雪崩、穿透、击穿的概念及解决思路

雪崩是

大面积

的key缓存失效；穿透是redis里

不存在

这个缓存key；击穿是redis

某一个热点

key突然失效，最终的受害者都是数据库。

1. 缓存雪崩

1.1. 概念

在

高并发

下，在数据未加载到缓存中或者缓存同一时间大面积的失效，绝大部分请求都去查数据库，造成数据库短时间内承受⼤量请求⽽崩掉

1.2. 故障解决

1. 事前：尽量保证整个 redis 集群的⾼可⽤性，发现机器宕机尽快补上。选择合适的内存淘汰策 略。
2. 事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL崩掉。或通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。注意:加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量
3. 事后：利⽤ redis 持久化机制保存的数据尽快恢复缓存

1.3. 解决思路

针对缓存同一时间大面积的失效的问题，解决思路如下：

1. 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀，均摊分配Redis的key的失效时间，避免大量key集体失效
2. 针对较少改变的热点数据设置为永不过期
3. 若是集群部署，可将热点数据均匀分布在不同的Redis库中也能够避免key全部失效问题
4. 跑定时任务，在缓存失效前刷进新的缓存

2. 缓存穿透

2.1. 概念

缓存穿透说简单点就是⼤量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这⼀层。举个例⼦：某个⿊客故意制造我们缓存中不存在的 key 发起⼤量请求，导致⼤量请求落到数据库。

redis缓存

和

数据库

中没有相关数据(例用户直接携带

id<=0

的参数不断发起请求)，redis中没有这样的数据，

无法进行拦截

，直接被穿透到

数据库

，导致数据库压力过大宕机。

如下图：

正常缓存处理流程下，客户端请求的key直接从缓存中获取数据，仅有少量查询数据库

缓存穿透情况下处理流程，客户端请求的key绝大部分或全部不存在于缓存于，需要查询数据库，但因为结果为空，则不缓存结果，导致这个不存在的key每次请求都要到数据库去查询，造成缓存穿透。

⼀般MySQL 默认的最⼤连接数在 150 左右，这个可以通过 show variables like '%max_connections%'; 命令来查看。最⼤连接数⼀个还只是⼀个指标，cpu，内存，磁盘，网络等条件都会限制其并发能⼒！所以，⼀般 3000 个并发请求就能打死⼤部分数据库了。

2.2. 解决思路

1. 最基本就是做好参数校验，⼀些不合法的参数请求直接抛出异常信息返回给客户端。⽐如查询的数据库 id 不能⼩于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。
2. 缓存⽆效 key : 如果缓存和数据库都查不到某个 key 的数据就写⼀个到 redis 中去并设置过期时间。仩这种⽅式可以解决请求的 key 变化不频繁的情况，如果⿊客恶意攻击，每次构建不同的请求key，会导致 redis 中缓存⼤量⽆效的 key 。很明显，这种⽅案并不能从根本上解决此问题。如果⾮要⽤这种⽅式来解决穿透问题的话，尽量将⽆效的 key 的过期时间设置短⼀点⽐如 1 分钟。
3. 布隆过滤器：通过它可以⾮常⽅便地判断⼀个给定数据是否存在与海量数据中。需要的就是判断 key 是否合法。具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当⽤户请求过来，会先判断⽤户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会⾛下⾯的流程。
4. 拉黑频繁请求且key不存在的IP地址

3. 缓存击穿

3.1. 概念

某一个

热点key，在不停地扛着高并发，当这个热点key在

失效的一瞬间

，持续的高并发访问就

击破缓存

直接访问数据库，导致数据库宕机。

3.2. 解决思路

• 设置热点数据"永不过期"

• 加上互斥锁：多个线程同时去查询数据库中这个热点key的数据，可以在第一个查询数据的请求上使用一个互斥锁来锁住它

  其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后将数据放到redis缓存起来。后面的线程进来发现已经有缓存了，就直接走缓存

参考

《v3.0-JavaGuide问题突击版夜间模式.pdf》

https://www.zhihu.com/question/421946305/answer/1482420252