一，什么是缓存穿透、雪崩、击穿？

(相关资料图)

1、缓存穿透：

是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

2、缓存雪崩：

我们可以简单的理解为：由于原有缓存失效，新缓存未到时间 (例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

3、缓存击穿：

某个 key 非常非常热，访问非常的频繁，高并发访问的情况下，当这个 key在失效（可能expire过期了，也可能LRU淘汰了）的瞬间，大量的请求进来，这时候就击穿了缓存，直接请求到了数据库，一下子来这么多，数据库肯定受不了，这就叫缓存击穿。某个key突然失效，然后这时候高并发来访问这个key，结果缓存里没有，都跑到db了。和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

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

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

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

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

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

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

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

二，对应解决方案

2.1、缓存穿透

根本原因（结合上文）就是：请求根本不存在的资源

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

当大量的客户端发出类似于：https://localhost：9090/user/18933？id=-9527的请求，就可能导致出现缓存穿透的情况。因为数据库DB中本身就没有id=-9527的用户的数据，所以Redis也没有对应的数据，那么这些请求在redis就得不到响应，就会直接打在DB上，导致DB压力过大而卡死情景在线或宕机

解决方式：

对空值进行缓存

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

实时监控

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

使用布隆过滤器

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

接口校验

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

二，对应解决方案

2.1、缓存穿透

根本原因（结合上文）就是：请求根本不存在的资源

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

当大量的客户端发出类似于：https://localhost：9090/user/18933？id=-9527的请求，就可能导致出现缓存穿透的情况。因为数据库DB中本身就没有id=-9527的用户的数据，所以Redis也没有对应的数据，那么这些请求在redis就得不到响应，就会直接打在DB上，导致DB压力过大而卡死情景在线或宕机

解决方式：

对空值进行缓存

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

实时监控

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

使用布隆过滤器

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

接口校验

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

2.3、缓存击穿

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

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

解决方式：

提前对热点数据进行设置

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

监控数据，适时调整

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

使用锁机制

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

关键词