这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
缓存雪崩基础
那个可怕的夜晚
周五凌晨 2 点，睡得正香的我被电话惊醒。
电话那头是运维同事焦急的声音：
通话中
周五 02:03
运
运维同事
“快起来！系统崩了！” “外部 API 调用失败率 100%，触发限流！” “Redis 好像挂了，连接不上！”
扬声器
挂断
静音
我打开电脑，看到的是一片红色警报：
Inbox
From: 监控系统
To: 运维值班
Time: 周五 02:03
Subject: [P0] 系统全面崩溃 - Redis 集群无响应
- 严重：Redis 集群无响应
- 严重：外部 API 调用失败率 85%
- 严重：API 错误率 85%
- 严重：响应时间超过 30 秒
这就是缓存雪崩——缓存系统大规模失效，所有请求直接涌向外部 API。
什么是缓存雪崩？
缓存雪崩流程
场景一：集中过期
14:00 批量写入缓存
key_001 TTL: 3600s
key_002 TTL: 3600s
key_003 TTL: 3600s
...
key_999 TTL: 3600s
所有 key 都在同一时间过期!
15:00 集体过期!
key_001 过期
key_002 过期
key_003 过期
...
key_999 过期
10000 个 key 同时失效!
15:01 外部 API 崩溃
请求洪水
外部 API 过载
CPU: 100%
系统雪崩!
场景二：Redis 宕机
正常状态
用户
→ Redis
→ 外部 API
缓存命中率 95%
响应时间 50ms
Redis 宕机
用户
→ Redis
⇨ 外部 API 全部请求涌向这里!
缓存命中率 0%
响应时间 5000ms+
API 限流状态 已触发
缓存雪崩是指：
- 大量缓存 key 在同一时间过期
- 或者缓存服务（如 Redis）宕机
- 导致大量请求同时访问外部 API
- 外部 API 瞬间压力激增，可能触发限流或崩溃
关键特征：
- 大面积失效（不是单个 key）
- 通常是系统级问题
- 后果最严重（可能导致整个系统崩溃）
真实上线还要注意
- Redis 也会变成关键依赖。 它帮你挡住外部 API，但它自己挂了，压力又会回到外部 API。
- 不要只看命中率。 还要看 Redis 连接数、响应时间和回源请求有没有突然变多。
- 要提前准备兜底。 缓存不可用时，可以返回旧数据或简化数据，别让所有请求一起失败。
练习
练习 1
缓存雪崩的两种触发场景是什么？
参考答案 (2 个标签)
缓存雪崩 基础概念
答案：
场景一：集中过期
- 大量缓存 key 在同一时间过期
- 原因：使用固定过期时间，且批量写入
- 例：10000 个 key 都在 14:00 写入，都设置 1 小时过期，15:00 同时失效
场景二：缓存服务宕机
- Redis 服务器故障、网络中断、机房断电等
- 导致所有缓存无法访问
- 所有请求直接访问外部 API
区别：
- 集中过期可以预防（随机过期时间）
- 服务宕机需要高可用架构和降级方案