Seata 作为主流的分布式事务解决方案，支持以下四种事务模式，覆盖不同业务场景的需求：

---

🔧 1. AT 模式（Auto Transaction）

原理：基于二阶段提交（2PC）优化，通过 SQL 解析 + 回滚日志 实现自动补偿，业务侵入性低。
工作流程：

1. 一阶段：
   • 解析业务 SQL，生成前置快照（Before Image）和业务操作后的快照（After Image）。
   • 将快照存入 undo_log 表，与业务 SQL 在同一本地事务中提交。
2. 二阶段：
   • 提交：异步删除 undo_log 日志。
   • 回滚：根据 undo_log 生成反向 SQL 补偿数据。
     适用场景：

• 常规业务（如订单创建、库存扣减），需快速接入分布式事务。
  优点：
• 业务无侵入，仅需配置代理数据源。
  缺点：
• 依赖数据库行锁，高并发下可能阻塞（如热点数据更新）。

---

⚙️ 2. TCC 模式（Try-Confirm-Cancel）

原理：通过 业务编码 实现两阶段，需手动编写三个阶段方法：

• Try：资源预留（如冻结库存、预扣余额）。
• Confirm：执行实际业务（如扣减冻结资源）。
• Cancel：释放预留资源（如解冻库存）。
  关键要求：
• Confirm/Cancel 需保证 幂等性（网络重试可能导致重复调用）。
• 需处理 三大异常：
  • 空回滚：未执行 Try 时触发 Cancel（需检查事务记录）。
  • 幂等：重复调用 Confirm/Cancel 需返回相同结果。
  • 悬挂：Cancel 在 Try 前执行（需事务状态记录）。
    适用场景：
• 高性能需求（如支付、秒杀），或需强隔离性的金融业务。
  优点：
• 无全局锁，性能优于 AT 模式。
  缺点：
• 代码侵入性强，需为每个业务编写三阶段逻辑。

---

🔄 3. SAGA 模式

原理：长事务拆分为多个本地事务，通过 补偿操作 实现最终一致性。
实现方式：

• 编排式（Orchestration）：
  • 中央协调器（如 Seata 状态机）控制流程，依次调用服务。
• 协同式（Choreography）：
  • 服务间通过 事件驱动（如消息队列）触发后续操作。
    工作流程：
• 若某步骤失败，按 逆序触发补偿操作（如订单取消 → 库存恢复）。
  适用场景：
• 跨服务长流程（如电商下单、保险理赔），支持异步执行。
  优点：
• 支持复杂业务流程，无阻塞问题。
  缺点：
• 补偿逻辑复杂，需保证 最终一致性。

---

🗂️ 4. XA 模式

原理：基于数据库的 标准两阶段提交（2PC），由事务管理器（TM）协调资源管理器（RM）。

• 一阶段（Prepare）：各参与者预提交并锁定资源。
• 二阶段（Commit/Rollback）：协调者根据一阶段结果通知提交或回滚。
  适用场景：
• 强依赖数据库事务协议的传统系统（如银行转账）。
  优点：
• 强一致性保证，兼容支持 XA 协议的数据库（如 MySQL、Oracle）。
  缺点：
• 性能低（同步阻塞），协调者单点故障风险。

---

💎 模式对比与选型建议

模式	一致性	侵入性	性能	适用场景
AT	最终一致	无	中（有锁阻塞）	常规业务（订单、库存）
TCC	最终一致	高	高	高并发、金融交易
SAGA	最终一致	中	高（异步）	长流程、跨服务业务
XA	强一致	低	低	传统数据库强一致需求

选型原则：

• 追求低侵入 → AT 模式
• 追求高性能 → TCC 模式
• 流程复杂且长 → SAGA 模式
• 强一致性需求 → XA 模式

---

⚠️ 生产注意事项

1. 幂等设计：TCC/SAGA 的 Confirm/Cancel 需支持重复调用。
2. 隔离性补偿：AT 模式可能脏读，可通过 SELECT FOR UPDATE 强制读已提交。
3. 监控与日志：使用 Seata Dashboard 跟踪全局事务状态。

参考官方文档：Seata 事务模式详解 (opens new window)。