1. 课程导论：为什么需要缓存失效后的降级与补偿设计？异步导出任务的典型场景与挑战
1.1 缓存失效：分布式系统中的“隐形雪崩”
在分布式系统中，Redis 缓存承担着“流量缓冲层”的核心角色。当缓存中的热点 Key 突然失效（过期或被删除），大量请求会同时穿透到后端数据库，这种现象被称为 缓存雪崩。对于异步导出任务而言，缓存失效带来的后果更为隐蔽且严重：
- 任务元数据丢失：导出任务的进度、状态、文件路径等元数据通常暂存于 Redis，一旦失效，任务将变成“孤儿任务”，用户无法获取结果。
- 重复计算风暴：多个服务实例同时检测到缓存失效，会并发触发数据导出逻辑，导致数据库和计算资源瞬间过载。
- 补偿成本激增：缺乏降级策略时，系统只能依赖人工介入或全量重跑，恢复时间（MTTR）从分钟级恶化到小时级。
关键数据：据行业统计，未做缓存失效降级的导出系统，在缓存失效后的 30 秒内，数据库 QPS 平均飙升 15-20 倍，任务失败率高达 73%。
1.2 异步导出任务的典型架构与数据流
一个标准的异步导出任务通常包含以下 5 个阶段，每个阶段都可能因缓存失效而中断：
| 阶段 | 缓存依赖 | 失效风险 |
|---|---|---|
| 1. 任务提交 | 任务 ID → 参数映射 | 参数丢失，任务无法恢复 |
| 2. 进度追踪 | 任务 ID → 进度百分比 | 前端进度条卡死或报错 |
| 3. 数据分片 | 分片游标 + 偏移量 | 分片错乱，数据重复或遗漏 |
| 4. 中间结果 | 临时文件路径 + 状态 | 文件无法定位，导出失败 |
| 5. 结果通知 | 回调 URL / 用户 ID | 用户收不到下载链接 |
下图展示了异步导出任务在缓存失效前后的数据流对比：
1.3 降级与补偿设计的核心挑战
设计一套健壮的缓存失效应对方案，需要解决以下 4 个核心挑战：
- 挑战一：状态一致性 —— 缓存失效后，如何保证任务状态与数据库最终一致？直接回写数据库会引入写放大，不写则状态丢失。
- 挑战二：幂等性保障 —— 补偿重试时，如何避免重复导出相同数据？需要设计全局唯一的任务指纹。
- 挑战三：资源隔离 —— 降级策略本身不能成为新的瓶颈。例如，补偿队列如果设计不当，可能被失效风暴打满。
- 挑战四：时效性平衡 —— 降级方案需要在“快速恢复”和“数据准确”之间做权衡。完全同步补偿会阻塞用户，完全异步补偿则延迟过高。
设计原则：优秀的降级方案应遵循“先止损，后补偿”的优先级。第一优先级是防止数据库被击穿，第二优先级是恢复任务进度，第三优先级才是通知用户。
1.4 本课程的技术栈与解决思路
本课程将围绕以下技术栈，系统性地讲解降级与补偿的完整方案：
| 技术组件 | 在降级方案中的角色 |
|---|---|
| Redis 集群 | 主缓存层 + 本地缓存（Caffeine）作为 L1 降级 |
| MySQL / PostgreSQL | 任务元数据的持久化兜底 + 补偿日志表 |
| 消息队列（RocketMQ / Kafka） | 异步补偿任务的可靠投递与重试 |
| 分布式锁（Redisson） | 防止补偿任务并发执行 |
| 定时任务（XXL-Job / Quartz） | 兜底扫描：定期检测并修复“孤儿任务” |
下图展示了本课程将要实现的整体降级架构：
重要提示：降级方案不是“银弹”。本课程将重点讲解如何通过 本地缓存预热、布隆过滤器 和 限流熔断 来减少降级触发的概率，而非单纯依赖事后补偿。
1.5 本章小结
缓存失效是异步导出系统中最容易被忽视的“定时炸弹”。通过本章的学习，你应该理解：
- 缓存失效会导致任务元数据丢失、重复计算和数据库过载。
- 异步导出任务的 5 个阶段都依赖缓存，任何一个阶段失效都会导致任务失败。
- 降级与补偿设计需要解决状态一致性、幂等性、资源隔离和时效性 4 大挑战。
- 本课程将基于 Redis + DB + MQ + 分布式锁 + 定时任务的技术栈，构建完整的降级与补偿体系。