Seata分布式事务实战：AT模式与TCC模式的选型与应用

微服务架构下，一个业务操作要跨多个服务、多个数据库完成，本地事务管不住，分布式事务就是解决跨库、跨服务数据一致性的核心手段。Seata是阿里巴巴开源的一站式分布式事务解决方案，本篇文章用实际配置说明AT、TCC、SAGA、XA四种模式的选型与落地。

分布式事务的难点：为什么本地事务无法解决

单体应用的一条SQL要么成功要么回滚，事务ACID由数据库保证。微服务化之后，订单创建要同时扣库存、加积分、记账，分别落在订单库、库存库、账户库，每个服务各自有本地事务。如果扣库存成功但加积分失败，传统做法只能手工对账，数据一致性无从保证。分布式事务要解决的就是把多个本地事务绑定成一个全局事务。

2. Seata核心架构：TC、TM与RM的分工

Seata把分布式事务拆成三个角色：TC（事务协调器）：独立部署的服务端，维护全局事务状态，负责提交与回滚的协调；TM（事务管理器）：发起全局事务的入口，由业务侧调用，决定全局提交或回滚；RM（资源管理器）：管理分支事务，处理本地事务的提交与回滚并上报状态。全局事务通过XID贯穿调用链，服务间传递XID，保证分支事务归属同一个全局事务。

3. Seata AT模式：自动补偿如何实现与配置示例

AT模式是Seata最常用的模式，它代理数据源，在业务SQL前后自动记录undo_log，实现近乎无侵入的补偿回滚。全局事务提交时，TC让分支事务先做一阶段提交，然后二阶段根据undo_log反向生成回滚SQL。适合大多数业务场景，但需要数据库支持undo_log表（MySQL、PostgreSQL、Oracle均支持）。

以Spring Boot + MyBatis为例，核心配置：

# 依赖（Gradle）
implementation 'com.alibaba.cloud:spring-cloud-starter-alibaba-seata'

# application.yml
seata:
  enabled: true
  application-id: order-service
  tx-service-group: my_test_tx_group
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
  config:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848

# 业务侧启用全局事务
@GlobalTransactional(name = "create-order")
public void createOrder(OrderDTO dto) {
    orderDao.insert(dto);          // 本地事务1
    stockService.deduct(dto.getSkuId(), 1);  // 远端服务事务2
    accountService.debit(dto.getUserId());   // 远端服务事务3
}

启用@GlobalTransactional后，Seata会协调上述多个本地事务，任一分支失败则自动反向回滚已提交的分支。

4. TCC模式：Try-Confirm-Cancel三段式实现

TCC把每个分支拆成Try（预留资源）、Confirm（确认）、Cancel（补偿）三个方法。Try阶段做资源预留但不真正提交，Confirm阶段真正执行，Cancel阶段回补。它不依赖数据库undo表，可完全由业务控制，适合并发高、事务耗时短、资源预留明确的场景（如库存预扣）。代码实现：

@LocalTCC
public interface StockAction {

    @TwoPhaseBusinessAction(name = "deductStock",
            commitMethod = "confirm", rollbackMethod = "cancel")
    boolean tryDeductStock(
        @BusinessActionContextParameter(paramName = "skuId") Long skuId,
        @BusinessActionContextParameter(paramName = "qty") Integer qty);

    boolean confirm(BusinessActionContext ctx);
    boolean cancel(BusinessActionContext ctx);
}

TCC的缺点是开发量翻倍，每个分支都要写三套方法，且要保证Confirm/Cancel的幂等性。

5. SAGA与XA：长事务和强一致场景的选择

SAGA模式把长事务拆成一串本地事务，每个事务完成后发事件驱动下一段，任何一步失败就沿链反向补偿。适合耗时很长的业务流程（如预订、审批流），不需要锁资源，但补偿逻辑要自己写、且事务过程中数据处于中间态。XA模式是数据库原生的分布式事务标准，由数据库驱动，强一致，但锁粒度和依赖范围大，高并发下性能下降明显，适合对一致性要求极高、并发要求不高的金融对账类场景。

6. 分布式事务选型结论与实操建议

业务事务跨度小、服务少，直接改普通事务即可；跨服务场景优先AT模式，改动小、维护成本低；高并发短事务（秒杀扣库存）用TCC；长流程业务流程用SAGA；强一致对账用XA。分布式事务不是万能的，能避免就避免：把业务重构为单库单服务事务、或通过幂等+重试+对账做最终一致，往往比引入分布式事务框架更简单可靠。消息事务（本地消息表、RocketMQ事务消息）同样可处理跨服务最终一致。

Seata把分布式事务的复杂度收敛到框架层，AT模式能做到业务代码几乎零侵入。先按上述配置跑通AT，再按需叠加TCC/SAGA，就能覆盖绝大多数微服务的一致性问题。