定义：请求的数据既不在 Redis 缓存，也不在数据库，导致每次请求都穿透缓存直接打到数据库，数据库压力骤增。 科技新闻。
定义：大量 key 同时过期，或者Redis 集群整体宕机，导致所有请求都打到数据库，数据库雪崩式崩溃。
“最后是 ❄️ 缓存雪崩，这个破坏力最大。
介绍背景与起因
一般是两种场景叠加：大量 key 在同一时间过期，或者 Redis 突然挂掉。
“总结对比一下？”
我可以结合画图，逐个说一下原理和落地方法吗？”
介绍事件经过
最典型的是秒杀商品，key 为 hot_item:123。一旦这个热点 key 失效，刚好又赶上高并发，瞬间所有请求都奔向数据库去抢着重建缓存。
技术亮点：
介绍各方回应
技术亮点：
“好的，我用一个表格串一下：
“没问题，面试官。我按场景来贴代码，顺便把难点和亮点都说明白。😄”
伪代码大概这样：
介绍影响分析
“我会包装一层对象，比如 HotDataWrapper，里面两个字段：data 和 expireAt（逻辑过期时候戳）。取出来先判断 expireAt < now，如果过期了，先用旧数据返回，同时开一个线程去抢锁重建。”
“不错，整体框架很清晰，方案能落地。我追问一个点：你用互斥锁的时候，如果业务是集群部署，SETNX 锁要是业务执行超时或者节点宕机了，会不会死锁？怎么解决？”
“好的，先说 🔍 缓存穿透。
技术亮点：
“嗯，方案都说得挺清楚。那你能不能贴几段核心代码，展示下技术亮点？然后把这一整套场景中的技术难点和解决方案整理一下？”
生产上，我一般布隆过滤器前置拦截 + 空值兜底，双保险。”
“那如果用逻辑过期，value 里怎么存？”
“确实有死锁风险。我会给锁加一个过期时刻，并且用 Redisson 的看门狗机制自动续期——只要线程还活着，锁就不会超时释放；如果节点真挂了，锁也会在到期后自动放开。不会出现死锁解不掉的情况。”
我先快速区分一下：
比如有人恶意用 id = -1 不断请求，这个数据库里根本没有，缓存里也不会有，每次请求都打到库上。
“再说 💥 缓存击穿。
“可以，思路到位。最后说说雪崩吧。”
“可以，你边画边讲。”
“同学，前面基础知识聊得不错。现在来个场景设计题：介绍一下 Redis 的缓存穿透、击穿、雪崩，最好能说清楚它们的区别和解决方案。你可以开始了。”
技术亮点：过期时间加随机盐 + 多级缓存兜底（Caffeine）。
技术亮点：布隆过滤器 + 空值缓存双保险，兼顾性能和防穿透。
技术亮点：使用 Redisson 分布式锁 + 看门狗自动续期，避免死锁，保障高并发。
“好的面试官。这三个问题本质上都是缓存没挡住流量，导致大量请求砸到数据库，但触发原因不一样，解决方案侧重点也不同。
定义：单个热点 key 突然过期，瞬间有大量并发请求打到数据库，数据库瞬间被打垮。
“嗯，逻辑清晰。那击穿呢？”
“很好，代码细节到位，难点拆解得也清晰。你这种把代码和方案能对应讲出来的习惯，是面试加分项。这场缓存三兄弟的考察，给你 Strong Hire ✅。”，引发了热烈讨论。
