缓存三大经典问题：穿透、击穿、雪崩的工程化防护

三种故障，三种根因，别混着防

缓存体系的三类经典故障经常被混为一谈，但根因完全不同：穿透是「查不存在的数据」（请求绕过缓存直打数据库）；击穿是「热点 key 恰好过期」（瞬间高并发全打到 DB）；雪崩是「大批 key 同时失效或缓存集群宕机」（DB 被洪峰冲垮）。防护矩阵必须分开设计，一套方案包打天下必然顾此失彼。一、穿透：把「不存在」也缓存住

1. 空值缓存：DB 查不到时，在缓存写一个短 TTL（30~60 秒）的空标记，同 key 的后续请求被缓存挡住——简单有效，成本是少量无效 key 占用；
2. 布隆过滤器：在缓存前加一层布隆过滤器，把全量合法 key 预热进去，「过滤器说不存在」的一定不存在，直接拒绝。适合 key 集合相对固定（商品 ID、用户 ID）的场景；注意布隆过滤器有误判率（说存在的可能不存在），且删除困难，重建要预设计划；
3. 请求侧风控：穿透往往来自恶意扫描（遍历 ID 段），网关层对单 IP/单用户的高频 miss 限流，比在缓存层硬扛更划算。

二、击穿：热点 key 的「永不过期」策略

1. 逻辑过期：热点 key 物理上不设 TTL，value 里带逻辑过期时间；发现逻辑过期后由一个线程去重建，其他线程继续用旧值——牺牲一点实时性，换来零击穿；
2. 互斥重建：过期后只放一个请求去 DB 加载（Redis SETNX 锁 + 短等待），其余请求自旋等待或返回旧值。实现简单，但要防锁未释放的死等；
3. 热点探测：通过访问统计识别 Top 热点 key，提前预热并延长 TTL；大促前对已知热点（爆款商品）做人工预热是标准动作。

三、雪崩：打散失效时间 + 双层兜底

1. TTL 加随机抖动：批量写入的 key 统一 TTL 加 0~300 秒随机偏移，避免同一时刻集中失效——一行代码消灭最常见的雪崩源；
2. 多级缓存：本地缓存（Caffeine）+ 分布式缓存（Redis）双层，Redis 抖动时本地层兜住读流量；
3. DB 侧限流兜底：真到缓存全挂的时刻，DB 前的连接池上限 + 限流就是最后防线——宁可部分请求失败，不能让 DB 被打挂导致全站不可用；
4. 集群高可用：Redis 主从 + 哨兵/集群模式，故障自动切换；切换期间的部分失败要有降级预案（读旧数据/静态兜底页）。

四、验收：用故障演练验证

防护写完要演练：模拟空值批量请求（验穿透防护）、删除热点 key（验击穿防护）、重启 Redis（验雪崩兜底与恢复时间）。没有演练过的防护，和没有一样。

缓存防护的本质是「为失败设计」：默认假设缓存会 miss、会过期、会宕机，然后为每一种失败准备好提前量。三张防护矩阵表贴在监控面板旁，比事后复盘有用得多。