【后端开发】(图解)面试官最爱问的缓存三连：缓存穿透/击穿/雪崩到底怎么区分、怎么治理？

🔥 个人主页：铁皮哥（欢迎关注）
📌 作者简介：28届校招生，后端开发/Agent 方向在学
📚 学习内容：Java、Python、计算机视觉、大语言模型、Agent开发
📝 专栏内容：从零开始的Claude Code零代码生活（持续更新中）
✨不只背八股，更想搞懂为什么这样设计

前言

缓存是后端开发中几乎绕不开的一个难题，系统一上并发，数据库扛不住，第一反应往往就是把热点数据放进 Redis；接口一追求响应速度，也总会想到“这块能不能先走缓存”。可缓存这个东西，平时用起来像是在“加速”，真到线上出问题时，很多故障却恰恰也是从缓存开始的。

其中最常被放在一起讨论的，就是缓存穿透、缓存击穿、缓存雪崩。它们都和“缓存失效”有关，但成因不一样、风险级别不一样、治理思路也不一样。

这篇文章不打算停留在对缓存三剑客的概念解释上，而是想把这三个高频问题真正拆开讲清楚：

• 它们到底怎么区分
• 各自通常在什么场景下出现
• 为什么会把数据库拖垮
• 常见治理方案分别解决的又是什么问题

1 缓存穿透

先看一个最简单的读请求流程：

Client → Redis（未命中）→ MySQL（未命中）→ 返回空

如果这个请求只是偶尔发生，其实问题不大。但如果同一个不存在的数据被频繁请求，事情就不一样了：Redis 一直查不到（因为根本没有），然后每一次请求都会直接打到数据库，结果就是缓存这一层完全失去保护作用。

这就是所谓的缓存穿透（Cache Penetration）。

现在想象一个更真实的场景。
假设有一个接口是查用户信息的：

GET /user?id=123456

正常情况下用户存在并且被 redis 命中就会返回数据，但如果有人恶意请求或程序出现了 bug，导致一直有无效查询发过来：

GET /user?id=99999999
GET /user?id=88888888
GET /user?id=77777777
…

这些 ID 在数据库里根本不存在，redis 也根本命中不了，结果每一个请求都要访问数据库，如果请求量一大，数据库就会被这种无效查询给拖垮。

常见的解决方案有两种：缓存空值和布隆过滤器。

1.1 解决方案：缓存空值

缓存空值的思路是即使数据库查不到，也把“空结果”缓存起来。

流程变成：

Client → Redis（未命中）→ MySQL（未命中） → Redis 写入一个空值（短 TTL） → 返回空

之后再查同一个 key：

Client → Redis（命中空值）→ 直接返回

这种方案的优点是实现起来很简单，直接减少重复请求打向 DB。
但是也要注意空值一定要设置较短 TTL（比如几分钟），否则可能影响数据“从无到有”的实时性。

1.2 解决方案：布隆过滤器

布隆过滤器的思路是在请求进入缓存之前，先判断这个 Key 是否“可能存在”。如果判断一定不存在，则直接拦下；如果可能存在，再放行。

流程：

Client → Bloom Filter（判断不存在）→ 直接拒绝
→（判断可能存在）→ Redis → MySQL

这种布隆过滤器方案的优点是可以在最前面拦截大量无效请求，对恶意攻击非常有效。
但是局限是布隆过滤器有误判率，可能把不存在的数据当成存在。另外也要额外维护一个数据集合，增加了复杂性。

关于布隆过滤器我之前写过一篇文章，可以参考：
【后端开发】(图解/面试题)拆解布隆过滤器，为什么它能防缓存穿透？

2 缓存击穿

缓存击穿和缓存穿透名字上有些许相似，但是有很大的不同。缓存击穿查的不是不存在的数据，而是“本来存在，但刚好失效的热点数据”。

典型流程是这样的：

Client → Redis（命中）→ 返回数据 ✅（正常情况）

但某一时刻，这个 Key 过期了：

Client → Redis（未命中）→ MySQL（查询）→ 回写缓存

如果只是一个请求，这依然没问题。问题在于——这个 Key 是热点数据，当它一过期，在缓存重建的过程中可能有成千上万的请求进来，直接打到数据库，数据库被瞬间打穿。

如果这个热点 key 来源于多张表共同计算的结果，那缓存重建的过程就更长了，更容易出现问题。

常见的解决方案有两个：互斥锁和逻辑过期。

2.1 解决方案：互斥锁

互斥锁就是在第一次查缓存未命中时，该线程取走锁，并去执行缓存重建。在重建结束之前，其他线程发现锁已被取走，就阻塞一段时间后重新查询缓存，直至命中为止。

互斥锁方案的流程是这样的：

请求A → 获取锁 → 查询DB → 回写缓存 → 释放锁
请求B/C/D →获取锁失败→ 等待

这种方案的优点是能从根本上避免“并发回源”，但是注意要防止死锁（设置过期时间），同时等待策略要设计好（自旋 / 降级）。

2.2 解决方案：逻辑过期

逻辑过期就是对于热点 key，物理上不立刻删除缓存，业务上通过过期字段判断它是否该被更新。

缓存过期的方案是这样的：

读取缓存 → 判断是否逻辑过期 → 未过期 → 直接返回
→ 已过期 → 返回旧数据 + 异步更新缓存

因为对用户请求来说，缓存并没有真的在 Redis 里消失，所以不会出现“所有请求同时 miss”的情况。真正的更新动作，通常只交给少量后台线程或抢到锁的请求去做。

这种方案的优点是对于高并发热点数据非常有用，但是要注意的是用户可能会在短时间内读到旧数据。

互斥锁和逻辑过期通常是一起使用的。

3 缓存雪崩

缓存雪崩其实就是同一时段大量的缓存key同时过期失效，或Redis服务宕机(近似所有key都失效)，导致大量请求到达数据库，带来巨大压力。大量原本应该被缓存拦住的请求，在同一时刻或极短时间内，成批地涌向下游系统。

典型流程是这样的：

大量请求 → Redis（大面积 miss / 不可用）→ 全部打到 MySQL ❗

缓存雪崩通常不是“偶然事件”，而是某些设计或异常导致的结果。

经典的发生场景如大量 Key 同时过期。比如你在某次上线时，批量写入缓存，所有 Key TTL = 30 分钟，那么 30 分钟之后一大批缓存同时失效，所有请求同时 miss，数据库瞬间承压。

再比如缓存服务出现了异常。redis 宕机了，所有请求都无法命中缓存，系统等价于没有缓存层，流量全部打到数据库。这类情况比大量 Key 同时过期更危险，因为是全量失效。

常见的解决方案有两种：给过期时间加随机值和做多级缓存。

3.2 解决方案：给过期时间加随机值

在同一时间批量写入缓存时，不要这样设置：

所有 Key TTL = 1800s

而是这样：

TTL = 1800s + 随机值（0~300s）

这样一来原本同一时刻过期的 Key 被打散到一段时间内，请求压力从“瞬时洪峰”变成“平滑流量”，这种方案非常简单同时也很有效。

3.3 解决方案：做多级缓存

在 Redis 之外，再加一层：

Client → 本地缓存（如 Caffeine）→ Redis → MySQL

当 Redis 出问题时，本地缓存还能兜住一部分流量，这样可以避免所有请求直接打到数据库。

写在文后

期待您的一键三连！如果有什么问题或建议欢迎在评论区交流！