Redis的缓存穿透、缓存击穿、缓存雪崩

一、概述

① 缓存穿透：大量请求根本不存在的key

② 缓存雪崩：Redis中大量key集体过期

③ 缓存击穿：Redis中一个热点key过期

三者出现的根本原因：Redis命中率下降，请求直接打在DB上 正常情况下，大量的资源请求都会被redis响应，在redis得不到响应的小部分请求才会去请求DB，这样DB的压力是非常小的，是可以正常工作的（如下图）

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

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

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

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

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

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

二、情景分析 （详解）

（一）缓存击穿

概念：

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

情景：

缓存击穿的原因通常有以下几种：

1. 缓存中不存在所需的热点数据：当系统中某个热点数据需要被频繁访问时，如果这个热点数据最开始没有被缓存，那么就会导致系统每次请求都需要直接查询数据库，造成数据库负担。

2. 缓存的热点数据过期：当一个热点数据过期并需要重新缓存时，如果此时有大量请求，那么就会导致所有请求都要直接查询数据库。

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

解决方案：

1.设置永不过期（提前对热点数据进行设置）

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

2.加锁排队

（方式一）双重检查锁：

只有一个请求A可以获取到互斥锁，其它请求在外排队，然后线程A到DB中将数据查询并返回到Redis，之后所有请求就可以从Redis中得到响应（这些请求有两种情况：一，已经进入排队的请求获得锁之后，可在第二重查询redis中获取数据；二，没有进入排队的请求【也就是没有通过 if(obj == null) 而进入争取锁的队列中的请求】，直接在外部的查询redis获取到数据）

（方式二）分布式锁：

不好之处：

高并发的情况下，影响性能。但大多数情况下访问是可以从外层就可以获取到缓存数据的了，而只有在偶尔的情况下会因为key突然过期，才会导致那个时间的请求进入锁机制，而且进入排队的，也有二重检查来减轻对数据库的压力。

3.监控数据，适时调整

监控哪些数据是热门数据，实时的调整key的过期时长 使用锁机制

（二）缓存雪崩

概念：

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

举例：

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

情景：

• 大量key集体过期

  • 解决方法

    • 1.加锁排队 + 将失效时间分散开
    • 2.使用多级缓存架构
    • 3.设置缓存标记

• Redis服务宕机

  • 解决方法：redis高可用（集群、哨兵模式）

• 机房断电

  • 解决方法：提前做好灾备，做好多机房，一个机房挂掉了，马上切换到另外一个地方的机房

解决方式：

1.加锁排队 + 将失效时间分散开

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

2.使用多级架构

使用nginx缓存+redis缓存+其他缓存，不同层使用不同（过期时间）的缓存，可靠性更强

3.设置缓存标记

记录缓存数据是否过期，如果过期会去跟新实际的key。

（1）不另外启一个线程，而是在value里面，储存了个逻辑过期时间（相当于实际过期时间我们设置1小时，但逻辑过期时间可能是50分钟），取值的时候，判断 实际时间 > 逻辑时间，则进行加锁更新，其余的线程，拿不到锁的先全部返回旧数据。

（2）异步处理：但判断 实际时间 > 逻辑时间，通知另外的线程进行更新

4.redis高可用（集群、哨兵模式）

如果是Redis服务宕机，那就需要提前给Redis做好集群，并做好哨兵模式，发现宕机，另外的补上。

（三）缓存穿透

概念：

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

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

  当大量的客户端发出类似于：http://localhost:8080/user/19833?id=-3872 的请求，就可能导致出现缓存穿透的情况。因为数据库DB中本身就没有id=-3872的用户的数据，所以Redis也没有对应的数据，那么这些请求在redis就得不到响应，就会直接打在DB上，导致DB压力过大而卡死情景在线或宕机。   缓存穿透很有可能是黑客攻击所为，黑客通过发送大量的高并发的无法响应的请求给服务器，由于请求的资源根本就不存在，DB就很容易被打垮了。

解决方式：

1.缓存空对象（+加锁排队 + 将失效时间分散开）

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

  • 注意：

    • 使用空值作为缓存的时候，key设置的过期时间不能太长，防止占用太多redis资源（比如大量的恶意攻击）
    • 当前访问的数据可能当时数据库中没有，但后面可能会有，所以设置过期时间不能太长，建议随机的短时间

2.布隆过滤器

• 黑名单：把请求不存在的数据存进黑名单，下次访问数据前先判断布隆过滤器中是都存在该key，存在则拒绝访问。
• 白名单：把数据库存在的数据存进布隆过滤器，请求访问判断到布隆过滤器中有才释放后续访问数据，不存在则拒绝后续访问。

注意：

1. 要做好数据同步，因为不是所有的数据都是一直在黑名单或白名单的，增删改会导致变动。所以这种方式的缺点就是要做数据同步。
2. 布隆过滤器是有一定的误差，所以一般需要配合一些接口流量的限制（规定用户在一段时间内访问的频率）、权限校验、黑名单等来解决缓存穿透的问题

3.实时监控：

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

4.接口校验

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

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

相关推荐: 多目标建模算法PLE

1. 概述 在现如今的推荐系统或者搜索中，都存在多个目标，多目标的算法在现如今的系统中已然成为了标配。在多目标的建模过程中，如果不同的学习任务之间较为相关时，多个任务之间可以共享一部分的信息，这样最终能够提升整体的模型学习效果。但是如果多个任务之间的相关性并不…