缓存雪崩是指大量缓存数据同时过期或redis宕机，导致请求集中打到数据库，引发数据库压力骤增甚至崩溃；主因是批量设置相同过期时间、未做随机偏移、时钟不同步及persist后未重设ttl等。
直接用 EXPIRE 批量设置相同过期时间是最大误区
很多人在预热缓存时，用脚本循环调用 EXPIRE 给一批 key 统一设为 3600 秒，结果凌晨 2 点所有首页商品缓存同时失效——这不是“缓存有”，而是“缓存集体消失”。Redis 本身不拒绝这种操作，但业务扛不住。真正的问题不在 Redis，而在你没把时间差打散。
正确做法是：在基础过期时间上叠加随机偏移量。比如目标是 1 小时，就用 EXPIREAT + 当前时间戳 + 3600 + Math.random() * 300（即 ±5 分钟）。Java、Python、Node.js 都能轻松生成这个时间戳，别图省事写死一个值。
- 不要用
SETEX或SET的EX参数批量写入相同 TTL，除非你明确知道这批 key 是孤立、低频、可容忍雪崩的冷数据 - 如果用 Lua 脚本批量设置，务必在脚本内生成随机数，而不是在客户端算好再传进去（避免客户端时间不同步导致随机性失效）
- 注意
EXPIREAT接收的是秒级时间戳，PEXPIREAT才是毫秒级；混用会导致缓存提前或延后数小时失效
persist 后忘记重设过期时间会埋雷
运维或排查时手动执行 PERSIST 清除某个 key 的过期时间很常见，但之后如果代码逻辑仍假设该 key 会自动过期，就会出问题。比如库存 key 被 PERSIST 后长期滞留，后续更新没触发新 EXPIRE，最终返回陈旧数据。
这类问题往往在压测或上线后才暴露，因为开发环境很少模拟长期运行+人工干预的组合场景。
- 所有对 key 执行
PERSIST的操作，必须配套检查后续是否有EXPIRE/EXPIREAT调用，尤其注意异步任务、消息消费、定时刷新等路径 - 建议在关键业务 key 的更新逻辑里，统一用
SET key value EX 3600替代SET + EXPIRE两步，避免中间状态残留 - 监控层面可配置告警：对高频访问但
TTL返回 -1（永不过期）的 key 做标记，人工复核是否合理
集群环境下误以为“分片 = 天然防雪崩”
有人觉得“我把热点 key 分到 3 个 Redis 实例上，就算全过期也不至于一起崩”，这忽略了两个事实：一是客户端路由逻辑可能让某类请求集中打到同一分片；二是如果使用了 Hash Tag（如 {user123}），实际还是落在同一个节点。分片只解决容量和单点压力，不解决时间维度的并发穿透。
更隐蔽的问题是：不同分片的系统时钟未校准，导致 EXPIREAT 计算出的过期时刻在各节点上实际不一致，可能引发部分节点提前雪崩。
- 集群部署必须启用 NTP 或 chrony 时间同步，误差控制在 50ms 内，否则
PEXPIREAT的毫秒级精度会失准 - 不要依赖分片数量来稀释过期风险，该加随机偏移还得加；分片只是兜底，不是替代方案
- 用
redis-cli --cluster check定期验证各节点时间偏差，比等故障发生再查快得多
把“永不过期”当银弹，却忽略内存泄漏风险
首页 banner、运营配置这类数据，确实常被设为永不过期（不调 EXPIRE），靠更新时覆写。但一旦上游发布漏发更新、或写入逻辑异常（如空值覆盖、序列化失败），这个 key 就变成“僵尸缓存”——永远存在，永远错误。
它不会引发雪崩，但会让问题静默持续数天，直到用户投诉才被发现。
- 永不过期的 key 必须配强校验：读取后检查字段完整性、版本号、更新时间戳，不满足则主动触发刷新并记录告警
- 给这类 key 设置
MAXMEMORY策略时，避免用noeviction；至少选allkeys-lru，防止 OOM - 定期用
SCAN+TTL检查长期（如 >7 天）TTL为 -1 的 key，结合业务语义判断是否合理
真实线上环境里，雪崩往往不是由单一错误触发，而是多个“看起来无害”的操作叠加：脚本批量设 TTL、一次 PERSIST、集群时钟漂移、加上恰好没做空值兜底——这些点单独看都容易被放过，合起来就是凌晨三点的告警风暴。
