1. 课程导论：缓存一致性问题概述、TCC模式简介、课程目标与学习路径
1.1 缓存一致性问题的本质
在分布式系统中，缓存与数据库之间的数据不一致是导致业务故障的头号隐患。当应用同时读写缓存（如 Redis）和数据库（如 MySQL）时，由于两者是独立的存储系统，任何一次写操作都可能在时间窗口内造成数据差异。
核心矛盾：缓存追求低延迟（微秒级），数据库追求持久化与事务性（毫秒级）。两者在写入顺序、回滚能力、隔离级别上的天然差异，使得“先写库还是先写缓存”成为经典难题。
典型的缓存一致性问题场景包括：
| 场景 | 操作顺序 | 不一致后果 |
|---|---|---|
| 缓存穿透 | 查询未命中缓存 → 查库 → 回写缓存 | 高并发下大量请求直接打到数据库 |
| 缓存击穿 | 热点 key 过期 → 并发查库 | 数据库瞬时压力激增 |
| 缓存雪崩 | 大量 key 同时过期 → 全部查库 | 数据库被打垮 |
| 双写不一致 | 先写库后写缓存 / 先删缓存后写库 | 读到旧数据或丢失更新 |
其中，双写不一致是本课程关注的核心。传统解决方案（延迟双删、订阅 binlog 异步同步）只能降低不一致概率，无法在分布式事务层面保证最终一致性。
1.2 为什么需要 TCC 模式
TCC（Try-Confirm/Cancel）是分布式事务领域的一种补偿型方案，最初用于跨库转账、订单拆分等场景。将其引入缓存一致性领域，是因为它提供了明确的边界控制：
- Try 阶段：预留资源，锁定缓存与数据库的中间状态
- Confirm 阶段：确认提交，将预留状态转为最终一致
- Cancel 阶段：回滚释放，撤销 Try 阶段的所有预留操作
相比传统“先删缓存再写库”或“先写库再删缓存”的脆弱策略，TCC 模式在缓存场景中具备以下优势：
| 对比维度 | 传统延迟双删 | binlog 异步同步 | TCC 模式（本课程） |
|---|---|---|---|
| 一致性保证 | 概率性最终一致 | 最终一致（秒级延迟） | 强最终一致（毫秒级） |
| 回滚能力 | 无 | 需额外补偿脚本 | 内置 Cancel 回滚 |
| 缓存利用率 | 频繁删除导致命中率下降 | 依赖 binlog 时效 | Try 阶段保留缓存 |
| 实现复杂度 | 低 | 中 | 中高（需定义接口） |
适用场景提示：TCC 模式最适合对一致性要求高、且缓存更新频率可控的业务，如库存扣减、账户余额、订单状态变更。不适合纯读多写少或缓存仅做加速的场景。
1.3 课程目标与学习路径
本课程旨在帮助你建立从理论到实战的完整知识体系，最终能够独立设计并落地基于 TCC 的缓存一致性方案。
课程三大目标
- 理解边界：掌握缓存一致性的问题边界与 TCC 模式的核心原理
- 掌握设计：学会在缓存场景中定义 Try、Confirm、Cancel 三阶段接口
- 落地实战：基于 Spring Boot + Redis + MySQL 实现可运行的 TCC 缓存一致性框架
学习路径（30 章结构）
| 阶段 | 章节范围 | 核心内容 |
|---|---|---|
| 基础篇 | 第 1–6 章 | 缓存一致性理论、TCC 模式原理、分布式事务基础 |
| 设计篇 | 第 7–15 章 | 接口定义、状态机设计、幂等与防悬挂、超时与补偿 |
| 实现篇 | 第 16–24 章 | Spring Boot 集成、Redis 锁与事务、MySQL 本地事务编排 |
| 进阶篇 | 第 25–30 章 | 性能调优、监控与告警、生产案例复盘 |
1.4 前置知识与工具准备
为获得最佳学习效果，建议你具备以下基础：
- 熟悉 Java 语言及 Spring Boot 基础开发
- 了解 Redis 基本数据结构（String、Hash）与过期策略
- 了解 MySQL 事务与行锁机制
- 了解分布式 CAP 理论与 BASE 原则
注意：本课程所有实战代码均基于 JDK 17 + Spring Boot 3.x + Redis 7.x + MySQL 8.x。如果你使用更低版本，部分 API 可能需要适配。
现在，让我们正式进入缓存一致性的世界，从 TCC 模式中寻找那个精确的“一致性边界”。