4. 缓存雪崩：定义、大规模缓存同时失效的灾难与预防策略

4.1 什么是缓存雪崩

缓存雪崩是指大量缓存键在同一时间或极短时间窗口内集中失效，导致所有请求直接穿透到后端数据库（如 MySQL），造成数据库瞬间负载飙升、连接池耗尽、响应超时，甚至引发数据库宕机和服务级联崩溃的灾难性现象。

4.2 雪崩 vs 穿透 vs 击穿

4.3 大规模缓存同时失效的灾难链路

当大量缓存 key 在同一秒过期，Redis 中这些 key 被删除，后续请求全部 miss。灾难通常按以下阶段演进：

1. 缓存 Miss 洪峰： 所有请求同时穿透到数据库层。
2. 数据库连接池耗尽： 数据库无法处理瞬间数万 QPS，连接超时。
3. 请求堆积与重试： 上游服务因超时不断重试，进一步放大流量。
4. 数据库宕机： CPU 100%、磁盘 IO 打满，数据库进程被 OOM Killer 终止。
5. 服务级联崩溃： 依赖该数据库的所有微服务相继不可用。

4.4 缓存雪崩的预防策略

预防策略需要从缓存过期策略、缓存架构和流量控制三个层面综合设计：

4.4.1 过期时间随机化（基础防线）

避免所有 key 使用相同的 TTL。在基础过期时间上增加一个随机偏移量，使失效时间均匀分布。

// Java 示例：在基础 TTL 上增加随机偏移
int baseTTL = 3600; // 1 小时
int randomOffset = new Random().nextInt(600); // 0~600 秒随机
int finalTTL = baseTTL + randomOffset;
redisTemplate.opsForValue().set(key, value, finalTTL, TimeUnit.SECONDS);

4.4.2 多级缓存架构（缓冲层）

在 Redis 与数据库之间增加本地缓存（如 Caffeine、Guava Cache），即使 Redis 大面积失效，本地缓存仍能承载部分流量，为数据库争取恢复时间。

4.4.3 互斥锁 / 分布式锁（限流回源）

当缓存 miss 时，只允许一个线程去数据库加载数据，其他线程等待缓存重建完成后再读取。适用于并发极高的热点 key。

// 伪代码：互斥锁回源
String lockKey = "lock:" + cacheKey;
if (redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS)) {
    // 获取锁成功，查询数据库
    Object dbData = queryFromDB(key);
    redisTemplate.opsForValue().set(cacheKey, dbData, 3600, TimeUnit.SECONDS);
    redisTemplate.delete(lockKey);
    return dbData;
} else {
    // 获取锁失败，短暂休眠后重试缓存
    Thread.sleep(50);
    return redisTemplate.opsForValue().get(cacheKey);
}

4.4.4 缓存永不失效 + 后台异步更新

不设置物理过期时间，而是由后台定时任务或消息队列异步更新缓存。适用于对一致性要求不高的场景。

• 优点： 彻底避免雪崩。
• 缺点： 数据存在短暂不一致，需要额外的更新调度系统。

4.4.5 服务降级与熔断

当检测到数据库负载超过阈值时，直接返回默认值或错误提示，拒绝部分请求，保护数据库不被击垮。

4.5 预防策略对比表

4.6 缓存雪崩的灾难链路与预防策略总览

下图展示了从缓存同时失效到数据库宕机的完整灾难链路，以及各预防策略在链路中的介入位置：

4.7 最佳实践组合建议

在实际生产环境中，单一策略往往不足以完全防御雪崩。推荐组合方案：

• 基础层： 过期时间随机化（必须实施，成本最低）。
• 缓冲层： 本地缓存（Caffeine）作为二级缓存，设置较短 TTL（如 30 秒）。
• 回源层： 互斥锁控制数据库回源并发度。
• 兜底层： 数据库连接池限流 + 服务熔断（Sentinel / Hystrix）。