SET product:1001 '{}' EX 7300
# 代码里用 7200 加 0 到 600 的随机秒
SCAN 0 MATCH product:* COUNT 1000
TTL product:1001
零点整缓存集体失效，MySQL 报 Too many connections，接口成功率掉到 41%。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，写缓存时统一用了 7200 秒固定过期，同一批数据又是同一时刻灌进去的，过期点自然撞在一起，请求同时回源把数据库顶穿。
围绕「缓存雪崩预防」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
处理上按这个顺序：给过期时间加随机偏移 基础值上浮百分之十；热点数据改成逻辑过期 由后台线程异步续期；回源入口加互斥和限流 只放少量请求进数据库。
改完只确认一件事：压测快进到过期时刻，数据库 QPS 峰值不超过日常两倍就算过。