Redis从入门到进阶第 6 讲：缓存雪崩击穿穿透场景与解决方案

Posted 2023-04-09 执梗

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis从入门到进阶第 6 讲：缓存雪崩击穿穿透场景与解决方案相关的知识，希望对你有一定的参考价值。

专栏前言

本专栏开启，目的在于帮助大家更好的掌握学习Redis，同时也是为了记录我自己学习Redis的过程，将会从基础的数据类型开始记录，直到一些更多的应用，如缓存击穿还有分布式锁以及Redis持久化等。希望大家有问题也可以一起沟通，欢迎一起学习，对于专栏内容有错还望您可以及时指点，非常感谢大家 🌹。

1.缓存的三大问题

话说学习缓存，缓存雪崩、击穿、穿透肯定是绕不开的一个话题，不仅在开发中我们需要注意这个问题，在面试中更是面试官有关Redis必问的面试题，可以说我们对这三个场景我们必须了解其中的差异，以及各自的解决方案。

2.缓存雪崩

2.1 什么是缓存雪崩？

缓存雪崩指的是在同一时间，大量的Key同时失效，导致大量的请求直接绕开了我们的Redis直接打到数据库，数据库一下顶不住直接挂彩了，这就是缓存雪崩的场景。
那有的人肯定好奇，咦？怎么会那么巧大量的Key同时失效，考虑一个秒杀场景，比如双十一的时候，我们在晚上十一点集中上架一批商品，此时缓存过期时间设置为一小时，那么一到十二点这批商品的缓存就全部过期了，如果此时成千上万的用户想购买这些商品发送大量请求，就会导致数据库的压力上升从而可能压垮数据库。

同一时间大量 Key 失效，就会导致Redis直接如同隐身了一样，那对于双十一这种数以千万级别甚至上亿量级的请求来到数据库，那后果就是灾难性的。一旦你一个库被打倒，那么其他的库可能也会收到影响，导致瞬间都挂掉了。你一重启用户又把你干崩，等你真正修好的时候，可能用户早就睡着了，还在心里吐槽一句什么垃圾产品。
当然，如果Redis宕机了，那么显然也会触发缓存雪崩的情况。

2.如何解决缓存雪崩？

讨论完了案发场景，那我们该如何解决缓存雪崩了。

过期时间添加随机值。
那就对症下药嘛，既然你是大量的key同时过期导致的，那我就尽量让你不一起过期，所以我们在批量添加缓存的时候，可以给过期时间添加一个随机值，使得Key过期的时间尽量分散，这样保证缓存不会大面积的同时失效。
进行集群部署
集群部署的情况下，我们就无须担心某一台Redis宕机导致触发缓存雪崩，也可以将热点数据均匀分布在不同Redis库中，来避免全部失效的问题。
热点数据永不过期
我们也可以让热点数据永不过期，只进行更新的操作，这也可以避免缓存雪崩。但可能会带来数据不一致的问题。

3.缓存穿透

3.1 什么是缓存穿透？

缓存穿透指的是对于一些缓存和数据库中都不存在的数据，而用户却不断对该数据进行请求，如果你的数据库甚至没有建立索引，那么数据库还会进行全表扫描，压力更大。每次数据库都需要去进行查，然后查不到，然后又继续查，然后又查不到，然后又…最终数据库卒，这就是缓存穿透。
此时显然用户是一个攻击者，比如我们数据库id都是从1开始自增的，它可以故意访问一个负数的id，然后不断请求，如果是我们个人搭建的一些小网站，对这种行为没有预防，只需要用 postman 就可以干崩你的网站。

3.2 如何解决缓存穿透?

我们考虑如何去解决缓存穿透问题。

参数校验
在场景中我们已经提及，对于一些非法的参数我们一定要进行校验，不合法的参数直接进行返回，比如一些负数的id，还有用户的鉴权校验。参数校验的思想我们一定要根深蒂固，在任何地方都不应该相信前端传来的参数，我们都应当手动判断其是否合法。
缓存空值
对于一些不存在的对象，我们也可以将其作为key缓存，value设置null，这样用户再次访问时就不会走数据库查询了。当然需要注意的是我们这个key的过期时间我们需要设置短一些。

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;

