一、概述

① 缓存穿透：大量请求根本不存在的key（下文详解）

② 缓存雪崩：redis中大量key集体过期（下文详解）

③ 缓存击穿：redis中一个热点key过期（大量用户访问该热点key，但是热点key过期）

穿透解决方案：

• 对空值进行缓存
• 设置白名单
• 使用布隆过滤器
• 网警

雪崩解决方案：

• 进行预先的热门词汇的设置，进行key时长的调整
• 实时调整，监控哪些数据是热门数据，实时的调整key的过期时长
• 使用锁机制

击穿解决方案：

• 进行预先的热门词汇的设置，进行key时长的调整
• 实时调整，监控哪些数据是热门数据，实时的调整key的过期时长
• 使用锁机制(只有一个线程可以进行热点数据的重构)

下文进行详解

三者出现的根本原因：Redis命中率下降，请求直接打在DB上

正常情况下，大量的资源请求都会被redis响应，在redis得不到响应的小部分请求才会去请求DB，这样DB的压力是非常小的，是可以正常工作的（如下图）

如果大量的请求在redis上得不到响应，那么就会导致这些请求会直接去访问DB，导致DB的压力瞬间变大而卡死或者宕机。如下图：

① 大量的高并发的请求打在redis上

② 这些请求发现redis上并没有需要请求的资源，redis命中率降低

③ 因此这些大量的高并发请求转向DB（数据库服务器）请求对应的资源

④ DB压力瞬间增大，直接将DB打垮，进而引发一系列“灾害”

那么为什么redis会没有需要访问的数据呢？通过分析大致可以总结为三种情况，也就对应着redis的雪崩、穿透和击穿（下文开始进行详解）

二、情景分析 （详解）

缓存穿透

缓存穿透产生的原因：请求根本不存在的资源（DB本身就不存在，Redis更是不存在）

举例（情景在线）：客户端发送大量的不可响应的请求（如下图）

当大量的客户端发出类似于：http://localhost:8080/user/19833″ />缓存雪崩

缓存雪崩产生的原因：redis中大量的key集体过期

举例：

当redis中的大量key集体过期，可以理解为redis中的大部分数据都被清空了（失效了），那么这时候如果有大量并发的请求来到，那么redis就无法进行有效的响应（命中率急剧下降），请求就都打到DB上了，到时DB直接崩溃

解决方式：

• 将失效时间分散开

通过使用自动生成随机数使得key的过期时间是随机的，防止集体过期

• 使用多级架构

使用nginx缓存+redis缓存+其他缓存，不同层使用不同的缓存，可靠性更强

• 设置缓存标记

记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去跟新实际的key

• 使用锁或者队列的方式

如果查不到就加上排它锁，其他请求只能进行等待

---

缓存击穿

产生缓存雪崩的原因：redis中的某个热点key过期，但是此时有大量的用户访问该过期key

举例：

类似于“某男明星塌房事件”上了热搜，这时候大量的“粉丝”都在访问该热点事件，但是可能优于某种原因，redis的这个热点key过期了，那么这时候大量高并发对于该key的请求就得不到redis的响应，那么就会将请求直接打在DB服务器上，导致整个DB瘫痪。

解决方案：

• 提前对热点数据进行设置

类似于新闻、某博等软件都需要对热点数据进行预先设置在redis中

• 监控数据，适时调整

监控哪些数据是热门数据，实时的调整key的过期时长

• 使用锁机制

只有一个请求可以获取到互斥锁，然后到DB中将数据查询并返回到Redis，之后所有请求就可以从Redis中得到响应

---