面试题：Seata 支持哪些模式的分布式事务？

Seata 是一款开源的分布式事务解决方案，支持多种分布式事务模式，以满足不同业务场景的需求。以下是 Seata 支持的四种主要事务模式：

---

1. AT 模式（自动补偿型）

• 原理：
  • 基于 两阶段提交（2PC） 的思想。
  • 第一阶段：执行业务 SQL，生成回滚日志（undo log），并提交本地事务。
  • 第二阶段：根据全局事务的状态，决定是提交还是回滚。
• 特点：
  • 对业务代码无侵入，开发者只需关注业务逻辑。
  • 依赖数据库的回滚日志功能。
• 适用场景：
  • 适合大多数业务场景，尤其是对代码侵入性要求低的场景。
• 优点：
  • 使用简单，性能较高。
• 缺点：
  • 依赖数据库的回滚日志功能，可能产生锁竞争。

---

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

• 原理：
  • 基于 补偿事务 的思想，分为三个阶段：
    1. Try：尝试执行业务逻辑，预留资源。
    2. Confirm：确认执行业务逻辑，提交资源。
    3. Cancel：取消执行业务逻辑，释放资源。
• 特点：
  • 需要开发者手动编写 Try、Confirm、Cancel 逻辑。
  • 不依赖数据库的回滚日志功能。
• 适用场景：
  • 适合高并发、高性能要求的场景，如金融支付、库存扣减等。
• 优点：
  • 性能高，灵活性好。
• 缺点：
  • 对业务代码侵入性强，开发复杂度高。

---

3. Saga 模式

• 原理：
  • 基于 长事务 的思想，将分布式事务拆分为多个本地事务。
  • 每个本地事务执行后，触发下一个本地事务。
  • 如果某个本地事务失败，通过补偿事务回滚之前的操作。
• 特点：
  • 适合长时间运行的业务流程。
  • 需要开发者编写补偿逻辑。
• 适用场景：
  • 适合跨多个服务的长时间事务，如订单创建、物流跟踪等。
• 优点：
  • 支持长事务，灵活性高。
• 缺点：
  • 补偿逻辑复杂，可能产生数据不一致问题。

---

4. XA 模式

• 原理：
  • 基于 XA 协议，依赖数据库的 XA 功能。
  • 分为两个阶段：
    1. 准备阶段：所有参与者准备提交事务。
    2. 提交阶段：协调者通知所有参与者提交或回滚事务。
• 特点：
  • 强一致性，适合对数据一致性要求极高的场景。
  • 依赖数据库的 XA 功能。
• 适用场景：
  • 适合传统数据库事务场景，如银行转账、账务处理等。
• 优点：
  • 强一致性，可靠性高。
• 缺点：
  • 性能较低，依赖数据库支持。

---

5. 模式对比

模式	原理	侵入性	性能	一致性	适用场景
AT	两阶段提交 + 回滚日志	无侵入	较高	最终	大多数业务场景
TCC	Try-Confirm-Cancel	高侵入	高	强	高并发、高性能场景
Saga	长事务 + 补偿机制	中侵入	中	最终	长时间运行的业务流程
XA	XA 协议	无侵入	低	强	强一致性要求的传统数据库场景

---

6. 选择建议

• 如果对代码侵入性要求低，且业务场景不复杂，可以选择 AT 模式。
• 如果需要高性能和高灵活性，且愿意编写补偿逻辑，可以选择 TCC 模式。
• 如果业务涉及长时间运行的流程，可以选择 Saga 模式。
• 如果对数据一致性要求极高，且依赖传统数据库，可以选择 XA 模式。

---

总结

Seata 支持 AT、TCC、Saga 和 XA 四种分布式事务模式，每种模式都有其特点和适用场景。开发者可以根据业务需求选择合适的事务模式，以实现分布式系统中的数据一致性。