Redis 缓存穿透、击穿、雪崩有什么区别？分别怎么解决？
🧑💻 面试官：商品接口突然把数据库打满了，缓存穿透、击穿、雪崩怎么区分？
🙋♂️ 我：穿透通常是查不存在的数据，击穿是热点失效，雪崩是大量缓存同时出问题。
🧑💻 面试官：只要加随机过期时间，三种问题都能解决吗？
🙋♂️ 我：随机过期主要分散失效时间，挡不住反复查询不存在的商品。
🧑💻 面试官：那热点回源加了锁，数据库没被打满，但几千个请求都在等锁。这样就算解决了吗？
三个名字背后都是回源压力，但要先找清楚「为什么没命中、影响多少请求」，才能选对处理方式。
面试速答（60 秒版）
缓存穿透、击穿和雪崩，都可能让请求大量访问数据库，但触发原因不同。
穿透通常是反复查询本来就不存在的数据，缓存和数据库都没有结果。可以做参数检查、短期空值缓存，必要时用布隆过滤器提前筛选。
击穿是某个热点缓存失效以后，大量请求同时回源。可以合并同一热点的重建请求，让一个请求查询，其他请求有限等待，或者在允许旧数据的场景使用旧值。
雪崩则是大量缓存集中失效，或者缓存服务整体不可用。随机过期能分散集中到期，但服务故障还需要限流、降级与回源保护。
因此，不能只加一把锁或随机 TTL 就认为解决了。还要检查数据库承载、等待上限，以及哪些数据允许暂时返回旧值。
知识点详解：一次商品查询，在哪种情况下会打到数据库？
正常情况下，缓存怎样工作？
假设用户查询商品详情。应用先查 Redis，命中就返回；没命中，再查数据库，并把结果写回缓存。
这种 Cache-Aside 模式很常见，但缓存未命中本身并不是故障。需要关注的是：未命中以后，有多少请求同时访问数据库，以及它能否承受。微软的 Cache-Aside 说明介绍了基本读写方式与过期选择。
穿透：这个商品压根不存在
假设有人不断查询商品 999999，而数据库没有这件商品。每次 Redis 查不到，数据库也查不到，如果应用只缓存存在的商品，下一次还是同样的流程。
首先可以检查编号格式和合理范围，挡掉明显不合法的请求。对于格式合法但不存在的商品，可以短期缓存“未找到”，避免反复回源。
不过，新商品刚创建时，旧的空值缓存可能挡住它，因此要考虑主动失效或较短有效期。空值还要和网络错误区分，数据库超时不能被缓存成“商品不存在”。
数据量大时，可以使用布隆过滤器。它回答“不在集合中”或“可能在集合中”，后者仍需要继续查询。过滤器本身存在误判可能，业务数据更新也要正确维护，不能把“可能存在”当成确定存在。Redis 的布隆过滤器说明解释了这一性质。
击穿：一个热点商品突然到期
假设促销商品的缓存失效，几千个请求几乎同时发现没有缓存。商品确实存在，但这些请求一起查数据库，就把同一份数据重复读了几千次。
这里要合并的是“重建同一个 key”的工作。一个请求取得重建资格以后，再确认缓存是否仍为空，然后查询数据库并回填。其他请求只等待有限时间，再读缓存或按规则降级。
如果服务有多个实例，仅进程内锁只能合并本实例的请求，跨实例还需要相应机制。同时，等待者不能无限堆积：锁保护了数据库，却可能把应用线程和连接全部耗尽。
允许短暂旧值的商品描述，可以采用提前刷新或旧值配合后台重建。库存、价格等对时效要求较高的数据，则不能未经业务确认就使用同一策略。
雪崩：很多 key，甚至整个缓存入口都出问题
假设批量预热的商品都设置了相同 TTL，它们可能集中到期。给过期时间加适度随机值，可以把重建压力分散开。
但如果 Redis 服务不可用，所有 key 的到期时间再随机也没用。应用需要限制回源并发、限制请求队列，按业务提供降级结果，必要时拒绝部分请求，不能让所有流量直接涌向数据库。
多级缓存可以降低影响，但也会带来不同副本的数据一致性和容量问题。它是可选择的保护层，不是缓存故障以后自动安全的保证。
面试官继续追问
给所有查询加锁，是不是最保险？
不合适。不同 key 的查询没有必要互相等待，把它们锁在一起反而降低吞吐。
同一个热点的重建可以合并，但锁还要有持有者标识、有效期和失败处理。查询超时后是否重试、等待者什么时候退出，都需要明确。
怎样判断是三种问题中的哪一种？
看未命中的 key 分布、数据库查询结果和缓存服务状态。
大量不存在的编号指向穿透；一个或少数热点集中失效，更像击穿；很多 key 同时未命中或 Redis 整体报错，要检查雪崩与服务故障。它们也可能同时发生，不需要为了名字强行只选一个。
怎么验证保护真的有效？
压测不存在编号、热点到期和缓存不可用三种情况。
检查数据库回源峰值、应用排队和超时、返回结果的时效，以及缓存恢复后能否正常重建。不能只看到数据库不再过载，却漏掉用户全部等到超时。
面试速记卡
- 穿透：不存在的数据反复回源，检查参数与空值处理。
- 击穿：少数热点失效，合并重建并限制等待。
- 雪崩：大范围失效或服务故障，分散过期并保护回源。
- 布隆过滤器：可能存在仍需查询，不提供精确存在证明。
- 验收重点：数据库压力、应用等待与数据时效一起检查。