Redis雪崩的核心原理：大量key同时过期，导致请求全部打到DB，DB挂掉。应对策略：1.给缓存设置不同TTL；2.热点key永不过期；3.限流降级；4.多级缓存；5.预热缓存；6.后台异步重建缓存。一张图总结：用户请求→缓存miss→DB雪崩→服务瘫痪。预防路径：随机TTL→部分miss→DB可扛→服务正常。

什么是Redis雪崩

缓存雪崩是指由于缓存失效或缓存节点全部宕机，导致大量请求直接访问数据库，瞬间打垮数据库。我们把缓存击穿和缓存穿透也归为雪崩范畴。缓存雪崩：大量热点key同一时间失效，缓存全部失效，请求打到db，db压力剧增，乃至宕机。图解：时间轴上，众多key同时过期，流量峰值直冲db。

雪崩原理图解

正常流程：用户请求→查Redis→命中返回数据；雪崩场景：Redis key批量过期→大量请求同时miss→全部查询后端数据库→数据库瞬间负载过高→服务不可用。示意图：左侧正常箭头流畅，右侧雪崩时箭头全部汇聚到DB，形成爆炸状。

应对策略一：TTL随机化

解决方案1：给缓存设置不同的失效时间，比如随机化TTL，避免同一时间大量key同时失效。这样即使部分key失效，也不会全部雪崩到后端。

应对策略二：多级缓存

解决方案2：使用多级缓存结构，如本地缓存（guava）+ 分布式缓存（redis）。本地缓存命中率高，速度快；未命中再查redis，减少redis压力。图中：用户→本地→redis→db，层层过滤。

应对策略三：热点数据永不过期

解决方案3：对热点key设置永不过期，或定期异步刷新。同时设置逻辑过期时间，到期后后台异步重建。防止热点key失效引发雪崩。

应对策略四：限流与降级

解决方案4：在网关层或服务层加限流熔断（如Sentinel、Hystrix），雪崩发生时直接降级返回空数据或默认数据，保护后端数据库。配合降级策略，快速恢复。

其他预防措施

预热：系统启动时预先加载热点数据到缓存。后台重建：缓存失效后，异步线程去DB重建缓存，并设置短TTL。监控告警：实时监控缓存命中率、QPS，异常时告警。最终一张图：左侧雪崩路径（红线），右侧多策略防护（绿线）。

FAQ
Q: Redis雪崩和缓存击穿有什么区别？
A: 雪崩是大量key同时失效，击穿是单个热点key失效导致大量请求打到DB。
Q: 如何实现TTL随机化？
A: 设置key过期时间为基准时间+随机值，如 baseTTL + random(0, 300)。
Q: 本地缓存适合什么场景？
A: 读多写少，高频访问数据，本地一致性要求不高。
Q: 雪崩发生后怎么快速恢复？
A: 先限流降级，然后异步重建缓存，最后逐步放量测试。