Redis雪崩和击穿问题到底怎么破，真不是一两招能解决的复杂事儿

关于Redis的雪崩和击穿问题,网上确实有很多文章，但很多都说得太简单，好像加个过期时间或者用个锁就能搞定，在生产环境中，这俩问题非常棘手，需要一套组合拳来应对，而且没有一劳永逸的“银弹”，下面我们就来详细拆解一下，为什么它们复杂以及到底该怎么破。

得把雪崩和击穿分清楚，这是解决问题的第一步。

（来源：多数技术社区和博客文章的基础定义） Redis缓存击穿，指的是某一个非常热点的数据（比如某个顶流明星的新闻详情）突然过期了，或者从一开始就没被缓存，就在它失效的那个瞬间，海量的用户请求直接绕过了Redis，像一根针一样直接刺穿了缓存，全部打到了后端的数据库上，数据库短时间内承受不住这么高的并发查询，可能直接就挂掉了。

而Redis雪崩,情况更严重，它不是某一个热点key失效，而是大量的key在同一时间点或者短时间内集体失效，想象一下，你给缓存数据设置的过期时间都是默认的30分钟，结果在某个时间点，系统初始化时缓存的那一大批数据同时到期，这时候，大量的请求发现缓存里没数据了，就会同时涌向数据库，这个流量洪峰就像雪崩一样，瞬间就能把数据库压垮，雪崩比击穿的破坏范围更大。

我们看看为什么解决它们不能只靠一两招。

对付缓存击穿，常见的“神招”是加锁（比如互斥锁）。 （来源：分布式系统常见解决方案思路） 思路是：当第一个发现缓存失效的请求到来时，它先去抢一个锁，抢到锁的线程负责去数据库查询数据并回填到Redis，其他没抢到锁的请求就等着，要么隔段时间重试，要么直接返回默认值，这听起来很完美对吧？但问题马上就来了：

1. 锁本身成了瓶颈： 如果这个热点key的热度超高，比如每秒几十万请求，那么抢锁这个操作本身就会成为一个新的单点瓶颈，可能拖慢整个系统。
2. 死锁风险： 如果那个抢到锁的线程在查询数据库或者写Redis的时候挂掉了，没能及时释放锁，那么其他所有线程就会一直等下去，导致整个服务不可用。
3. 用户体验： 等待的请求会有延迟，虽然比数据库挂掉好，但也不是最佳体验。

单纯加锁不行,我们得优化，可以使用“逻辑过期”的方案，不给热点数据设置真实的物理过期时间，而是把它和一個过期时间戳一起存入缓存，请求来时，先判断是否逻辑过期，如果过期了，同样抢锁，但抢到锁的线程会开启一个异步线程去更新数据，自己则返回旧的、可能稍微过时一点的数据，这样既保证了不会所有请求都打到数据库，又避免了用户长时间等待，你看，这就不是一招了，而是“逻辑过期+互斥锁+异步更新”的组合拳。

对付缓存雪崩，教科书会告诉你“设置不同的过期时间”。 （来源：几乎所有Redis最佳实践指南） 在给缓存设置过期时间时，不要都设成30分钟，而是用一个基础时间加上一个随机的偏移量，比如30分钟加上一个0到5分钟的随机数，这样就能保证key不会在同一时间点大量失效，而是均匀地分布在一段时间内，从而避免了流量洪峰。

但这个办法就够了吗？远远不够，因为它只能预防“同时过期”引发的雪崩，如果遇到Redis集群某个主节点宕机（比如机房网络故障），导致整个集群部分数据不可用，这时候大量请求同样会涌向数据库——这是一种更可怕的“雪崩”，面对这种情况，设置随机过期时间就无能为力了。

我们需要更高级的防御工事：

1. 保证Redis服务本身的高可用： 采用主从复制+哨兵模式，或者直接使用Redis Cluster集群，这样即使个别节点宕机，也有备用节点能顶上来，服务不会中断，这是从根源上减少雪崩发生的概率。
2. 服务熔断和降级： 在业务系统和后端数据库之间增加一层保护，当系统检测到访问数据库的请求异常比例过高时，可以自动“熔断”，在一段时间内直接拒绝掉部分请求（返回一个友好的提示页面），给数据库喘息的机会，或者，返回一些默认的、非核心的数据，这就是“降级”，这需要引入像Hystrix、Sentinel这样的组件。
3. 提前预热： 对于一些能预知的高并发场景，比如秒杀活动、春节抢红包，要提前把相关的热点数据加载到Redis中，并确保它们的过期时间设置得合理，不会在活动期间失效。

你会发现，无论是击穿还是雪崩，其核心都是“大量请求直接访问数据库”，解决它们绝不是一个开关、一行配置就能搞定的，它需要一个立体的、从缓存本身到业务架构的全面考虑：

• 针对击穿： 你要在“互斥锁”的基础上，考虑如何避免锁瓶颈、保证可用性，结合“逻辑过期”等策略来平衡一致性和性能。
• 针对雪崩： 你既要通过“随机过期时间”解决key同时失效的问题，更要通过“Redis高可用集群”防止服务宕机，还要有最后的防线——“服务熔断降级”来保护数据库不被冲垮。

所以说,这真不是一个简单的事儿，它考验的是开发者和架构师对整个系统链路的深刻理解，以及根据实际业务场景灵活运用多种技术手段的能力，没有最好的方案，只有最适合当前情况的方案。