缓存雪崩主因是大量key集中过期或Redis宕机，应对策略包括均匀设置过期时间、互斥锁、双key策略和后台更新缓存。
Redis 本身不记录“哪个驱逐操作直接引发了缓存雪崩”，它只按策略（如 volatile-lru、allkeys-random 等）被动淘汰键，也不会主动上报“我刚删了这 10 万个 key”。所谓“驱逐导致雪崩”，本质是多个业务关键 key 在相近时间被集中驱逐或过期，而应用层又没做兜底保护。定位源头必须靠**外部协同观测**，而非依赖 Redis 自身日志。
Redis 的 INFO stats 和 INFO memory 能提供什么线索
这两个命令返回的指标是基础但关键的入口：
-
evicted_keys：累计被驱逐的 key 总数，突增说明内存压力大，但无法对应到具体 key 或时间点 -
expired_keys：累计过期 key 数，和evicted_keys同时飙升，大概率是过期集中触发的雪崩前兆 -
used_memory_peak_human和mem_fragmentation_ratio：判断是否因内存碎片或峰值超限触发了被动驱逐 -
maxmemory_policy：确认当前用的是哪种淘汰策略，比如volatile-ttl容易在批量过期时集中清理，比allkeys-lru更危险
应用端埋点必须捕获的三个时间戳
仅靠 Redis 指标只能看到“发生了什么”，要定位“为什么是这些 key”，应用代码里必须在缓存读写路径上打点：
- 缓存读取时发现 miss，记录：
key、miss_time（毫秒级）、cache_type（如 user_profile、order_list） - 从 DB 加载成功后写入缓存时，记录：
key、db_load_time_ms、ttl_seconds（实际设置的过期时间）、set_time - 捕获
redis.exceptions.ConnectionError或TimeoutError，并关联最近 5 秒内所有 miss 的 key 列表 —— 这往往是 Redis 不可用引发雪崩的直接证据
注意：ttl_seconds 必须是写入时真实传入的值，不能硬编码；如果用了随机偏移（如 base_ttl + random(0, 300)），埋点里也得记下这个偏移量，否则无法回溯“为什么这批 key 几乎同时到期”。
如何用时间戳比对锁定穿透源头
当监控告警触发“缓存 miss 率 > 80% 持续 30s”时，立刻查两组数据：
- 从应用埋点中拉取该时间段内
miss_time密集出现的 key 前 20 名，按key分组统计出现频次 - 用这些 key 去 Redis 执行
PTTL key（毫秒级剩余 TTL），如果多数返回-2（key 不存在）或-1（永不过期），说明已驱逐或未重建；若返回小正值（如 1200），说明它们正处在“即将过期”窗口 - 再查这些 key 对应的
set_time和ttl_seconds，计算理论过期时间 =set_time + ttl_seconds，与当前时间比对 —— 如果误差在 ±10s 内高度集中，基本可断定是过期时间设置不合理（比如全设了 3600 秒且没加随机）
典型陷阱：PTTL 返回 -2 并不等于“刚被驱逐”，也可能是应用根本没写进去（比如 DB 查询失败跳过了 set）。所以必须结合埋点里的 db_load_time_ms 是否为空来交叉验证。
真正容易被忽略的细节
很多人以为只要开了 maxmemory 就会触发驱逐，但 Redis 实际行为更隐蔽：当 used_memory 超过 maxmemory 后，每次写入命令都会触发一次驱逐检查，而检查逻辑是“尝试驱逐直到内存回落到阈值以下”。这意味着一次大 value 写入可能连续踢掉几十个 key，且这些 key 的驱逐时间戳在 Redis 日志里根本不会单独记录 —— 它们只是“顺带消失”的。所以应用端的 set 埋点里，除了 key 和 ttl，还建议加上 value_size_bytes，方便事后识别“谁塞了个 2MB 的大对象进来”。
