缓存被穿透了怎么办？

首先来了解几个概念：

缓存穿透：大量请求根本不存在的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?id=-3872 的请求，就可能导致出现缓存穿透的情况。因为数据库DB中本身就没有id=-3872的用户的数据，所以Redis也没有对应的数据，那么这些请求在redis就得不到响应，就会直接打在DB上，导致DB压力过大而卡死情景在线或宕机。

缓存穿透很有可能是黑客攻击所为，黑客通过发送大量的高并发的无法响应的请求给服务器，由于请求的资源根本就不存在，DB就很容易被打垮了。

解决方案

对空值进行缓存：

类似于上面的例子，虽然数据库中没有id=-3872的用户的数据，但是在redis中对他进行缓存（key=-3872，value=null），这样当请求到达redis的时候就会直接返回一个null的值给客户端，避免了大量无法访问的数据直接打在DB上

实时监控：

对redis进行实时监控，当发现redis中的命中率下降的时候进行原因的排查，配合运维人员对访问对象和访问数据进行分析查询，从而进行黑名单的设置限制服务（拒绝黑客攻击）

使用布隆过滤器

使用BitMap作为布隆过滤器，将目前所有可以访问到的资源通过简单的映射关系放入到布隆过滤器中（哈希计算），当一个请求来临的时候先进行布隆过滤器的判断，如果有那么才进行放行，否则就直接拦截

接口校验

类似于用户权限的拦截，对于id=-3872这些无效访问就直接拦截，不允许这些请求到达Redis、DB上。

注意事项：

- 使用空值作为缓存的时候，key设置的过期时间不能太长，防止占用太多redis资源
- 使用空值作为缓存只能防止黑客重复使用相同的id暴力攻击，但是如果黑客使用动态的无效id攻击就没有效果（需要配合网警）
- 使用布隆过滤器也是有哈希冲突的可能

缓存雪崩

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

举例：

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

解决方案：

- 将失效时间分散开
- 通过使用自动生成随机数使得key的过期时间是随机的，防止集体过期
- 使用多级架构
- 使用nginx缓存+redis缓存+其他缓存，不同层使用不同的缓存，可靠性更强
- 设置缓存标记
- 记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去跟新实际的key
- 使用锁或者队列的方式
- 如果查不到就加上排它锁，其他请求只能进行等待