@Component
public class CacheNullValue 

    private static final int CACHE_EXPIRATION = 60; // 缓存过期时间，单位为秒

    @Autowired
    private StringRedisTemplate stringRedisTemplate;
	//@NotBlank对参数进行校验
    public String getData(@NotBlank String key) 
        String data = stringRedisTemplate.opsForValue().get(key);
        if (data == null) 
            data = getDataFromDatabase(key);
            if (data == null) 
                // 将空值缓存指定时间
                stringRedisTemplate.opsForValue().set(key, "", CACHE_EXPIRATION);
             else 
                // 将数据缓存指定时间
                stringRedisTemplate.opsForValue().set(key, data, CACHE_EXPIRATION);
            
        
        return data;
    

    private String getDataFromDatabase(String key) 
        // 从数据库中获取数据的逻辑
        System.out.println("查询数据");
        return null;

布隆过滤器
这是一个解决缓存穿透效果最好的办法，但是确定就是代码维护起来比较复杂。它是一种数据结构，主要的作用是用来判断某个元素是否存在在集合内，具有运行速度快，占用内存小等优点，但是具有一定的误判率，而且删除困难等问题。但它有一个特点，就是会可能会误报但不会漏报，存在的元素它一定会知道，不存在的元素它可能也会告诉你存在。
这样我们就可以使用布隆过滤器来对一些数据进行白名单，如果不存在的话我们直接返回null或者失败。
监控IP
要知道正常的用户，肯定不会同时发大量的非法请求，当请求次数超过某个阈值时，那么我们可以对该用户ip进行拉黑，把他关进小黑屋。

4. 缓存击穿

4.1 什么是缓存击穿？

接下来最后聊聊缓存击穿，有的同学可能容易把它和缓存穿透搞混，听起来意思很像，这里分析一下我的记法——巴雷特 （当然你也可以记成 AWM ）。不知道大家玩过枪战游戏没，巴雷特是一把杀伤力巨大的狙击枪，单点的杀伤力爆炸，哪怕你站在门后都能把你一枪击穿。
回到正题，缓存击穿有点类型我们刚刚举的小例子，它指的是对于一个非常热门的key在不停地扛着大并发需求，如果这个key瞬间失效了，此时瞬间大并发就直接到达了数据库，数据库瞬间挂彩，这感觉就像大木桶打穿了一个洞的感觉（没错就是巴雷特的感觉 😂）
缓存击穿一般是两个场景产生，注意我们强调的是并发的场景下：

1. 该数据没有人查询过，所以缓存中没有，第一次就遭受大并发访问（某些冷门数据）
1. 缓存中存在，但恰好失效了，大并发访问瞬间落到数据库（热点数据）

4.2 如何解决缓存击穿？

加互斥锁
由于是并发场景下，我们可以考虑加锁解决该问题，当缓存未命中时，只有持有锁的线程才能进行数据库查询，然后将查询结构写入缓存，其余的线程只能自旋进行等待。
下面是逻辑的流程图

import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.ValueOperations;
import org.springframework.data.redis.core.RedisOperations;
import org.springframework.data.redis.core.RedisConnectionUtils;
import org.springframework.data.redis.RedisConnectionFailureException;
import java.util.concurrent.locks.ReentrantLock;
@Component
public class RedisCache 
    
    private final static String CACHE_PREFIX = "my_cache_";
    private final static int EXPIRE_TIME_SECONDS = 60;
    private final ReentrantLock lock = new ReentrantLock();
	@Autowired
    private StringRedisTemplate stringRedisTemplate;
    public Object get(@NotBlank String key) 
        String cacheKey = CACHE_PREFIX + key;
        //1.先查询缓存
        ValueOperations<String, String> ops = redisTemplate.opsForValue();
        String value = ops.get(cacheKey);
        //2.缓存未命中
        if (value == null) 
        	//3.尝试获取锁
            lock.lock();
            try 
         		//4.双重校验
                value = ops.get(cacheKey);           
                if (value == null) 
                	//5.查询数据库
                    value = fetchDataFromDatabase(key);
                    //6.写回redis
                    ops.set(cacheKey, value, EXPIRE_TIME_SECONDS);
                    
                
             catch (Exception e) 
                System.out.println("出现异常");
             finally 
            	//释放锁
                lock.unlock();
            
        
        return value;
    

    private String fetchDataFromDatabase(String key) 
        System.out.println("查询数据库");
        return key;

