分布式事务的终局之战：从2PC到Saga，选型不是技术题，是数学题

1. 一个让架构师失眠的真实场景

某头部电商平台的订单系统在2026年大促期间暴露了经典问题：用户下单后，库存扣减成功、优惠券核销成功、但积分系统因GC停顿超时导致事务回滚。最终结果是——订单没了，库存扣了，优惠券废了。事后排查发现，该团队选择了Seata的AT模式（2PC变种），但在跨机房环境下，全局锁竞争让核心链路P99从80ms飙到2.3s。

这个案例暴露了分布式事务选型的本质矛盾：一致性强度与可用性/性能之间，不存在免费午餐。选型不是看哪个框架更流行，而是看业务能否承担特定故障场景下的数据偏差。

2. 2PC的最后一根稻草：资源锁与协调者单点

2PC（两阶段提交）在理论上是完美的——它保证了全局原子性。但实现层面有三个致命伤：

资源锁定时间过长：从prepare到commit，所有参与者的本地事务资源（如数据库行锁）必须持续持有。在跨库、跨机房场景下，这个时间被网络RTT放大到秒级。
协调者SPOF：TC（事务协调者）宕机后，所有参与者会一直阻塞在prepare状态，直到超时回滚。Seata的AT模式虽然优化了undo_log，但全局锁的争用问题在高并发下依然无解。
隔离性被牺牲：2PC无法避免脏读。

// Seata AT模式的核心代理逻辑（简化）
@GlobalTransactional
public void createOrder(OrderDTO order) {
    // 1. 本地事务：插入订单表
    orderMapper.insert(order);
    // 2. 远程调用：扣库存（此时本地行锁未释放）
    stockClient.deduct(order.getSkuId(), order.getCount());
    // 3. 远程调用：核销优惠券（此时订单行锁仍持有）
    couponClient.consume(order.getCouponId());
    // 4. 全局事务提交... 若步骤3超时，则步骤1和2回滚
}

关键点：@GlobalTransactional 注解背后是资源锁的全局代理——步骤2和3执行期间，订单表的行锁被Seata的LockManager持有，这直接阻塞了同一用户的其他操作。踩坑点：在高并发下，锁等待超时会直接触发全局回滚，而业务方往往把超时时间调大，结果就是雪崩。

3. 从2PC到Saga：为什么是“补偿”而非“回滚”

Saga模式的本质是放弃全局原子性，用本地事务+业务补偿来达成最终一致性。核心思想：每个本地事务执行完立即提交并释放锁，若后续步骤失败，则按逆序调用补偿操作。

对比2PC，Saga的代价是隔离性缺失——在Saga执行过程中，外部可以看到中间状态。对订单系统来说，这意味着“库存已扣但订单未创建”的状态可能被其他服务读到。

// Saga编排器伪代码（基于Apache ServiceComb Saga）
public class OrderSagaOrchestrator {
    @SagaStart
    public void createOrder(OrderDTO order) {
        // 步骤1：创建本地订单（立即提交）
        orderService.create(order);
        // 步骤2：扣库存（立即提交）
        stockService.deduct(order.getSkuId(), order.getCount());
        // 步骤3：核销优惠券（若失败，触发补偿）
        couponService.consumeWithCompensation(order.getCouponId(), 
            () -> couponService.refund(order.getCouponId()));
    }
}

关键点：@SagaStart 注解标记了编排起点，每个子事务的补偿逻辑必须幂等——因为网络重试可能导致补偿多次执行。踩坑点：补偿操作本身可能失败（如优惠券已过期），此时需要人工介入或死信队列兜底。关键决策：Saga适合长事务（如跨日清算）和低冲突场景；若业务对中间状态敏感（如金融转账），Saga不适用。

4. 选型决策矩阵：用数学思维而非框架偏好

基于上述分析，建立一套可量化的选型模型。设业务对数据不一致的容忍度为 T（0-1，0表示零容忍），核心链路平均事务时长为 L（ms），全局事务并发量为 C。

若 T ≈ 0 且 L < 50ms 且 C < 500：选择2PC（Seata AT或XA），因为资源锁争用可控。
若 T ≈ 0 且 L > 100ms：放弃强一致，改用异步确保型（本地消息表）+ 对账补偿。
若 T > 0.01（允许最终一致）：选Saga，但要设计好补偿幂等和中间态读策略。

实际案例：某跨境支付平台采用Saga处理“外汇兑换+账户扣款”的跨时区事务，将全局锁持有时间从2s降到150ms，吞吐提升4倍，但引入了“兑换成功但扣款失败”的补偿分支——该分支在业务上通过“挂账+人工核销”兜底。

5. 终极建议：分布式事务是“设计模式”而非“中间件”

经过多个项目的实践，最稳健的方案是混合架构：

核心资金链路（如支付）：用本地消息表+异步对账，不依赖任何分布式事务框架——这是最笨但最可靠的方式。
非核心链路（如积分、优惠券）：用Saga，且补偿逻辑全部走MQ异步。
绝不使用2PC，除非事务时长小于50ms且并发极低。

下一步行动：不要急着引入框架。先画出所有跨服务调用的依赖图，为每个事务标记“可容忍不一致时长”和“补偿复杂度”。然后从最痛的那个链路开始，用Saga或消息表重构——而不是在现有2PC上打补丁。

本文关键词：Seata、Saga模式、2PC、分布式事务、本地消息表