【技术栈】Redis缓存穿透/击穿/雪崩/预热/降级

1. 前言

Redis缓存穿透、击穿、雪崩是Redis作为缓存最常遇到的问题（生产+面试），此外缓存预热以及降级也要有所了解。

 

度娘来一张图，总结的很到位，喜欢的推荐原创：https://blog.51cto.com/15069471/2610940
Redis缓存穿透、击穿、雪崩：
穿透：指在缓存和数据库中均没有值得时候
击穿：指的是单个值的缓存过期，查询直达DB的情况
雪崩：指的是批量值的缓存过期，查询直达DB的情况（另，Redis宕机导致数据丢失（可以理解为宕机了，缓存数据没有了，请求要达到DB上，而不是真正导致的部分数据丢失））
预热：指的提前将缓存数据加载
降级：指缓存失效或缓存服务器宕机时，直接返回默认数据或访问服务的内存数据

2. 缓存穿透

危害描述：
1. 缓存和数据库均无值，查询直达DB，缓存层已经失去缓存意义。这种情况经常出现在查询一个数据库中本没有值的情况（如会员id<0）
解决方案：
1. 布隆过滤器：查询Redis缓存前，先经过布隆过滤器的过滤，数据库中没有的值不会穿透到DB（见上图）
2. 返回空对象：为数据库中不存在的值设置一个空对象缓存，其过期时间设置的短一些
3. 和上述两种方案配合使用，业务上做一些校验（如会员id>0，字段长度校验等），尽量减少缓存穿透的情况发生
//返回空对象
public object GetProductListNew() {
    int cacheTime = 30;
    String cacheKey = "product_list";

    String cacheValue = CacheHelper.Get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    }

    cacheValue = CacheHelper.Get(cacheKey);
    if (cacheValue != null) {
        return cacheValue;
    } else {
        //数据库查询不到，为空
        cacheValue = GetProductListFromDB();
        if (cacheValue == null) {
            //如果发现为空，设置个默认值，也缓存起来
            cacheValue = string.Empty;
        }
        CacheHelper.Add(cacheKey, cacheValue, cacheTime);
        return cacheValue;
    }
}

3. 缓存击穿

危害描述：
1. 短期内缓存失效，高并发场景时对DB产生较大压力（如热点数据-商品秒杀）
2. 分布式环境下，容易产生缓存不一致的情况
解决方案：
1. 热点数据永不过期：提前给热点数据预设一个较长的过期时间或者永不过期
1.1 物理不过期，不设置过期时间
1.2 逻辑过期，把过期时间设置在value字段，如果发现要过期了，通过一个异步线程进行缓存的重新构建
2. 加互斥锁
2.1 单机环境下，加JVM锁即可（Synchronized或Lock）
2.2 分布式环境下，要加分布式锁，如Redis的setNx（SET if Not eXists）
2.3 加互斥锁，高并发场景大量线程阻塞，系统吞吐量降低
//加分布式锁
public String get(key) {
      String value = redis.get(key);
      if (value == null) { //代表缓存值过期
          //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
      if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {  //代表设置成功
          value = db.get(key);
          redis.set(key, value, expire_secs);
          redis.del(key_mutex);
      } else {  //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
          sleep(50);
          get(key);  //重试
      }
      } else {
          return value;      
      }
 }
注意：
1. 加JVM锁时，会有多个应用程序同时拿到锁的情况（即一台服务器可能去数据库查询一次，若每台服务器代码一致，一般情况下没问题，就是多查询几次的问题，但是若部署代码不一致，或者代码会导致拿到的数据不一致时就会有问题），使用分布式锁更好，只去查询一次
2. 加锁时，若当前锁被其它线程占用，另一个线程没拿到锁，则这个线程休眠一段时间再次尝试获取锁的时候，要重新判断缓存是否存在（双重校验机制）
3. redis的setNx必须设置key的同时设置过期时间，保证原子性（redis是单进程单线程的，对于收到的命令其实是串行进行的，若先设置key，再设置时间ex，当中间有非常耗时的key *命令时N秒，会导致设置的过期时间其实是大于要设置的ex的 ex+N，或者中间down机导致不能设置key的过期时间）
4. 解锁也要保证原子性，哪一个线程加的锁，需要有哪个线程进行解锁（比如线程A加锁的时候设置为value=a，线程A解锁的时候要保证value=a(ThreadLocal)，否则说明被其它线程操作了，此时抛出异常。特例：几个线程操作后value一致）
5. 设置过期时间，应该比业务执行时间稍大一些，但是若业务执行时间不确定（比如线程A设置过期时间2s，业务执行时间5s，当业务执行到2s的时候，缓存过期被删除，此时线程B获取锁，然后执行业务，若是购票系统，则可能存在多个线程拿到一张票的情况-多卖）
5.1 加时间：为线程A开启一个守护线程（比如每隔1s），只要当前缓存不过期，就增加过期时间
5.2 redission实现
6. 高可用，单机版redis若挂了，则一切结束，所以生产使用redis cluster，有个redLock的概念，超过一半的主机Master成功，则成功拿到锁的理论，使用redission实现
7. redis cluster基于分片的原理（crc16/16386个槽位，槽位可根据机器性能来分配，redission根据前缀分配到不同的机器，即分片上）

4. 缓存雪崩

解决方案：
1. 对缓存设置一个比较分散的随机时间
2. 分布式缓存，因redis集群分片策略，不同的缓存缓存在不同的片中，也能一定意义上降低雪崩的影响（缓存分散了，同时失效的情况降低了一些）
3. 加互斥锁：同缓存击穿解决思路，只不过分布式场景下只有一个线程获取当前锁，其它线程都在等待，引起大量阻塞，系统吞吐量降低，治标不治本
4. 缓存永不过期：同缓存击穿解决思路，物理上永远不过期，或用一个异步的线程重新构建缓存
5. 双层缓存策略：使用主备两层缓存
5.1 主缓存：有效期按照经验值设置，设置为主读取的缓存，主缓存失效后从数据库加载最新值
5.2 备份缓存：有效期长，获取锁失败时读取的缓存，主缓存更新时需要同步更新备份缓存

5. 缓存预热

缓存预热：主要解决应用系统上线时，什么时机加载好缓存数据，以保护DB安全
解决方案：
1. 数据量不大时，应用启动的时候加载缓存
2. 数据量大时，启动一个定时任务进行缓存的构建
3. 数据量很大时，优先保证热点数据加载

6. 缓存降级

缓存降级：同服务降级类似，当缓存系统无法提供正常服务时，返回一个预设的默认值，或去访问服务的内存数据
解决方案：
1. 返回默认值：缓存失效或系统宕机时，返回预设的默认值
2. 服务内存数据：缓存数据构建时，加载一份到应用服务内存，这样缓存异常时，可以去查询内存数据
2.1 缓存数据在初始构建、重新构建时需要对服务内存数据进行更新
2.2 缓存降级一般是有损操作，不到万不得已不要尝试使用

参考连接：

https://blog.csdn.net/kongtiao5/article/details/82771694
https://www.cnblogs.com/xichji/p/11286443.html
https://blog.csdn.net/wx1528159409/article/details/88357728
视频教程：https://ke.qq.com/course/450705?taid=3984965146960017
布隆过滤器：https://www.dtmao.cc/news_show_281758.shtml
手写布隆代码：https://blog.csdn.net/qq_38697767/article/details/108849197

【说明】梳理知识用，有些地方未做验证，请保持怀疑态度。