需要注意我们这里的场景是单机的情况下，如果是分布式环境的话我们就得使用分布式锁了，这里我们使用synchronized和lock都是可以的。有关分布式锁我们后续文章会进行讲解

热点数据永不过期

同样因为是数据过期的问题，那我们也可以考虑设置热点数据永不过期，当后台更新数据的同时更新缓存中的数据，当然可能会带来数据不一致的问题，适用于不严格要求缓存一致性的场景。

第128天学习打卡（Redis 哨兵模式 Redis缓存穿透和缓存击穿雪崩）

哨兵模式

概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务器不可用。这不是一种推荐的方式，更多的时候，会优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel(哨兵)架构来解决这个问题。

哨兵模式，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用：

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换到master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

测试

我们目前的状态是一主二从

1.配置哨兵配置文件sentinel.conf

[root@kuangshen kconfig2]# vim sentinel.conf

#sentinel monitor myredis host port 1
#后面的这个数字1，代表主机挂了，slave投票看让谁接替为主机，票数最多的，就会成为主机！
sentinel monitor myredis 127.0.0.1 6379 1

2.启动哨兵！

[root@kuangshen bin]# redis-sentinel kconfig2/sentinel.conf
20898:X 16 May 2021 15:06:06.195 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
20898:X 16 May 2021 15:06:06.195 # Redis version=6.2.3, bits=64, commit=00000000, modified=0, pid=20898, just started
20898:X 16 May 2021 15:06:06.195 # Configuration loaded
20898:X 16 May 2021 15:06:06.195 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.3 (00000000/0) 64 bit
  .-`` .-```.  ```\\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 20898
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

20898:X 16 May 2021 15:06:06.200 # Sentinel ID is 0648b14b7c1292002550df442ceef23bcffe07be
20898:X 16 May 2021 15:06:06.200 # +monitor master myredis 127.0.0.1 6379 quorum 1
20898:X 16 May 2021 15:06:06.200 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
20898:X 16 May 2021 15:06:06.206 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379

如果Master节点断开了，这个时候就会从从机中随机选择一个服务器！（这里面有一个投票算法！）

failover #故障转移

哨兵模式

如果主机此时回来了，只能归并到新的主机下，当做从机，这就是哨兵模式的规则。

优点：

1.哨兵模式，基于主从复制模式，所有的主从配置优点，它全有

2.主从可以切换，故障可以转移，系统的可用性就会更好。

3.哨兵模式就是主从模式的升级，手动到自动，更加健壮。

缺点:

1.Redis不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦！

2.实现哨兵模式的配置其实是很麻烦的，里面有很多选择。

哨兵模式的全部配置：

# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379         如果有哨兵集群，我们还需呀配置每个哨兵端口
port 26379
# 哨兵sentinel的工作目录
dir /tmp
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供
密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那
里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。 
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，
slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知
相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），
将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信
息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配
置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无
法正常启动成功。
#通知脚本
# shell编程
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已
经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通
信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配
置！

Redis缓存穿透和雪崩（面试高频，工作常用）

服务的高可用问题!

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别时数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。

另外的一些经典问题就是，缓存穿透、缓存雪崩和缓存击穿。

缓存穿透（查不到导致的）

概念

缓存穿透是，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

解决方案

布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数都以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力；

缓存空对象：

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；

但是这种方法会存在两个问题：

1.如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；

2.即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

缓存击穿（量太大，缓存过期）

概述

这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导致数据库瞬间压力过大。

解决方案

设置热点数据永不过期

从缓存层面上来看，没有设置过期时间，所以不会出现热点key过期后产生的问题。

加互斥锁

分布式锁：使用分布式锁，保证对于每个key同时只要一个线程区查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis宕机。

产生雪崩的原因之一，比如要到双十二零点，很快会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点中的时候，这批商品的缓存就都过期了，而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所以的请求都会到达存储层，存储层的调用会暴增，造成存储层也会挂掉的情况。