Redis雪崩问题怎么破？更新策略得讲究点，别全炸了才想办法

主要综合自知乎专栏“架构精进”的文章《缓存雪崩、缓存穿透、缓存击穿，Redis缓存三大问题的解决方案》以及掘金社区部分开发者的经验分享）

Redis雪崩,说白了就是一大堆数据在同一时间突然失效，或者Redis服务器直接宕机了，导致所有请求像雪崩一样，哗啦啦地全砸到后面的数据库上，数据库平时小打小闹还能顶住，这下瞬间来的请求太多了，根本处理不过来，轻则响应变慢，整个系统卡顿，重则直接把数据库搞挂，整个服务就瘫痪了，这就像节假日的高速公路收费站，所有车都挤在同一个时间点通过，出口就那么几个，可不就堵死了嘛。

怎么防止这种“全炸了”的悲剧发生呢？关键就在于更新缓存策略要讲究，不能太死板。

第一招，别让缓存键同时失效。 这是最核心的一点，很多人在设置缓存过期时间（TTL）的时候，图省事，给一大批数据设置了相同的过期时间，比如都设为1小时，结果1小时后，这些缓存齐刷刷地全部失效，请求瞬间穿透到数据库，解决办法很简单，就是给缓存过期时间加个随机数，原本都设1小时，现在可以改成在1小时的基础上，加上一个几分钟的随机值，比如1小时到1小时10分钟之间随机，这样，缓存就不会在同一时刻集体失效了，失效时间被均匀地分散开，对数据库的冲击就小多了，这招是从很多开发者的实践经验中总结出来的，非常有效。

第二招，建立缓存“后备军”，也就是设置热点数据永不过期。 对于一些特别重要、访问频率极高的热点数据，可以考虑不设置过期时间，让它们永远留在缓存里，但这并不意味着数据就不更新了，我们需要另外启动一个后台任务（比如一个定时任务），定期去主动更新这些缓存数据，这样，用户请求永远都能从缓存中拿到数据，完全不会给数据库压力，不过要注意，这个后台更新策略也要设计好，避免更新过程中出现错误导致缓存数据变成脏数据，知乎专栏“架构精进”里特别提到了这种“永久缓存+后台更新”的策略。

第三招，做好“熔断”和“降级”，准备后路。 即使我们做了分散过期时间和设置热点数据，仍然有可能出现极端情况，比如Redis整个集群真的宕机了，这时候，光靠缓存策略本身是没用的，需要有系统层面的保护机制，可以引入熔断机制，当系统检测到访问数据库的请求失败率太高或者响应时间太长时，就自动“熔断”，短时间内直接拒绝新的请求，返回一个默认的、友好的提示信息（系统繁忙，请稍后再试”），给数据库恢复的时间，降级则是准备一些非核心的功能暂时不可用，保证核心业务流程还能勉强运行，这些措施虽然影响了部分用户体验，但总比整个系统完全崩溃要好，这种思想在微服务架构中很常见，同样适用于处理缓存雪崩的极端场景。

第四招，在应用层加一道“锁”，避免大量请求同时重建缓存。 当某个缓存失效时，如果恰好有大量请求都来读这个数据，那么这些请求都会发现缓存没了，然后都跑去数据库查，同样会造成压力，这时候可以用一个简单的互斥锁机制，比如使用Redis的setnx命令，当第一个请求发现缓存失效后，它先去抢一个锁（在Redis里设置一个特殊的键），抢到锁的请求负责去数据库查询数据并写回缓存，而其他没抢到锁的请求呢？别傻等着，也不要都去查数据库，可以稍微等待一小会儿（比如100毫秒），然后重新去缓存里查，因为这个时候可能第一个请求已经把缓存重建好了，这样就保证了只有一个线程会去访问数据库，大大减轻压力，这个方法在掘金等社区的技术文章中被广泛讨论。

第五招，事前预防永远比事后补救强。 要做好Redis本身的高可用，比如使用Redis的主从复制（Replication）和哨兵模式（Sentinel）来自动切换故障节点，或者直接使用Redis集群（Cluster）将数据分片存储，这样即使某个节点宕机，也只会影响一部分数据，不会导致全线崩溃，对Redis服务器的资源和性能做好监控，提前发现潜在的风险。

破解Redis雪崩,不能等到问题发生了才手忙脚乱，核心思路是“分散压力、多层防护”，通过差异化的过期时间分散失效点，通过热点数据永不过期保住核心流量，通过熔断降级和互斥锁机制作为系统最后的防线，再结合Redis自身的高可用架构，这样才能构建一个真正健壮的、能抗住冲击的缓存系统，更新策略上的一点点讲究，就能避免全盘崩溃的大麻烦。