redis缓存雪崩、击穿、穿透详解及其应对办法

redis作为高并发的基石，在各大互联网存储技术中拥有广泛的应用。而缓存雪崩、击穿、穿透这三个概念也许我们都听说过，但这三个概念具体含义及其却别是什么呢？让我们一起来揭开他们的神秘面纱。

一、缓存雪崩

1、概念

目前电商的首页以及热点数据都会做缓存，一般缓存都是定时任务去刷新，或者查不到后去更新，定时刷新就会存在一个问题：

比如：如果所有首页key的失效时间是12小时，中午12点刷新，零点秒杀活动有大量的用户涌入，假设每秒6000个请求，本地缓存能抗住每秒5000个请求，但是所有的key都失效了，每秒4000个请求全部打到数据库上，数据库必然扛不住，所以会报一下警，真实的情况是当想去处理时，发现数据库已经挂了。如果没有特别的方案处理这个故障，只是重启数据库，会发现瞬间来的请求又会把数据库打死。这就是缓存雪崩的概念。

同一时间缓存key大面积失效，那一瞬间redis和没有一样，那个数量级别的请求直接打到数据库上几乎是灾难性的，你想想如果打挂的是一个用户服务的库，那么其他依赖他的库的所有的接口几乎都会报错，如果没有熔断等策略，基本上瞬间就挂一片，你怎么重启用户都会把你打挂，等你重启好了，用户早就去睡觉了，对你的产品也失去了信心，也许再也不会用了，这样会流失一部分客户。

2、如何应对

处理缓存雪崩很简单，在批量往redis存数据时，把每个key的失效时间都加一个随机值，这样可以保证数据不会同一时间大面积失效，redis这点流量还是能抗住的。

setRedis（Key，value，time + Math.random() * 10000）；

如果redis是集群部署，将热点数据均匀分布在不同的redis库中也能避免全部失效的问题。或者设置热点数据永不过期，有更新就更新缓存就好(比如运维更新了首页商品，那你刷新下缓存就完事了，不要设置过期时间)，电商首页的数据也可以用这个操作，保险。

二、缓存击穿

1、概念

缓存击穿和缓存雪崩有点像，但又有点不一样，缓存雪崩是因为大面积缓存失效，打崩了DB，而缓存击穿是指一个key非常热点，在不停的抗着大并发，大并发对这个一点进行访问，当这个key失效瞬间，持续的大并发就穿破了缓存，直接请求打数据库，就像一个完好无损的桶被击穿一个洞。

2、如何应对

可以使用热点数据永不过期，或者使用互斥锁。

业界比较常用的做法，是使用互斥锁(mutex key)。简单来说，就是在缓存失效的时候(拿出的值为空)，不是立即去load db，而是使用缓存工具的某些带成功操作返回值的操作(比如：redis的SETNX或者Memcache的ADD)，去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存，否则，表示已经有其他线程load db并回设缓存了，直接get获取缓存之就行。参考代码如下：

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;      
          }
 }

注：SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。

三、缓存穿透

1、概念

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，我们的数据库的id都是1开始自增上去的，如果发起id为-1的数据或者id为特别大不存在的数据，这时用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。

2、如何应对

（1）可以在接口层增加校验，比如用户鉴权校验、参数做校验，不合法的参数直接return，比如：id做基础校验，id <= 0的直接拦截。

这里想提的一点就是，我们在开发程序的时候要有一颗“不信任”的心，就是不相信任何调用方，比如你提供了api接口出去，你有几个参数，那我觉得作为被调用方，任何可能的参数情况都应该被考虑到，做校验，因为你不相信调用你的人，你不知道他会传来什么参数给你。

从缓存和数据库中都取不到值，这时可以将对应key的value写为null、位置错误、稍后重试这样的值具体取啥问产品，或者看具体场景，缓存有效时间可以设置短点，如30秒(设置太长会导致正常情况也没法使用)。

这样可以防止攻击用户反复用同一个id暴力攻击，但是我们知道正常用户是不会在单秒内发起这么多次请求的，网关层Nginx可以进行配置，可以让运维大大对单个ip每秒访问次数超过阈值的ip拉黑。

（2）redis还有一个高级用法：布隆过滤器(Bloom Filter)，这个也能很好的防止缓存穿透的发生，他的原理也很简单，就是利用高效的数据结构和算法快速判断这个key是否在数据库中存在，不存在直接return就好，存在你就查db刷新KV在return。

小结：

一般为了避免上述情况发生，可以从三个时间段分析：

1.事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。

2.事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免mysql被打死。

3.事后：redis 持久化 RDB + AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存信息。

好处：

数据库绝对不会死，限流组件确保了每秒只有多少个请求通过。只要数据不死，就是说，对于用户来说，3/5的请求都是可以被处理的。只要有3/5的请求被处理，就意味着你的系统没死，对用户来说，可能就是点几次刷新不出来页面，但是多点几次，就可以刷新出来一次。

这个在目前主流的互联网大厂里面是最常见的，你是不好奇，某明星爆出什么事，你发现你去微博怎么刷都是空白页面，但是有的人又直接进去了，你多刷几次也出来了，现在知道了把，那就是做了降级，牺牲了部分用户的体验换来服务的安全。

总结

我们在遇到一个问题是，一定要知其然，知其所以然。要理解是怎么发生的，以及怎么去避免的，发生之后又怎么去抢救，你可以不是知道很深入，但你不能一点不去想，尤其是在面试的时候，有时不一定是对知识面的拷问，或许是对你的学习态度的拷问，如果你的思路很清晰，我想面试官会感觉，恩，这个小伙子(小姑娘)很nice，值得培养。

最后引用我很佩服的一个人经常说的话：你知道的越多，你不知道的越多！

文章参考：
https://mp.weixin.qq.com/s/knz-j-m8bTg5GnKc7oeZLg