缓存雪崩是什么
雪崩指同一瞬间大面积缓存同时失效，回源流量瞬间涌向数据库：一类是大批键在同一时刻过期，另一类是缓存层整体不可用（实例宕机、主从全部失效、大 key 阻塞导致请求超时）。本质是「同一个瞬间大家都没缓存」，因此防护重点是让回源流量可控，而不是单点优化缓存本身。
基本信息
| 触发原因 | 批量键同刻过期、缓存层宕机、大 key 阻塞 |
|---|---|
| 直接后果 | 数据库连接与 QPS 被打满，业务整体不可用 |
| 主要手段 | TTL 抖动、多级缓存、回源限流、熔断降级 |
| 架构手段 | 哨兵或 Cluster 多副本，避免缓存单点 |
| 补充手段 | 发布或重启后分批预热，避免冷启动冲击 |
典型使用场景
- 批量写入缓存时：给同批数据的 TTL 加随机抖动，避免同刻到期
- 大促与大流量前：提前分批预热热点数据，不等到用户请求来触发
- 缓存重启后：先补一批热点再放全量流量进来
- 数据库保护：对回源流量设并发上限与排队，宁可慢不可垮
- 依赖降级：缓存不可用时读本地缓存或返回兜底内容
- 监控告警：对回源 QPS、缓存命中率设置突降告警
TTL 抖动与分批预热
TTL 抖动与分批预热
import random
base = 600
ttl = base + random.randint(-120, 120) # 600 加减 120 秒的随机抖动
redis.set(key, value, ex=ttl)
# 批量预热时分批进行，避免一次性压满缓存与数据库
# for chunk in chunks(keys, 100):
# warmup(chunk)
# time.sleep(0.1)
# 热更新时的推荐顺序：先写库，再删缓存，等回源自然加载防护措施对照
| 措施 | 作用 | 局限 |
|---|---|---|
| TTL 抖动 | 把过期时间打散，避免同刻失效 | 对整体宕机无效 |
| 多级缓存 | 本地缓存顶住短暂不可用 | 容量小，数据一致性更难 |
| 回源限流 | 保护数据库不被打垮 | 部分请求要排队或失败 |
| 熔断降级 | 快速失败并返回兜底数据 | 用户看到降级内容 |
| 多副本高可用 | 降低缓存层整体失效概率 | 增加成本与运维复杂度 |
雪崩的本质是「同一个瞬间大家都没缓存」：无论是过期还是宕机，都要让回源流量可控，这是最后一道闸门。
缓存层挂掉时最危险的动作是全量流量直接压向数据库：应先限流再恢复缓存，或直接进入降级模式返回兜底数据，避免缓存恢复后数据库已被打垮。