分布式事务
一个订单服务调用了库存服务、账户服务、仓储服务。
四个服务，四个数据库，怎么保证「订单创建成功，库存扣减成功，余额扣减成功，库存入库成功」？
这就是分布式事务要解决的问题。
模块速览
分布式事务的解决方案分为两大类：强一致性方案和最终一致性方案。
| 章节 | 篇数 | 核心内容 |
|---|---|---|
| 解决方案总览 | 7 篇 | AT、TCC、SAGA、可靠消息、最大努力通知、方案对比 |
| 原理深度剖析 | 7 篇 | XA 规范、Seata 架构、全局事务、TCC 问题 |
方案对比
| 方案 | 一致性 | 侵入性 | 性能 | 适用场景 |
|---|---|---|---|---|
| XA | 强一致 | 中等 | 差 | 多数据库强一致 |
| AT | 最终一致 | 低 | 中 | 普通业务场景 |
| TCC | 强一致 | 高 | 高 | 资源敏感场景 |
| SAGA | 最终一致 | 中 | 高 | 长事务编排 |
| 可靠消息 | 最终一致 | 低 | 高 | 异步解耦 |
选型决策树
业务代码能改吗？
├─ 不能 → AT 模式（零侵入）
└─ 能 ↓
资源敏感吗？（库存、资金）
├─ 是 → TCC 模式（高性能）
└─ 否 ↓
事务时间长？（> 1 分钟）
├─ 是 → SAGA 模式（长事务）
└─ 否 → AT 模式 / 可靠消息面试高频问题
Q1：分布式事务的解决方案有哪些？
「五种：XA、AT、TCC、SAGA、可靠消息。 XA 是数据库层面的强一致，性能差但可靠。 AT 是 Seata 的零侵入方案，通过 undolog 自动补偿。 TCC 是业务层面的强一致，性能高但侵入性大。 SAGA 适合长事务，通过补偿操作实现最终一致。 可靠消息通过 MQ 保证最终一致，性能最高但延迟大。」
Q2：TCC 的空回滚、幂等、悬挂问题怎么解决？
「三个问题的本质都是分布式系统的经典问题： 空回滚——用 Try 执行记录解决，Cancel 前检查记录是否存在。 幂等——用唯一键 + 状态机解决，无论执行多少次结果一致。 悬挂——用状态转移检查解决，Cancel 前确认是否已 Confirm。」
Q3：Seata AT 模式的全局锁和数据库锁有什么区别？
「数据库锁防止并发事务之间的脏写，Seata 全局锁防止跨全局事务的脏写。 两者的作用域不同，数据库锁是单节点内的，Seata 全局锁是跨节点的。 两者配合，共同保证隔离性。」
延伸阅读
分布式事务没有银弹，每种方案都是一致性、性能、开发成本的权衡。
建议结合具体业务场景理解：
- 电商下单：TCC（库存/余额）+ AT（订单）+ 可靠消息（通知）
- 金融转账：TCC（强一致）
- 订单流水线：SAGA（长事务）