大促期间缓存同时过期，数据库流量瞬间上涨几十倍，你会怎么区分并处理穿透、击穿和雪崩？
我的判断
大促回源暴涨要先看 key 是否存在、是不是单个热点失效、还是大量 key 同时过期，再分别处理穿透、击穿和雪崩。
我会先从缓存命中率、miss key 分布、过期时间和数据库 Top SQL 判断类型。穿透 是请求的 key 本来就不存在，常见于恶意随机 ID；做参数校验、Bloom Filter 和短 TTL 空值缓存。击穿 是一个热点 key 过期，瞬间大量并发回源；用逻辑过期、单飞加载或互斥重建，并保证等待有超时。
雪崩 是大量 key 同一时间失效或 Redis 整体不可用。TTL 加随机抖动只能解决前一种；节点故障还需要多副本、客户端超时、限流和降级数据。
已经在事故中时，会先保护数据库：限制回源并发、关闭非核心查询、返回可接受的旧缓存或默认值，后台分批预热热点，不能让每个请求都参与重建。
恢复后会检查是不是批量发布时把 TTL 写成同一秒、缓存版本切换导致全 miss，或者某个大 key 重建太慢。只有分类正确，方案才不会互相干扰。
容易答偏踩坑误区
- 所有问题都靠 TTL 随机化。 它挡不住恶意不存在 key 和节点故障。
- 分布式锁内慢慢查库。 锁持有者失败时热点请求会长时间排队。
- 缓存挂了就完全绕过。 数据库通常承受不了缓存前的原始并发。