深入解析分布式事务：从两阶段提交到 Saga 模式的工程实践

在微服务架构中，数据一致性是最具挑战性的问题之一。当业务逻辑跨多个服务边界时，如何保证数据正确性？本文系统解析分布式事务的演进路径与工程落地。

一、为什么需要分布式事务

单体应用时代，一个数据库事务就能保证 ACID。但进入微服务架构后，一个业务操作可能涉及多个服务的数据变更：

• 电商下单：需要扣减库存、创建订单、扣减账户余额、增加积分——这些操作分散在不同服务的数据库中
• 银行转账：转出账户和转入账户可能在不同的数据库实例甚至不同的银行系统中
• 微服务编排：Saga 模式中的每个本地事务都需要最终一致性的保障

分布式事务要解决的核心问题是：在部分失败的情况下，如何保证跨服务的数据一致性。

二、核心技术演进：三代方案

2.1 第一阶段：两阶段提交（2PC）

两阶段提交（Two-Phase Commit）是最经典的分布式事务协议，由协调者（Coordinator）和多个参与者（Participant）组成：

第一阶段：准备阶段（Prepare Phase）

协调者 → 参与者A：准备提交？
协调者 → 参与者B：准备提交？
参与者A → 协调者：Yes（已锁定资源，写入 undo/redo log）
参与者B → 协调者：Yes（已锁定资源，写入 undo/redo log）

第二阶段：提交阶段（Commit Phase）

如果所有参与者都返回 Yes：
    协调者 → 所有参与者：提交！
    
如果有任何参与者返回 No 或超时：
    协调者 → 所有参与者：回滚！

经典实现：XA 规范（eXtended Architecture），主流关系型数据库（MySQL InnoDB、PostgreSQL、Oracle）均支持 XA 协议。Java 生态中 JTA（Java Transaction API）是标准的 2PC 编程接口。

2PC 的主要问题：

• 同步阻塞：准备阶段所有参与者都会锁定资源，性能严重受限
• 单点故障：协调者宕机会导致参与者持续阻塞
• 数据不一致：第二阶段协调者崩溃 参与者崩溃可能导致脑裂
• 性能代价：网络往返增加，锁持有时间延长

2.2 第二阶段：三阶段提交（3PC）

三阶段提交引入超时机制和预提交阶段，试图解决 2PC 的阻塞问题：

1. CanCommit：协调者询问参与者是否可以执行（不锁定资源）
2. PreCommit：所有参与者同意后才执行预提交（锁定资源）
3. DoCommit：最终提交或超时中断

3PC 通过 PreCommit 阶段和参与者超时机制，降低了协调者单点故障的影响范围。但在网络分区场景下仍无法避免不一致，且多了一个网络往返，性能进一步下降。实际工程中 3PC 的应用远不如 2PC 广泛。

2.3 第三阶段：最终一致性模式

TCC（Try-Confirm-Cancel）

TCC 将业务操作拆分为三个阶段，每个阶段都是本地事务：

Try：预留资源，做业务可行性校验
Confirm：确认执行，真正扣减资源
Cancel：取消执行，释放预留资源

例如电商下单场景：

• 库存服务 Try：冻结 5 件商品，不影响实际库存
• 库存服务 Confirm：实际扣减 5 件
• 库存服务 Cancel：释放冻结，恢复可用库存

TCC 的优点是不锁定资源、性能高。缺点是业务侵入性强，每个服务都要实现三个接口，空回滚和悬挂问题需要仔细处理。

Saga 模式

Saga 是一系列本地事务的序列，每个事务更新单个服务并发布事件或消息触发下一个事务。如果某个事务失败，执行补偿事务撤销之前的修改。

Saga 两种实现方式：

• 编排式（Choreography）：每个服务监听前一个服务的事件，决定下一步操作。通过事件驱动实现去中心化协调
• 协调式（Orchestration）：由一个 Saga 协调器统一管理服务调用顺序，当某个步骤失败时触发补偿链

