redis缓存雪崩主因是大量key同时过期导致请求直击数据库，或redis实例宕机致全量请求打库；需结合随机ttl、空值缓存、本地缓存、熔断降级等多层防护。
为什么 Redis 大量 Key 同时过期会触发雪崩
不是因为 Redis 自身扛不住，而是下游数据库在那一瞬间被击穿。当 setex 或 expire 设置了完全相同的 TTL（比如统一 3600 秒），恰好在整点或某个时间片集中失效，所有请求同时发现缓存 miss，全部涌向数据库——QPS 瞬间翻几倍甚至几十倍，MySQL 连接池打满、慢查询堆积、主从延迟飙升，整个链路就卡住了。
这种现象在电商大促前预热缓存、定时任务批量刷新商品信息等场景特别典型。更麻烦的是，如果这批 key 恰好是首页、分类页等热点数据，雪崩效应会呈指数放大。
加随机值不是随便 rand(1, 60)，得看业务节奏
随机范围不能拍脑袋定。太小（如 ±10 秒）起不到分散作用；太大（如 ±1 小时）又会让部分 key 缓存时间严重偏离业务预期，比如用户刚下单，订单状态缓存却还有 59 分钟才过期，导致前端看到“待支付”状态迟迟不更新。
实操建议：
- 基础 TTL 是业务可接受的最短有效时间（例如库存数据必须 10 分钟内刷新，则 base_ttl = 600）
- 随机偏移量取 base_ttl 的 10%～20%，上限不超过 5 分钟（
variance = 300） - 对强时效性 key（如秒杀库存、登录 token）单独分组，不参与随机，改用
PEXPIREAT精确控制毫秒级过期 - 避免在循环里反复调用
random.randint()，应提前生成好偏移量再批量写入，减少 CPU 波动
光加随机还不够：Redis 宕机才是真雪崩
上面说的「同时过期」只是缓存雪崩的一种诱因。更危险的是 Redis 实例整体不可用——哨兵没切主、Cluster 某个分片全挂、运维误删了整个 DB。这时哪怕每个 key 过期时间都错开了，也没缓存可读，所有请求 100% 打库。
所以必须叠加兜底手段：
- 本地缓存（如 Caffeine）设短 TTL（
expireAfterWrite(30, TimeUnit.SECONDS)），作为第一道缓冲 - 数据库层开启只读副本，并配置自动 failover 切换逻辑，Redis 不可用时降级走 DB
- 关键接口加熔断（如 Sentinel 的
degradeRule），DB 响应超时或异常率 > 30% 时直接返回兜底数据或友好提示 - 禁止在初始化脚本中用
FLUSHALL清空全库，改用按业务 namespace 分批清理
容易被忽略的细节：空值缓存和 key 命名空间污染
加了随机过期时间，但没处理空值，一样会雪崩。比如用户查一个根本不存在的订单号 order:999999999，缓存没命中，查库返回 null，你又没把 null 写进 Redis，下一次请求照样打库——高频无效查询积少成多，照样压垮 DB。
必须同步做两件事：
- 对确认不存在的 key，写入一个特殊标记（如
"_null_"）并设较短过期（redis.setex("order:999999999", 60, "_null_")） - 所有业务 key 必须带明确命名空间前缀（
product:1001、user:2002），避免KEYS *或SCAN扫描时误伤其他业务缓存 - 定期用
redis-cli --scan --pattern "product:*" | xargs redis-cli ttl抽样检查 TTL 分布是否真的均匀
真正难的不是加那几行随机数，而是让每个环节——从 key 设计、写入逻辑、空值处理到故障降级——都对“同时失效”这件事有防御意识。否则补丁打不完。
