Redis 缓存穿透、击穿、雪崩，我花了 3 年才分清它们的区别

2026/6/26 14:15:45

面试时被问到"Redis 缓存穿透、击穿、雪崩有什么区别"，我支支吾吾答不上来。工作三年后，终于在实际项目中把这三个概念搞清楚了。

不是我不爱学习，是这三个名字太像了，网上很多文章也讲混了。我用自己的踩坑经历，帮你彻底分清。

缓存穿透：查询一个不存在的数据

场景：用户查询一个数据库里根本没有的 key，比如 id=-1 的商品。

问题：每次查询都会穿透缓存，直接打到数据库。如果恶意攻击者构造大量不存在的 key，数据库会扛不住。

我的踩坑：早期项目没做校验，有人用脚本批量请求不存在的商品 ID，数据库 CPU 飙到 90%。

解决方案：布隆过滤器，或者缓存空值（设置较短的过期时间，比如 5 分钟）。

缓存击穿：一个热点 key 过期了

场景：某个 key 访问量极高，比如首页的商品列表。这个 key 过期的一瞬间，大量请求同时打到数据库。

问题：不是查询不存在的数据，是查询存在的数据，但缓存刚好失效。

我的踩坑：双十一活动页，缓存设置了 10 分钟过期。过期那一刻，数据库直接挂了。

解决方案：互斥锁（只有一个线程去查数据库，其他线程等待），或者逻辑过期（不设置 TTL，用逻辑时间判断）。

缓存雪崩：大量 key 同时过期

场景：缓存重启、或者批量设置了相同的过期时间，导致大量 key 在同一时间失效。

问题：和击穿类似，但规模更大。不是单个 key，是成片 key 同时失效。

我的踩坑：项目上线时，为了"预热缓存"，一次性加载了 10 万个 key，全部设置了 1 小时过期。1 小时后，数据库被瞬间打爆。

解决方案：过期时间加随机偏移（比如 1 小时 ± 10 分钟），或者多级缓存（本地缓存 + Redis）。

一句话总结

面试时的回答技巧

不要背定义，讲场景。面试官想听的是：你在什么情况下遇到过，怎么解决的。

我现在的回答结构是：场景描述 → 问题现象 → 解决方案 → 后续预防。

你们在实际项目中遇到过哪种？

我查了下，很多公司的缓存策略其实是"混着用"的，没有严格区分这三种情况。是不是只有大厂才会精细化处理？

最新新闻