Redis雪崩问题到底咋回事，怎么能避免缓存全挂掉的惨剧

Redis雪崩这个问题，说白了就是大量的缓存数据在同一时间集体失效，或者Redis服务本身突然宕机了，导致所有的请求像雪崩一样，瞬间都冲向了后端的数据库，直接把数据库给压垮了，整个系统随之瘫痪，这就像节假日的高速公路收费站，平时所有收费口都开着（缓存正常工作），车流（用户请求）分散通过，很顺畅，突然，绝大部分收费口在同一分钟全部关闭（缓存集体失效），所有车只能挤向唯一还开着的那一两个口（数据库），结果就是高速公路变成了巨型停车场（系统崩溃）。

（根据Redis官方文档及众多技术社区如Stack Overflow、CSDN、InfoQ上的常见讨论） 雪崩通常由两种情况引发：

第一种情况也是最常见的：缓存key大面积同时失效，很多程序员在设置缓存过期时间（TTL）的时候，为了图省事，可能会给一批相关的缓存数据设置成完全相同的过期时间，在每天凌晨0点，系统会批量更新一批热门商品信息到缓存，并统一设置过期时间为24小时，那么到了第二天凌晨0点，这批缓存就会同时失效，如果这时候有大量用户来访问这些商品，系统发现缓存里都没有了，就会同时去数据库查询，数据库短时间内收到海量查询请求，压力陡增，很可能就因为扛不住而响应变慢甚至崩溃，数据库一挂，整个网站或应用就基本上无法使用了,这就是典型的缓存雪崩。

还有一种情况是Redis服务器本身出了问题，如果公司只用了单机的Redis，万一这台机器网络故障、断电或者Redis进程挂掉了，那么所有的缓存服务瞬间就没了，这种情况下，即使缓存数据的过期时间设置得很分散，也照样会发生所有请求都涌向数据库的惨剧,这同样属于雪崩的范畴。

怎么才能避免这种“缓存全挂掉”的惨剧发生呢？其实核心思路就两点：第一，别让大量缓存同时失效；第二，就算Redis部分出问题，系统也要有一定的抵抗能力，不能立马全军覆没,下面说几个具体常用的办法：

最直接有效的一招就是给缓存数据的过期时间加上随机值，这是解决“同一时间大量缓存失效”这个问题的关键，还拿上面商品的例子来说，不要把所有热门商品的缓存过期时间都设成24小时整，可以在基础时间上，比如24小时的基础上，再加上一个随机的几分钟或者负几分钟的偏移量，有的商品缓存24小时+100秒过期，有的24小时-200秒过期，这样，这批缓存的失效时间就被打散了，会分布在一个时间区间内，而不是精准地在同一个时间点失效，这样一来，对数据库的请求就会是陆续到来的，而不是瞬间的洪峰，数据库就有能力逐个处理,避免了被一下子压垮的风险。

可以考虑设置热点数据永不过期，对于一些访问频率极高、几乎时时刻刻都需要的核心数据，比如网站的核心配置、顶级爆款商品信息等，可以直接设置为永不过期，通过后台任务或者程序逻辑，在数据有更新时主动去刷新缓存，这样就从根源上避免了因为过期时间到了而产生的缓存失效问题，这种方式需要维护数据的一致性,确保缓存里的数据是最新的。

第三，搭建高可用的Redis集群，为了防止单点故障导致的整个缓存服务不可用，就不能只依赖一台Redis服务器，可以采用主从复制（Replication）加上哨兵（Sentinel）机制，或者直接使用Redis Cluster集群方案，简单说，就是部署多台Redis服务器，让它们之间互相备份和数据同步，这样，即使主服务器宕机了，哨兵机制也能自动检测到并把一台从服务器切换成新的主服务器，继续提供服务，整个过程对应用程序来说可能是透明的或者影响很小，有了集群，除非是整个机房都挂了,否则Redis服务整体瘫痪的概率就大大降低了。

第四，在应用层做熔断、降级和限流，这是最后一道防线，属于“即使缓存挂了，我也不能让你数据库跟着一起死”的保护策略。

• 熔断机制：可以监控访问数据库的请求，如果发现短时间内失败率非常高（比如超过50%），就启动“熔断”，在一段时间内直接拒绝所有访问数据库的请求，给数据库喘息的机会，在这期间，可以给用户返回一个默认值、友好提示或者空白页面。
• 降级策略：在系统压力巨大、部分服务不可用时，主动关闭一些非核心的功能，保证核心流程还能勉强运行，比如电商网站，在缓存和数据库压力都很大的时候，可以暂时关闭商品推荐、用户积分更新等非关键服务，集中资源保证用户能够完成登录、浏览基本商品信息和下单流程。
• 限流：在系统入口或者服务层面，控制单位时间内能够进入的请求数量，一秒只允许10000个请求访问商品服务，超过这个数量的请求就直接拒绝并返回“系统繁忙”的提示，这就像节假日景区限制入园人数一样，虽然会拒绝一部分用户，但保证了系统内部不崩溃,大部分已进入的用户还能有相对正常的体验。

还可以考虑提前做缓存预热，在预估会有大量请求到来之前（比如大型促销活动开始前），提前把相关的数据加载到缓存中，并合理设置较长的过期时间，这样等流量洪峰真正来临时，大部分数据都能从缓存中获取,极大地减轻数据库的压力。

避免Redis雪崩不是靠单一手段，而是一个组合拳，核心是分散过期时间和构建高可用架构，再配合应用层的保护措施，就能极大地降低缓存全挂导致系统瘫痪的风险，让系统更加稳健。 参考和融合了普遍的技术社区讨论、博客文章如CSDN、掘金、知乎上的常见解决方案，以及《Redis设计与实现》等书籍中关于高可用和缓存策略的理念）