Redis 面试高频题：缓存雪崩到底是什么？四种解决方案一次讲清

先给结论：

缓存雪崩，说的是大量缓存数据在同一时间失效，或者缓存服务整体不可用，导致大量请求绕过缓存直接访问数据库，最终把数据库压垮。

说白了，它跟"单个 key 出问题"不是一回事，而是成片地崩。

那问题来了——好好的缓存，怎么就"成片"失效了？

原因其实就两类。

第一类，是大量 key 在同一时刻过期。

原因在于：

当初给这些 key 设缓存时，用的是同一个过期时间。

比如大促商品页统一设 30 分钟过期，到点那一刻几万个 key 一起消失，请求瞬间全打到库上。

这一类最好治。

既然是"过期时间撞车"导致的，那就让它们错峰过期。

做法很简单：

在原本的失效时间上，叠加一个随机值，比如 1~5 分钟的随机偏移。

这样每个 key 的过期时间被打散，可以大幅降低大量 key 同时失效的概率。

第二类原因，是 Redis 自己挂了。

服务宕机，缓存整体不可用，请求自然全涌向数据库。

这一类要从"让 Redis 别挂、挂了也能顶住"入手，下面给三招。

解法二：上 Redis 高可用集群。

单点最怕的就是"一挂全完"。

换成哨兵模式或集群模式，节点互相兜底，一台宕机还有别的顶着，缓存整体不塌。

解法三：降级限流做保底。

在系统入口拦一道：

如果是单体应用，可以在 Nginx 层做限流；

如果是微服务，就把限流规则配在 Spring Cloud Gateway 网关上。

流量被挡掉一部分，数据库就不会被冲垮。

解法四：多级缓存。

再往前叠一层本地缓存：

用 Caffeine、Guava 这类本地缓存做一级缓存，Redis 做二级缓存。

请求先打本地、再打 Redis、最后才回数据库。

即便 Redis 这一级出事，本地缓存还能顶一阵，雪崩就被拆成了小浪花。

不过本地缓存更适合缓存热点数据，对于强一致性要求高、变化频繁的数据，需要谨慎使用。

到这里，四种解法就齐了。

用一句话总结一下就是：

大量 key 同时过期 → 加随机过期时间；

Redis 宕机 → 高可用集群 + 限流降级 + 多级缓存。

需要注意的是，实际生产中通常会组合使用，而不是只依赖某一种方案。

最后补一句关键的：

在缓存穿透、击穿、雪崩这"三兄弟"里，限流降级是通用的保底手段。

前面几种解法各有侧重，但真到了极端情况，限流兜底是最后一道防线——这三个问题，最终都能靠它保命。

最后多句嘴，缓存雪崩核心就一句：

别让 key 一起死，也别让 Redis 孤身扛，错峰 + 集群 + 限流 + 多级，四管齐下。