四、工程实践：关键设计决策

4.1 幂等性设计

分布式环境下网络超时不等于失败，重试是必然选择。所有参与方必须保证幂等性：

• 全局唯一事务 ID（xid），每次重试携带相同 ID
• 数据库唯一约束 INSERT ... ON DUPLICATE KEY UPDATE
• Token 机制：预生成幂等令牌，消费后标记已用
• 状态机：只有特定状态才允许执行操作

4.2 悬挂与空回滚处理

TCC 模式的两个经典坑：

• 空回滚：_CANCEL 先于 _TRY 到达。解决方案：_TRY 执行时记录事务 ID，_CANCEL 时检查记录，无记录则返回成功
• 悬挂：_TRY 因网络延迟晚于 _CANCEL 到达。解决方案：_CANCEL 执行后置标志位，_TRY 先检查标志位

4.3 补偿事务设计原则

• 补偿必须幂等：补偿操作可能重试，不能产生副作用累积
• 补偿必须可达：即使系统故障，补偿链也必须能够执行
• 业务可逆优先：优先选择天然可逆的业务模型（如冻结→扣减）而非账单式反向操作
• 允许业务补偿：不一定追求数据完全回到原状态，可以接受"已退款"这样的终态

五、四大开源框架对比

框架	模式	适用场景	核心特点
Seata AT	2PC 自动补偿	微服务改造初期	无侵入，依赖 Undo Log 自动生成回滚 SQL
Seata TCC	TCC 手动实现	高性能要求场景	需手动实现三个接口，性能最优
Seata Saga	Saga 状态机	长业务流程	支持多种语言服务编排
Apache RocketMQ	事务消息	异步最终一致	基于消息队列，天然支持异步场景
Narayana	JTA/2PC	Java EE 应用	Java 标准 XA 实现，Spring 原生支持

六、选型决策矩阵

面对一个分布式事务需求时，建议按以下步骤决策：

1. 能否避免？优先考虑合并服务、使用本地消息表、引入事件驱动将异步化
2. 强一致 vs 最终一致？核心金融链路可能需要 2PC，非核心链路可选 Saga/TCC
3. 同步 vs 异步？高并发场景优先异步最终一致（MQ 事务消息），低并发可考虑同步 TCC
4. 业务侵入度？改造期用 AT 模式降低侵入性，稳定期可迁移到 TCC 提升性能
5. 监控是否到位？无论选哪种，必须存在事务状态追踪和告警机制

七、生产环境最佳实践

1. 事务边界最小化

只在真正需要跨服务保证一致性的场景使用分布式事务。能用本地事务解决的不要用 Saga，能用 Saga 不要用 2PC，能用 2PC 不要用 TCC。

2. 设置全局超时

任何分布式事务都需要全局超时机制，防止资源无限期锁定。建议：2PC 超时在 3-5 秒，Saga 单个步骤超时 30 秒，整体 Saga 超时 5-10 分钟。

3. 可观测性建设

分布式事务的排障难度极高，必须投入充足的观测能力：

• 全局事务 ID 贯穿所有服务（分布式追踪系统携带）
• 事务状态机可视化（每个步骤的执行状态）
• 异常事务告警（超时/悬挂/空回滚）
• 补偿失败人工介入面板

4. 降级与熔断

当依赖服务不可用时，分布式事务框架应支持降级：

• 2PC 协调者故障时，参与者应能在超时后自动回滚（3PC 的改进）
• Saga 协调器不可用时，新事务拒绝但已有事务应能靠日志恢复
• TCC 中 Confirm/Cancel 不可达时，应有外部干预通道

八、总结

分布式事务没有银弹，只有最适合的工程管理方案。核心原则是：

优先弱化一致性要求 → 其次选择侵入性最小的方案 → 最后才考虑强一致方案

理解每种方案的承诺边界和代价，结合业务场景做出合理判断。在绝大多数在线业务中，最终一致性 幂等设计 完善的可观测性，是工程实践中的最优解。