十八张图，看懂八种分布式事务机制的全貌！

在分布式系统架构中，事务的原子性和一致性是核心挑战。随着微服务、云原生等技术的普及，跨服务、跨数据库的操作成为常态，分布式事务机制的选择直接影响系统的可靠性和性能。本文通过十八张示意图，系统梳理八种主流分布式事务机制，帮助开发者快速掌握其核心原理与适用场景。

一、2PC（两阶段提交）机制：强一致性的经典方案

图1：2PC流程示意图
2PC通过协调者（Coordinator）和参与者（Participant）的交互，将事务分为“准备阶段”和“提交阶段”。

• 准备阶段：协调者向所有参与者发送预提交请求，参与者执行事务并锁定资源，返回“同意”或“中止”。
• 提交阶段：若所有参与者同意，协调者发送提交命令；否则发送回滚命令。

优点：实现简单，保证强一致性。
缺点：同步阻塞（参与者需等待协调者指令），单点问题（协调者故障导致事务阻塞），数据不一致风险（第二阶段协调者崩溃后，部分参与者可能已提交）。
适用场景：对一致性要求极高、可接受较低吞吐量的金融交易系统。

二、3PC（三阶段提交）机制：2PC的改进版

图2：3PC流程示意图
3PC将2PC的“两阶段”拆分为“CanCommit”“PreCommit”“DoCommit”三阶段，通过超时机制解决2PC的阻塞问题。

• CanCommit：协调者询问参与者是否能执行事务。
• PreCommit：参与者执行事务并锁定资源，协调者根据反馈决定进入提交或中断。
• DoCommit：协调者发送最终提交或回滚指令。

改进点：通过超时自动中断，降低阻塞概率。
局限性：仍存在网络分区时的数据不一致风险。
适用场景：对可用性要求略高于一致性的订单处理系统。

三、TCC（Try-Confirm-Cancel）机制：柔性事务的代表

图3：TCC三阶段示意图
TCC将事务拆分为“Try”“Confirm”“Cancel”三个操作，由业务层实现资源预留和回滚逻辑。

• Try：预留资源（如冻结账户余额）。
• Confirm：确认提交（实际扣款）。
• Cancel：取消预留（释放冻结资金）。

优点：灵活性高，适用于高并发场景。
缺点：业务侵入性强，需开发额外接口。
代码示例：

// Try阶段：冻结资金
public boolean tryReserve(String orderId, BigDecimal amount) {
    return accountService.freeze(orderId, amount);
}
// Confirm阶段：实际扣款
public boolean confirm(String orderId) {
    return accountService.deduct(orderId);
}
// Cancel阶段：释放冻结资金
public boolean cancel(String orderId) {
    return accountService.unfreeze(orderId);
}

适用场景：电商支付、库存扣减等需要最终一致性的业务。

四、SAGA模式：长事务的补偿机制

图4：SAGA正反向操作示意图
SAGA将长事务拆分为多个子事务，每个子事务对应一个补偿操作。若某一步失败，则按反向顺序执行补偿。

• 正向流程：T1→T2→T3（如创建订单→支付→发货）。
• 补偿流程：C3→C2→C1（如取消发货→退款→删除订单）。

优点：无需锁定资源，适合跨服务长事务。
缺点：补偿逻辑复杂，可能产生脏数据。
适用场景：旅行预订、跨系统数据同步等复杂业务。

五、本地消息表：最终一致性的可靠方案

图5：本地消息表流程示意图
通过数据库表记录消息状态，结合定时任务保证消息可靠性。

1. 业务系统将消息存入本地表（状态为“待发送”）。
2. 定时任务扫描表，将消息发送至MQ。
3. 消费者处理后更新消息状态为“已完成”。

优点：实现简单，无需依赖中间件。
缺点：需处理重复消息和幂等性。
适用场景：订单状态变更通知、日志同步等。

六、事务消息：RocketMQ的解决方案

图6：事务消息流程示意图
RocketMQ通过“半消息”机制实现事务一致性：

1. 生产者发送半消息（状态未知）。
2. 执行本地事务后，根据结果提交或回滚半消息。
3. 消费者消费已确认的消息。

优点：解耦生产者和消费者，支持异步处理。
缺点：依赖MQ中间件。
适用场景：跨系统数据同步、异步任务处理。

七、AT模式（自动补偿）：Seata的简化方案

图7：AT模式流程示意图
Seata的AT模式通过全局锁和回滚日志实现自动补偿：

1. 记录修改前的数据镜像（Before Image）。
2. 执行SQL并记录修改后的数据（After Image）。
3. 若事务失败，根据镜像生成回滚SQL。

优点：无需业务侵入，开发效率高。
缺点：依赖数据库日志，性能略低于TCC。
适用场景：快速迭代的互联网业务。

八、Seata框架：一站式分布式事务解决方案

图8：Seata架构示意图
Seata提供AT、TCC、SAGA、XA四种模式，通过TC（事务协调器）、TM（事务管理器）、RM（资源管理器）协同工作。

• TC：全局事务调度。
• TM：定义事务边界。
• RM：管理分支事务。

配置示例：

# application.yml
seata:
  tx-service-group: my_tx_group
  service:
    vgroup-mapping:
      my_tx_group: default
    grouplist:
      default: 127.0.0.1:8091

适用场景：需要统一管理分布式事务的微服务架构。

总结与建议

1. 强一致性需求：优先选择2PC或3PC，但需评估性能影响。
2. 高并发场景：TCC或AT模式更合适，注意业务侵入性和性能平衡。
3. 长事务处理：SAGA模式适合复杂业务流程，但需完善补偿逻辑。
4. 最终一致性：本地消息表或事务消息可降低系统耦合度。

实践建议：

• 结合业务特点选择机制，避免过度设计。
• 通过压测验证性能瓶颈，优化锁粒度和超时时间。
• 监控事务成功率、回滚率等指标，及时调整策略。

分布式事务无银弹，理解机制本质比追求技术新潮更重要。希望本文的十八张图和详细解析，能为你的架构设计提供清晰指引。