第2章 缓存穿透、雪崩、击穿 —— 面试高频经典问题精讲

面试问题：如何解决缓存穿透问题？

考察点：是否理解穿透的本质（大量请求 key 不存在）；能否给出有数据支撑的方案；是否会考虑限流/降级。

回答框架：定义+原因 → 方案一（布隆过滤器）、方案二（缓存空值）、方案三（参数校验）→ 对比选型（误判率 vs 内存开销）→ 结合业务举例。

示例回答：“缓存穿透指请求命中不存在 key 导致 DB 被打穿。我会优先使用布隆过滤器，将合法 key 提前预置，要求误判率 ≤1%。对少量穿透请求缓存空值 TTL 60s，同时配合参数校验拦截非法 ID。在电商商品详情页，我们曾用此方案将 DB 峰值 QPS 从 5k 降到 200。”

可能追问：布隆过滤器如何删除元素？误判率如何计算？空值缓存的内存膨胀如何控制？

避坑提醒：⚠️ 不要只提布隆过滤器，忽略空值缓存和限流兜底；避免说“布隆过滤器无删除操作”（实际可通过 Counting Bloom Filter 或 Redis Module 解决）。

面试问题：缓存雪崩的成因与应对方案有哪些？

考察点：是否区分雪崩与击穿；是否理解“同时失效”的根因；能否给出多级缓存/限流/降级等组合方案。

回答框架：定义→原因（同一时间大量 key 过期 / 缓存节点宕机）→ 方案一（过期时间加随机值）、方案二（多级缓存）、方案三（限流+熔断）、方案四（集群高可用）→ 落地细节。

示例回答：“雪崩是大量 key 同时过期或 Redis 挂掉导致 DB 被打垮。实践中我会给 TTL 加 5%~20% 随机偏移，并部署 Redis 哨兵/集群确保高可用。在秒杀场景还配置了本地缓存作为 L1，再通过 Sentinel 限流保护 DB。曾让 DB 成功率从 60% 提升到 99.9%。”

可能追问：本地缓存如何保证数据一致性？限流阈值如何设定？Redis 集群脑裂如何处理？

避坑提醒：⚠️ 避免只说“加随机过期时间”，要提到多级缓存和限流；别提“所有 key 错开过期”但忽略节点宕机场景；避免对一致性要求高的业务用本地缓存。

面试问题：热点 key 缓存击穿如何解决？

考察点：是否理解“热点 key 瞬间过期”场景；能否设计互斥锁或永不过期+异步更新机制；是否考虑分布式锁的性能开销。

回答框架：定义→原因（单个热点 key 过期 + 高并发）→ 方案一（互斥锁 SETNX）、方案二（逻辑过期 + 后台异步更新）、方案三（分布式锁优化：分段锁）→ 根据读多写少/写多读少选择。

示例回答：“击穿指单个热点 key 过期后大量并发击穿 DB。我对读多写少的场景用互斥锁，缓存回填后释放；对写频繁的场景使用‘逻辑过期’——key 永不过期，后台线程检查 TTL 并更新。在微博热搜中，我们用此方案将 99% 请求命中缓存，DB 负载下降 80%。”

可能追问：互斥锁模式下如何防止死锁？逻辑过期可能读到脏数据如何解决？热点 key 的发现机制如何实现？

避坑提醒：⚠️ 不要只答“加分布式锁”，要分析锁粒度与性能；避免在写密集场景使用互斥锁（可能超时）；逻辑过期方案中务必补充一致性补偿策略。