今天学习了 Seata 分布式事务的其他模式，包括 XA 模式、TCC 模式和 Saga 模式，以下是详细整理：

一、XA 模式

核心特点

  • 连接持有机制：XA 模式会持有数据库连接（如 MySQL 的  Connection  对象）直至两阶段提交完成，在此期间连接无法释放，可能影响数据库连接池性能。
  • 注解使用：需同时使用  @GlobalTransactional （保证分布式事务的提交/回滚）和  @Transactional （保证本地事务正常提交）两个注解。
  • 两阶段流程：
    1. 一阶段：各分支事务执行本地业务逻辑，但不提交，仅记录日志并等待全局协调。
    2. 二阶段：事务协调者（TC）根据全局事务状态，决定所有分支事务执行  commit （提交）或  rollback （回滚）。

优缺点

  • 优点：强一致性，依赖数据库原生 XA 协议，无需侵入业务代码。
  • 缺点：长期持有连接导致性能损耗大，不适合高并发场景，一般不推荐使用。

二、TCC 模式

核心概念

TCC 模式将分布式事务分为三个阶段，需手动实现业务逻辑：

1. Try：资源检查与预留（如扣减库存前检查库存是否充足，并锁定部分库存）。
2. Confirm：确认提交（如实际扣减锁定的库存）。
3. Cancel：取消回滚（如释放锁定的库存）。

注解使用

需在服务类上配合使用  @LocalTCC  和  @TwoPhaseBusinessAction  注解，明确 Try、Confirm、Cancel 方法的映射关系。

关键问题及解决方案

1. 空回滚：

  • 问题：当某分支事务未执行完成（如远程调用失败），却触发了 Cancel 回滚，导致无实际业务可回滚。
  • 解决：Seata 通过全局事务 ID（XID）和分支 ID 查询对应记录，判断是否需要执行回滚逻辑。
    2. 幂等性：
  • 问题：因网络重试等原因，同一事务可能被多次执行（如重复提交订单）。
  • 解决：通过状态机控制事务状态（如  Trying （执行中）、 Committed （已提交）、 Rollbacked （已回滚）），避免重复处理。
    3. 悬挂问题：
  • 问题：事务执行顺序异常（如二阶段提交先于一阶段完成，导致一阶段失败后无法回滚）。
  • 解决：新版本 Seata 限制在一阶段业务逻辑未完成前，不允许执行二阶段的  commit  操作。

优缺点

  • 优点：灵活性高，不依赖特定数据源，支持非关系型数据库。
  • 缺点：对业务代码侵入性强，需手动实现三个阶段的逻辑，开发成本高。

三、Saga 模式

核心特点

  • 状态机驱动：通过状态机定义业务流程的执行顺序，以及异常时的补偿逻辑（逆向操作）。
  • 回滚机制：当某环节失败时，通过状态机触发前置步骤的补偿操作（如订单创建失败，回滚支付、库存扣减等操作）。

常见实践

  • 实际应用中，Saga 模式较少直接使用，更多结合 MQ 实现定时补偿：
  • 业务处理失败时，将补偿任务发送至 MQ，通过重试机制反复执行。
  • 多次重试失败后，消息进入死信队列，由人工介入处理，保证数据最终一致性。

适用场景

  • 适合业务流程长、分支多的场景（如订单履约全流程）。
  • 适合老系统改造（无需深入了解原有业务细节，通过状态流转控制补偿逻辑）。

四、模式对比与选择建议

模式 一致性 性能 业务侵入性 适用场景
XA 强一致 差 无 低并发、强一致性要求极高场景
AT 最终一致 中 无 关系型数据库、一般微服务场景
TCC 最终一致 高 高 新业务、非关系型数据库场景
Saga 最终一致 中 低 长事务、老系统改造场景

选择建议

  • 新业务且需灵活控制资源：优先考虑 TCC 模式（需接受业务侵入性）。
  • 关系型数据库为主、低侵入需求：优先考虑 AT 模式。
  • 老系统改造或长事务：优先考虑 Saga 模式。
  • 性能敏感场景：避免使用 XA 模式。

总结

Seata 提供的多种分布式事务模式各有优劣，实际使用中需根据业务场景（如一致性要求、并发量、系统新旧程度）选择合适的模式，同时注意解决 TCC 等模式中的空回滚、幂等性、悬挂等问题，确保分布式事务的可靠性。