分布式事务实践——TCC、Saga入门级理解

引言：分布式事务的必然性

在微服务架构盛行的今天，系统拆分带来的数据一致性挑战日益凸显。当订单服务需要同时更新库存、积分、物流等多个子系统时，如何保证所有操作要么全部成功，要么全部回滚？这正是分布式事务需要解决的核心问题。

一、TCC模式：三阶段补偿的刚柔并济

1.1 TCC核心三阶段

TCC（Try-Confirm-Cancel）模式通过三个阶段实现最终一致性：

• Try阶段：资源预留与状态检查。例如订单服务预扣库存（库存表增加预留字段），支付服务冻结金额。
• Confirm阶段：正式执行业务。将Try阶段预留的资源转为实际占用，如将预扣库存转为实际扣减。
• Cancel阶段：资源释放与回滚。当Confirm失败时，释放Try阶段预留的所有资源。

1.2 典型实现示例

// 库存服务TCC接口示例
public interface InventoryTccService {
    // Try阶段：预扣库存
    boolean tryReserve(String orderId, int quantity);
    // Confirm阶段：确认扣减
    boolean confirmReserve(String orderId);
    // Cancel阶段：释放预留
    boolean cancelReserve(String orderId);
}
// 实现类关键逻辑
public class InventoryTccServiceImpl implements InventoryTccService {
    @Override
    public boolean tryReserve(String orderId, int quantity) {
        // 1. 检查库存是否充足
        // 2. 插入预留记录（状态=TRYING）
        // 3. 更新可用库存=可用-预留量
        return true;
    }
    @Override
    public boolean confirmReserve(String orderId) {
        // 1. 查找TRYING状态的预留记录
        // 2. 更新状态为CONFIRMED
        // 3. 实际扣减库存
        return true;
    }
    @Override
    public boolean cancelReserve(String orderId) {
        // 1. 查找TRYING状态的预留记录
        // 2. 更新状态为CANCELLED
        // 3. 恢复可用库存（加回预留量）
        return true;
    }
}

1.3 TCC适用场景

• 强一致性要求的场景（如金融交易）
• 业务操作可拆分为预留和确认两步
• 允许短暂的数据不一致（通过最终一致性解决）

1.4 实践要点

1. 幂等性设计：每个阶段需处理重复调用（如通过订单ID+状态判断）
2. 空回滚处理：当Try未执行直接调用Cancel时需能正确处理
3. 悬挂问题：避免Confirm执行前重复调用Try导致数据错误

二、Saga模式：长事务的优雅编排

2.1 Saga核心机制

Saga通过将长事务拆分为多个本地事务，每个事务对应一个补偿操作：

• 正向操作：T1, T2, T3…, Tn
• 补偿操作：C1, C2, C3…, Cn（与正向操作顺序相反）

2.2 典型实现方式

2.2.1 事件驱动编排

// 订单创建Saga示例
public class OrderCreationSaga {
    public void start(Order order) {
        // 1. 发布OrderCreated事件
        eventPublisher.publish(new OrderCreatedEvent(order));
        // 2. 监听后续事件
        subscribe(PaymentProcessedEvent.class, this::handlePaymentProcessed);
        subscribe(InventoryReservedEvent.class, this::handleInventoryReserved);
    }
    private void handlePaymentProcessed(PaymentProcessedEvent event) {
        if (event.isSuccess()) {
            // 继续处理库存
            inventoryService.reserve(event.getOrderId());
        } else {
            // 触发补偿
            compensatePayment(event.getOrderId());
        }
    }
    private void compensatePayment(String orderId) {
        // 调用支付服务退款接口
        paymentService.refund(orderId);
        // 发布PaymentCompensated事件
    }
}

2.2.2 命令协调模式

通过中央协调器（Saga Orchestrator）管理状态：

public class OrderSagaOrchestrator {
    private SagaState state;
    public void start(Order order) {
        state = SagaState.TRY_PAYMENT;
        paymentService.process(order);
    }
    public void onPaymentResult(PaymentResult result) {
        if (result.isSuccess()) {
            state = SagaState.TRY_INVENTORY;
            inventoryService.reserve(order);
        } else {
            state = SagaState.COMPENSATE_PAYMENT;
            paymentService.refund(order);
        }
    }
    // 其他状态处理...
}

2.3 Saga适用场景

• 跨多个微服务的长业务流程
• 补偿操作容易实现的场景
• 可接受阶段性不一致（通过最终一致性解决）

2.4 实践要点

1. 补偿逻辑设计：确保每个正向操作都有对应的补偿操作
2. 事务隔离：避免正向操作间的并发冲突
3. 状态管理：清晰记录当前执行阶段
4. 重试机制：处理临时性故障

三、TCC与Saga的对比选择

维度	TCC模式	Saga模式
一致性强度	强一致性（通过两阶段）	最终一致性
实现复杂度	高（需实现三个接口）	中（基于现有服务编排）
性能影响	较低（Try阶段快速）	较高（长事务链）
适用场景	金融等强一致场景	电商等可容忍短暂不一致场景
开发成本	高（需定制开发）	中（可基于现有服务）

四、最佳实践建议

1. 混合使用策略：核心业务用TCC保证强一致，非核心业务用Saga
2. 监控与告警：实时监控事务执行状态，设置超时告警
3. 降级方案：设计手动补偿流程，应对极端情况
4. 测试验证：通过混沌工程验证异常场景下的行为
5. 工具选型：考虑使用Seata、Axon等成熟框架

五、未来发展趋势

1. 与Service Mesh集成：通过Sidecar模式实现透明的事务管理
2. AI优化补偿：利用机器学习预测失败概率，动态调整事务策略
3. 区块链应用：探索利用区块链的不可篡改特性增强事务可靠性

结语

分布式事务没有银弹，TCC和Saga代表了两种不同的设计哲学。理解它们的本质差异，结合业务特点选择合适方案，并通过持续实践优化实现细节，才是构建可靠分布式系统的正确路径。对于初学者，建议从Saga模式入手，逐步掌握TCC的精细控制能力，最终形成适合自身业务的技术方案组合。