一、Seata核心概念
Seata（Simple Extensible Autonomous Transaction Architecture） 是阿里开源的分布式事务解决方案，核心思想是通过 事务协调器（TC） 统一管理全局事务分支的状态，协调 资源管理器（RM） 和 事务管理器（TM） 完成事务的提交与回滚。
核心组件：
- TC (Transaction Coordinator)：全局事务协调者，维护全局事务状态，驱动分支事务提交或回滚。
- TM (Transaction Manager)：定义全局事务边界，发起全局事务的提交或回滚。
- RM (Resource Manager)：管理分支事务，向TC注册分支事务并汇报状态。
二、Seata四种事务模式原理解析
1. AT模式（Auto Transaction）
原理：
- 基于数据库本地事务，通过代理JDBC数据源生成反向SQL日志（UNDO_LOG），实现自动补偿。
- 两阶段执行：
- 第一阶段：执行业务SQL，生成UNDO_LOG并注册分支事务到TC。
- 第二阶段：
- 提交：异步删除UNDO_LOG。
- 回滚：根据UNDO_LOG生成反向SQL补偿数据。
核心机制：
- 全局锁：避免其他事务修改正在处理的数据，确保隔离性。
- UNDO_LOG表：记录数据修改前后的快照，用于回滚。
优点：
- 对业务代码无侵入，仅需配置数据源代理。
- 高性能，适合常规CRUD场景。
缺点：
- 依赖数据库锁，高并发场景可能产生锁竞争。
2. TCC模式（Try-Confirm-Cancel）
原理：
- 手动编码实现三阶段：
- Try：预留资源（如冻结库存）。
- Confirm：提交资源（实际扣减库存）。
- Cancel：释放预留资源（解冻库存）。
核心机制：
- 幂等性：Confirm/Cancel需保证重复调用不产生副作用。
- 空回滚：处理Try未执行但触发Cancel的场景。
优点：
- 无全局锁，性能较高。
- 支持跨异构系统的事务。
缺点：
- 需手动编码实现三阶段逻辑，开发成本高。
3. Saga模式
原理：
- 长事务解决方案，将事务拆分为多个本地事务，每个事务提交后触发下一个事务。
- 补偿机制：任一子事务失败，按反向顺序执行补偿操作。
核心机制：
- 状态机：定义事务执行流程和补偿逻辑。
- 异步执行：适合耗时较长的业务流程（如订单创建→物流调度→支付）。
优点：
- 支持长事务，天然适应最终一致性场景。
- 无锁设计，高吞吐量。
缺点：
- 补偿逻辑需开发者完整覆盖，可能引入业务复杂度。
4. XA模式
原理：
- 基于XA协议，由数据库原生支持的两阶段提交（2PC）。
- Prepare：所有分支事务执行但不提交。
- Commit/Rollback：TC根据全局事务状态通知提交或回滚。
核心机制：
- 数据库XA驱动：依赖数据库的XA协议实现。
- 强一致性：所有分支事务要么全部提交，要么全部回滚。
优点：
- 强一致性，适合对数据一致性要求极高的场景（如金融系统）。
缺点：
- 同步阻塞，性能较低。
- 依赖数据库XA支持（如MySQL 5.7+）。
三、四种模式对比
| 模式 | 一致性 | 性能 | 侵入性 | 适用场景 |
|---|---|---|---|---|
| AT | 弱一致性 | 高 | 低 | 常规CRUD操作 |
| TCC | 最终一致性 | 中 | 高 | 需自定义资源管理的场景 |
| Saga | 最终一致性 | 高 | 中 | 长流程、跨服务业务链 |
| XA | 强一致性 | 低 | 低 | 强一致需求的传统业务 |
四、选型建议
- AT模式：快速接入，适合简单业务。
- TCC模式：需精细化控制资源（如资金交易）。
- Saga模式：长流程业务（如电商订单+物流）。
- XA模式：传统数据库强一致需求。
五、总结
Seata通过多种事务模式覆盖不同业务场景，开发者需根据业务特性（一致性、性能、复杂度）选择合适方案。AT模式适合快速落地，TCC/Saga应对复杂逻辑，XA模式保障强一致。