1. 课程背景与痛点：什么是热点Key？为什么在异步导出服务中热点Key会导致雪崩？
1.1 热点Key的定义与典型场景
在 Redis 分布式缓存体系中，热点Key 是指在短时间内被大量并发请求集中访问的某一个或某几个 Key。这类 Key 的访问频率远高于集群中其他 Key 的平均水平，导致流量严重倾斜到少数 Redis 节点上。
| 维度 | 正常 Key | 热点 Key |
|---|---|---|
| QPS 分布 | 均匀分散在集群各节点 | 单 Key QPS 可达数万至数十万 |
| 资源消耗 | CPU/内存负载均衡 | 单节点 CPU 打满、网卡带宽饱和 |
| 典型触发原因 | 常规业务查询 | 秒杀、大促、报表导出、批量任务 |
| 故障影响范围 | 局部慢查询 | 单节点宕机 → 集群雪崩 |
在异步导出服务中，热点 Key 的出现具有明显的业务特征：
- 导出任务状态 Key：所有用户查询同一个导出任务的状态，例如
export:task:20250315:status。 - 全局计数器 Key：每日导出次数限制、全局批次号生成等高频写入 Key。
- 共享数据快照 Key：大量导出任务同时引用同一份中间结果集，如
report:snapshot:2025Q1。
案例警示：某金融平台在季度报表导出高峰期，单个 Redis Key
export:counter:daily 的 QPS 瞬时飙升至 12 万，导致该分片节点 CPU 使用率从 30% 直接拉满到 100%，响应超时率达 67%。
1.2 热点Key导致雪崩的连锁反应
当热点 Key 所在的 Redis 节点因过载而宕机或触发保护性熔断时，雪崩效应会沿着以下路径快速扩散：
- 节点过载：单 Key 高并发导致该分片 CPU 打满、网卡带宽占尽。
- 请求积压：客户端连接池被占满，新请求排队超时。
- 节点宕机/主从切换：Redis 哨兵或集群触发故障转移，但新主节点立即承接相同流量。
- 缓存击穿：热点 Key 失效或节点宕机后，大量请求穿透到后端数据库。
- 数据库被打垮：DB 连接池耗尽，慢查询堆积，最终导致整个导出服务不可用。
关键认知：热点 Key 雪崩不是瞬间发生的，而是从“单点性能瓶颈”到“级联故障”的渐进式崩溃。异步导出服务由于任务批量大、并发高、持续时间长，比普通业务系统更容易触发这一链条。
1.3 热点Key雪崩链路全景图
下图展示了从热点 Key 产生到服务雪崩的完整链路：
1.4 异步导出服务中的特殊脆弱性
相比普通业务系统，异步导出服务在热点 Key 面前表现出更强的脆弱性，主要体现在以下四个方面：
| 脆弱性维度 | 具体表现 | 风险等级 |
|---|---|---|
| 任务状态轮询 | 前端每 2~3 秒轮询导出进度，大量用户同时查询同一任务 Key | 🔴 极高 |
| 全局计数器 | 每日导出次数、批次号生成等 Key 被所有导出任务共享 | 🔴 高 |
| 数据快照共享 | 同一份报表快照被多个导出任务同时引用，读放大效应明显 | 🟡 中高 |
| 批量任务并发 | 定时任务触发时，成百上千个导出任务同时启动，瞬间冲击同一批 Key | 🔴 极高 |
经验数据：在异步导出服务中，热点 Key 导致的雪崩事故占 Redis 相关故障的 42% 以上。其中，任务状态轮询 Key 是最高频的触发源，占比达 67%。
1.5 传统方案的局限性
业界常用的热点 Key 应对方案在异步导出场景中存在明显短板：
- 本地缓存：只能缓解读热点，无法解决写热点；且导出任务状态需要实时性，本地缓存过期时间难以权衡。
- 读写分离：Redis 集群读写分离对热点 Key 无效，因为流量仍然落在同一个分片的主从节点上。
- Key 拆分：手动拆分 Key 需要业务改造，且拆分粒度难以动态调整，运维成本高。
- 限流降级：传统限流在网关层做，无法感知 Redis 内部的热点分布，容易误杀正常请求。