微服务架构中分布式事务实战：Seata AT模式与TCC方案对比

微服务架构下分布式事务的挑战

微服务架构将单体应用拆分为多个独立服务后，原本一个数据库事务就能保证的数据一致性，变成了跨服务的分布式事务问题。订单创建需要同时调用库存扣减、账户扣款、物流预创建三个服务，任意一步失败都需要回滚前面的操作。后端开发中如何解决这个一致性问题，直接决定业务中台建设的成败。本文对比Seata AT模式与TCC方案的实际落地差异，给出选型建议。

Seata AT模式：无侵入式自动补偿

Seata AT模式是微服务架构中应用最广泛的分布式事务方案，核心优势是对业务代码零侵入——只需添加一个@GlobalTransactional注解，框架自动处理回滚。

AT模式的工作原理分两阶段：

一阶段：拦截业务SQL，在执行前记录修改前数据（before image），执行后记录修改后数据（after image），生成回滚日志（undo log）与业务数据在同一个本地事务中提交。

二阶段：提交阶段异步删除undo log（极低开销）；回滚阶段根据undo log反向补偿，恢复before image。

// Spring Boot项目中使用AT模式
@GlobalTransactional(timeoutMills = 60000)
public void createOrder(OrderDTO order) {
    // 1. 创建订单（订单服务）
    orderService.create(order);
    
    // 2. 扣减库存（库存服务）
    inventoryService.deduct(order.getProductId(), order.getQuantity());
    
    // 3. 扣减账户余额（账户服务）
    accountService.debit(order.getUserId(), order.getAmount());
}

AT模式的适用场景：业务SQL简单（单表CRUD为主）、并发量中等、对数据一致性要求高但对性能不极致敏感的系统。API接口规范中涉及资金操作时，AT模式是稳妥的默认选择。

TCC模式：高并发场景下的精细控制

TCC（Try-Confirm-Cancel）模式将每个服务操作拆分为三个阶段：Try预留资源、Confirm确认执行、Cancel释放资源。相比AT模式的全自动补偿，TCC需要业务开发者手动实现三阶段逻辑，但获得了更高的并发性能和更精细的资源控制。

// TCC模式实现示例
public interface InventoryTccService {
    
    // Try阶段：冻结库存
    @TwoPhaseBusinessAction(
        name = "deductInventory",
        commitMethod = "confirm",
        rollbackMethod = "cancel"
    )
    boolean tryDeduct(
        @BusinessActionContextParameter(paramName = "productId") String productId,
        @BusinessActionContextParameter(paramName = "quantity") Integer quantity
    );
    
    // Confirm阶段：确认扣减
    boolean confirm(BusinessActionContext context);
    
    // Cancel阶段：释放冻结库存
    boolean cancel(BusinessActionContext context);
}

// Try阶段SQL：冻结库存而非直接扣减
// UPDATE inventory SET available = available - #{quantity},
//                     frozen = frozen + #{quantity}
// WHERE product_id = #{productId} AND available >= #{quantity}

TCC模式的核心难点在于Cancel阶段的幂等性设计——网络超时可能导致Try阶段成功但Seata未收到确认，此时会触发Cancel，而Confirm也可能在同一时间被调用。每个阶段必须保证幂等，否则会出现数据不一致。

消息中间件方案：最终一致性保障

对于对实时一致性要求不高但吞吐量要求极高的场景（如电商下单后的积分发放、消息通知），消息中间件方案是更务实的选择。服务治理中常用的模式是”本地消息表+消息队列”：

// 1. 业务操作与消息记录在同一个本地事务中
@Transactional
public void createOrder(Order order) {
    orderMapper.insert(order);
    // 在同一事务中写入消息表
    messageMapper.insert(new OutboxMessage(
        "inventory_deduct",
        JSON.stringify(new DeductMsg(order.getProductId(), order.getQuantity())),
        "PENDING"
    ));
}

// 2. 定时任务扫描消息表，发送到MQ
@Scheduled(fixedDelay = 1000)
public void sendPendingMessages() {
    List<OutboxMessage> messages = messageMapper.selectByStatus("PENDING");
    for (OutboxMessage msg : messages) {
        try {
            rabbitTemplate.convertAndSend("order.exchange", msg.getTopic(), msg.getPayload());
            messageMapper.updateStatus(msg.getId(), "SENT");
        } catch (Exception e) {
            // 发送失败，下次重试
            log.warn("消息发送失败，等待重试: {}", msg.getId());
        }
    }
}

高并发设计中选择事务方案的核心判断标准：强一致性需求选AT模式，超高并发选TCC模式，最终一致性可接受选消息中间件方案。服务治理层面，三种方案可以共存——核心链路用AT/TCC保证强一致，非核心链路用消息方案降低系统耦合度，这是业务中台建设中常用的混合策略。