TCC vs Saga：分布式事务架构选型实战指南
TCC vs Saga：分布式事务架构选型实战指南（生产级深度解析）
这是一个非常经典且具有挑战性的架构决策问题。TCC（Try-Confirm-Cancel） 和 Saga 是解决分布式事务最主流的两种最终一致性方案，但它们的设计哲学和适用场景截然不同。
以下是一份基于生产实战的选型指南，希望能帮助你根据业务场景做出最合适的选择。
✅ 核心决策逻辑：一句话总结
- 如果你需要强一致性（事务要么全成功，要么全失败），且业务规模较大、不怕复杂 → 选 TCC
- 如果你能接受最终一致性，业务流程长、或希望快速落地 → 选 Saga
🔍 1. 深入理解两者的本质区别
| 维度 | TCC（Try-Confirm-Cancel） | Saga |
|---|---|---|
| 资源视角 | 资源预留型（先锁资源） | 补偿型（先执行，失败再补偿） |
| 隔离性 | ✅ 支持（Try 阶段锁定资源） | ❌ 不支持（可能出现脏写） |
| 一致性 | ✅ 强一致性 | ✅ 最终一致性 |
| 开发复杂度 | 高（三阶段 + 多种异常处理） | 中（正向 + 补偿） |
| 业务适配 | 钱 / 库存 / 核心资产 | 长流程 / 异步 / 外部系统 |
💰 2. 什么时候选 TCC？（适合“钱”和“货”）
📌 典型场景
- <