什么是缓存雪崩、缓存击穿和缓存穿透？怎么解决？
三种故障的成因不同，应分别从无效键、热点单键和大面积同时失效设计防护，并保留数据库保护线。
直接结论
缓存穿透是大量请求查询本就不存在的数据，缓存持续未命中并打到后端；缓存击穿是某个高热键失效时并发请求集中回源；缓存雪崩是大量键同时失效或缓存服务整体异常，造成后端负载骤增。治理不能只答“加锁”：穿透可用参数校验、负缓存或 Bloom Filter；击穿可用请求合并、互斥重建、逻辑过期和热点预热；雪崩要错开过期时间、限流降级、提升缓存高可用并保护数据库。
原理与步骤
Cache-Aside 模式下应用先读缓存，未命中再读数据源并回填，因此回填竞争、过期和一致性都由应用策略承担。负缓存把不存在结果短期保存，但要防止以后创建的数据被旧空值遮蔽；Bloom Filter 可快速排除大概率不存在的键，却存在假阳性且需要维护。随机抖动只减少同批键同刻过期，并不能解决节点故障。请求合并应限定等待时间和失败传播，避免一把全局锁把所有键串行化。
工程场景
商品详情可对不存在商品缓存短 TTL 的空结果，并在入口校验 ID；爆款商品在到期前异步刷新，回源由按键单飞控制；批量活动缓存设置分散过期并预热。数据库侧仍需连接池上限、查询超时和熔断，缓存不可用时优先返回可接受的陈旧值或降级内容。监控要按命中率、回源 QPS、热点键、重建耗时、淘汰率和后端饱和度联动，不能只盯整体命中率。
验证与边界
Bloom Filter 不是权限校验，也不能保证“存在”；删除数据后过滤器更新、容量估计和误判率都要设计。逻辑过期会返回陈旧数据，必须有业务可接受窗口；强一致余额类数据不应套用同样方案。缓存淘汰与 TTL 到期是不同机制，内存策略可能在 TTL 前驱逐键。演练应模拟单热点到期、批量过期、缓存节点不可达和慢回源，验证后端是否被限住以及恢复时是否产生二次流量峰值。
答题练习
- 1穿透击穿雪崩成因分开
- 2按键合并而非全局锁
- 3缓存之外仍需保护数据库
常见错误
- 用一个加锁答案覆盖三类问题
- 把 Bloom Filter 当成绝对存在判断
可能追问
- 逻辑过期如何控制陈旧窗口
- 缓存恢复时怎样避免流量再冲击
来源记录
- 原始来源
- 小林coding
- 来源页面
- 理想 Java 面试
- 最近收录
- 2026-07-05
- 官方复核
- Microsoft Learn、Redis 官方文档