缓存雪崩是大量key在同一时间过期导致请求穿透至数据库并压垮后端，核心在于“时间集中”+“无兜底”；应采用随机过期时间、懒加载+分布式锁、分批预热及实时监控降级等综合策略防范。
缓存雪崩是什么，为什么它会突然炸掉服务
缓存雪崩不是“缓存挂了”，而是大量 key 在同一时间过期，导致请求穿透到数据库，瞬间压垮后端。典型场景是：用固定 timeout=3600 给所有热点数据设过期时间，又在整点批量刷新缓存——结果 00:00 整点一到，Redis 里几千个 user_profile 全失效，DB 连接池直接打满。
关键点在于「时间集中」+「无兜底」。哪怕 Redis 健康，DB 也扛不住这种脉冲流量。
用随机过期时间 + 懒加载兜底最简单有效
别给所有 key 设相同 timeout。在基础过期时间上加一个随机偏移，比如原本都设 3600 秒，改成 3600 + random.randint(0, 600)，把过期时间打散到 10 分钟窗口内。
同时，对关键数据启用懒加载（lazy load）：缓存未命中时，不直接查 DB，而是先尝试加一个分布式锁（如 redis.set(key + ":lock", "1", ex=5, nx=True)），只有抢到锁的请求去查 DB 并回填缓存，其余请求等待或降级返回旧值。
立即学习“Python免费学习笔记（深入）”；
- 避免用
time.time() // 3600这类整点对齐逻辑生成 key 过期时间 - 不要在应用启动时统一预热全部缓存——预热也要分批、带抖动
-
redis-py的setex不支持设置毫秒级随机值，得用set(key, value, ex=base_ttl + jitter)
用互斥锁防击穿比用永不过期更可控
有人建议“把热门 key 设为永不过期”，但这是掩耳盗铃：内存会涨、节点重启就丢、运维无法感知 stale 数据。真正该防的是单个热 key 突然失效后的并发查询（即“击穿”），而不是整个雪崩。
用 Redis 原生命令实现轻量互斥锁更稳妥：SET key:lock "1" EX 5 NX 成功才查 DB，失败则 GET key 等待或 sleep 后重试。注意锁超时必须短于业务预期响应时间，否则会卡住后续请求。
- 别用
threading.Lock—— 多进程下无效 - 别让锁超时（
EX）远大于 DB 查询耗时，例如查库平均 200ms，锁却设成 30s，会拖慢整体吞吐 - 如果用
redis-py，推荐封装成上下文管理器，避免忘记delete锁 key
监控和预案比代码更重要
再好的策略也挡不住异常流量或配置失误。必须盯住两个指标：cache_miss_rate 突增（比如从 5% 跳到 60%），以及 db_load 对应时段飙升。一旦触发阈值，自动切到降级逻辑：比如返回本地缓存副本、或直接返回兜底 JSON 字符串。
预案要能手动开关，不能只靠自动熔断——半夜报警响了，人没醒，系统已经自毁三次。
- 别只监控 Redis
hits/misses，要按业务维度聚合，比如user_service:cache_miss_rate - 降级返回的数据必须带
X-Cache: stale或类似 header，前端可据此做 UI 提示 - 本地缓存（如
functools.lru_cache）只能作二级兜底，不能替代 Redis，因为不跨进程同步
雪崩往往不是技术选型问题，而是多个看似合理的小决定叠在一起：统一过期、全量预热、无锁重载、不设熔断。越早把“时间抖动”和“锁粒度”当默认项写进规范，越不容易在凌晨三点被电话叫醒。
