Redis雪崩到底是啥情况，为什么会突然让系统崩溃啊？

Redis雪崩,你可以把它想象成一个非常形象的场景：就像雪山上的积雪，平时好好地待在那里，但可能因为一点动静，比如一声大喊，就突然引发连锁反应，导致大规模、灾难性的雪块崩塌，在系统里，这就相当于Redis这个负责高速数据访问的“仓库”突然之间大面积失灵，导致所有压力瞬间压垮了后端的数据库，让整个系统陷入瘫痪。

具体是怎么一回事呢？为什么会这么严重呢？

雪崩到底是啥情况？

Redis雪崩指的是在同一个时间点或者一个极短的时间段内,大量存放在Redis里的数据同时过期失效，或者Redis服务本身突然宕机，这时，所有原本应该从Redis这个高速缓存中获取数据的用户请求，一下子全都找不到需要的数据了。

这会导致一个灾难性的后果：这些请求不会因为Redis里没有数据就放弃，而是会全部涌向系统的后方——也就是真正的数据源头，通常是MySQL这类数据库，数据库处理请求的速度和并发能力，远远比不上Redis，Redis一秒钟能处理几万甚至十几万个请求，而数据库可能每秒只能处理几千个。

想象一下这个画面：平时有10000个人要进门，Redis这个超级快递员站在门口，直接把东西递给了其中9900个人，只有100个人需要进到屋里（数据库）去取，但现在，Redis这个快递员突然病倒了（数据失效或服务宕机），这10000个人全部都要挤进那个小小的房门，结果可想而知，房门瞬间被挤爆，所有人都卡在门口，谁也进不去，系统就彻底崩溃了，页面打不开，功能无法使用。

为什么会突然让系统崩溃？

雪崩的可怕之处就在于它的“突然性”和“连锁反应”，我们来拆解一下它让系统崩溃的几个关键原因：

1. 瞬间的巨量请求压垮数据库： 这是最直接的原因，正如上面比喻的，数据库根本不是为了应对这种瞬间的极高并发而设计的，当海量查询请求像洪水一样冲过来时，数据库的CPU和内存资源会迅速被耗尽，导致其处理速度急剧下降，甚至完全停止响应，一旦数据库被打垮，所有依赖它的服务都会失效。

   

2. 引发连锁故障： 系统崩溃往往不是单一事件，当数据库开始变慢，那些在等待数据库响应的应用程序线程就会被阻塞住，迟迟得不到释放，而这些线程本身也是系统的宝贵资源（比如线程池里的线程是有限的），很快，线程池被这些“等待中”的线程占满，导致新的用户请求连一个可用的线程都分配不到，直接失败，这样一来，即使数据库后来勉强恢复了一点，应用程序也已经没有能力去处理请求了，故障范围从数据库扩散到了整个应用服务器集群。

3. 资源耗尽导致恶性循环： 在崩溃的过程中，系统会陷入一种恶性循环，大量的请求超时和失败，可能会触发应用程序的重试机制，一个请求失败后，程序自动再试一次，这无异于火上浇油，让本已不堪重负的数据库雪上加霜，进一步加速了系统的崩溃。

那为什么会发生“同时失效”这种事儿呢？

了解了雪崩的后果,我们再来看看常见的诱因，特别是“大量数据同时失效”是怎么发生的：

• 设置相同的过期时间： 这是最经典的人为失误，在项目上线时，为了图方便，程序员给所有缓存数据都设置了一个默认的过期时间，比如24小时，如果系统是在凌晨零点上线的，那么到了第二天凌晨零点，所有这些缓存数据就会在同一秒内全部失效，如果这时有早起的用户或者有定时任务触发，开始访问系统，就会立刻引发雪崩。

  • 参考来源：《Redis开发与运维》一书中明确指出，避免大量key同时过期是预防缓存雪崩的重要原则。

• Redis服务本身宕机： 无论是因为物理机故障、网络问题，还是Redis进程本身出现了严重的bug，导致整个Redis服务不可用，这时，所有请求都会“穿透”缓存，直击数据库，这种情况比数据失效更严重，因为它是100%的请求都会打到数据库上。

• 遭遇突发流量高峰： 电商网站在秒杀活动开始的瞬间，或者社交媒体上某个热点话题爆发时，会涌进来平时几十倍甚至上百倍的流量，如果这些热点数据恰好没有缓存，或者缓存设置不合理，也会导致数据库瞬间压力激增，产生类似雪崩的效果。

Redis雪崩的核心问题在于,系统过度依赖缓存来“保护”后端数据库，却没有为缓存突然失效的情况准备好“后备方案”，当保护层（Redis）出现大面积、同时性的故障时，脆弱的后端（数据库）直接暴露在流量的洪峰之下，最终被冲垮，并引发整个系统的连锁崩溃，解决雪崩的关键思路就是：避免数据集中失效，以及让系统在缓存失效时具备一定的自我保护能力（比如使用互斥锁、设置不同的过期时间、启用熔断机制等）。