缓存雪崩可通过随机化TTL和互斥锁预防：用random_int()为过期时间添加0–10分钟抖动，避免集中失效；用setnx+expire实现轻量锁，未获锁者休眠100ms后重试；慎用永不过期，须配合主动更新与内存策略。
缓存雪崩不是“会不会发生”的问题，而是“什么时候、以什么方式爆发”的问题——只要大量 Redis 缓存 key 设置了相同或高度集中的 expire 时间，高并发下就极大概率触发。
怎么设过期时间才不集体失效？用 random_int() 加偏移，别写死数字
PHP 里最常见也最危险的操作，就是所有用户、商品、订单缓存都统一写成 $redis->setex($key, 3600, $val)。3600 秒一到，全崩。
- 基础 TTL（比如 3600 秒）只是参考值，真实过期时间必须带随机抖动
- 推荐用
random_int(0, 600)在基础值上加 0–10 分钟浮动，让失效时间分散在 3600–4200 秒区间 - 不要用
rand()，它线程不安全；mt_rand()也不如random_int()密码学安全且可预测性低
$baseTtl = 3600; $jitter = random_int(0, 600); $ttl = $baseTtl + $jitter; $redis->setex($key, $ttl, $value);
注意：别把抖动设太大（比如 ±1 小时），否则冷热数据混在一起，缓存命中率反而下降。
缓存失效瞬间，怎么避免 100 个请求一起查数据库？用 setnx 做轻量级互斥锁
setnx 是 Redis 原生命令，PHP 客户端（如 Predis 或原生 Redis 扩展）都支持，比引入复杂锁服务更直接。
立即学习“PHP免费学习笔记（深入）”；
- 锁 key 要和业务 key 强关联，例如
"lock:{$key}"，防止误删 - 必须配
expire，否则进程崩溃或异常退出会导致锁永远不释放（死锁） - 没抢到锁的请求，别立刻重试，用
usleep(100000)（100ms）再查一次缓存——多数情况下这时缓存已重建好
$lockKey = "lock:{$key}";
if ($redis->setnx($lockKey, 1)) {
$redis->expire($lockKey, 10); // 锁最多持10秒
$data = db_query($id); // 查库
$redis->setex($key, $ttl, json_encode($data));
$redis->del($lockKey);
} else {
usleep(100000);
$data = $redis->get($key); // 再试一次
}
容易踩的坑：setnx 成功后忘记 expire，或者锁过期时间远短于数据库查询耗时（比如锁设 2 秒，DB 查询要 5 秒），导致多个请求同时进入重建逻辑。
要不要考虑“永不过期”？慎用，得配合主动更新机制
有人说“干脆不设 expire”，物理上避免雪崩。这在部分场景可行，但代价明确：
- 数据一致性变难：缓存不会自动淘汰，必须靠业务逻辑触发更新（比如修改商品价格后，主动
$redis->set("product:123", $new)） - 内存持续增长风险：没做 key 清理策略，旧数据越积越多，Redis 内存爆掉比雪崩还难排查
- 不适合读多写少但时效敏感的场景（如活动倒计时、库存余量）
如果真要用永不过期，至少做到：
- 所有写操作路径必须覆盖对应缓存 key 的更新或删除
- 配合
Redis的INFO memory和KEYS（生产禁用）或SCAN定期巡检大 key / 过期 key 残留 - 开启
maxmemory-policy（如allkeys-lru）作为兜底
监控和预热才是最后一道防线，光靠代码防不住人为失误
再完善的随机化 + 锁机制，也挡不住上线时批量 flushall、配置漏改、或新接口忘了加抖动。
- 关键指标必须告警：
redis_hit_rate（低于 85% 就预警）、redis_expired_keys（突增说明集中过期）、mysql_slow_queries - 预热脚本要在发布前跑：用
SCAN扫出热点 key 模式（如user:<em></em>、product:hot），提前加载并设置带抖动的 TTL - 线上禁止直接执行
KEYS *或未加 limit 的SCAN，它们会阻塞 Redis 主线程
真正压垮系统的，往往不是技术方案本身，而是某次发布跳过了预热步骤，或是监控告警阈值设成了“等 DB 报错才通知”。
