一、分布式事务的挑战与核心需求

在分布式系统中，由于服务拆分和微服务架构的普及，跨服务的数据一致性成为核心挑战。传统单机事务的ACID特性在分布式环境下难以直接应用，而分布式事务需要解决网络分区、服务宕机、时序不一致等复杂问题。其核心需求包括：

1. 原子性：跨服务操作要么全部成功，要么全部回滚；
2. 一致性：最终数据状态符合业务预期；
3. 隔离性：并发操作互不干扰；
4. 持久性：事务结果不可逆。

传统方案如XA协议（两阶段提交）因阻塞时间长、性能差，逐渐被TCC和Saga等柔性事务模式取代。

二、TCC模式：三阶段分步控制

1. TCC的核心原理

TCC（Try-Confirm-Cancel）通过三个阶段实现事务控制：

• Try阶段：预留资源，检查业务可行性（如冻结账户余额）；
• Confirm阶段：确认操作，执行实际业务逻辑（如扣减冻结余额）；
• Cancel阶段：取消预留，释放资源（如解冻余额）。

其核心特点是提前预留资源，通过反操作（Cancel）保证最终一致性。

2. 实践案例：转账场景

假设服务A向服务B转账100元：

// Try阶段（服务A）
public boolean tryReserve(String accountId, int amount) {
    Account account = accountDao.findById(accountId);
    if (account.getBalance() >= amount) {
        account.setFrozenBalance(account.getFrozenBalance() + amount);
        accountDao.update(account);
        return true;
    }
    return false;
}
// Confirm阶段（服务B）
public void confirmTransfer(String fromId, String toId, int amount) {
    Account from = accountDao.findById(fromId);
    Account to = accountDao.findById(toId);
    from.setBalance(from.getBalance() - amount);
    to.setBalance(to.getBalance() + amount);
    from.setFrozenBalance(from.getFrozenBalance() - amount);
    accountDao.batchUpdate(from, to);
}
// Cancel阶段（服务A）
public void cancelReserve(String accountId, int amount) {
    Account account = accountDao.findById(accountId);
    account.setFrozenBalance(account.getFrozenBalance() - amount);
    accountDao.update(account);
}

关键点：

• Try阶段需快速失败（如余额不足直接返回）；
• Confirm阶段必须幂等（防止重复执行）；
• Cancel阶段需处理部分成功场景（如网络超时后重试）。

3. TCC的适用场景与优缺点

• 适用场景：强一致性要求、资源预留成本低（如库存、账户余额）；
• 优点：高吞吐量、低延迟；
• 缺点：业务侵入性强（需拆分Try/Confirm/Cancel接口）、实现复杂。

三、Saga模式：长事务拆解与补偿

1. Saga的核心原理

Saga将长事务拆分为多个本地事务，每个事务对应一个补偿操作。当某个子事务失败时，通过逆序执行补偿操作回滚。例如：

T1 → T2 → T3 → ... → Tn
↓           ↑
Cn ← ... ← C3 ← C2 ← C1

• 正向流程：依次执行T1, T2, …, Tn；
• 补偿流程：失败时从后向前执行Cn, …, C1。

2. 实践案例：订单全流程

假设订单包含“创建订单→支付→发货”三个步骤：

// 正向事务
public class OrderService {
    public boolean createOrder(Order order) { /* 创建订单 */ }
    public boolean pay(Order order) { /* 支付逻辑 */ }
    public boolean ship(Order order) { /* 发货逻辑 */ }
}
// 补偿事务
public class OrderCompensation {
    public void cancelOrder(Order order) { /* 取消订单 */ }
    public void refund(Order order) { /* 退款 */ }
    public void returnGoods(Order order) { /* 退货 */ }
}

执行流程：

1. 成功：T1(create) → T2(pay) → T3(ship)；
2. 失败（如支付后发货失败）：C3(return) → C2(refund)。

3. Saga的实现方式

• 事件驱动：通过消息队列（如Kafka）触发补偿；
• 状态机：使用有限状态机管理事务状态（如Netflix的Conductor）；
• 编排式：中央协调器控制流程（如Axon Framework）；
• 编舞式：服务间通过事件协作（如Event Sourcing）。

4. Saga的适用场景与优缺点

• 适用场景：跨服务长事务、补偿操作可逆（如订单、支付）；
• 优点：无阻塞、适合异步场景；
• 缺点：补偿逻辑复杂、可能存在数据不一致窗口。

四、TCC与Saga的对比与选型建议

维度	TCC	Saga
一致性级别	强一致性	最终一致性
性能	高（无阻塞）	中等（依赖补偿）
实现复杂度	高（需拆分接口）	中等（依赖补偿逻辑）
适用场景	短事务、资源预留	长事务、异步流程

选型建议：

1. TCC：适合金融、支付等强一致性场景，但需投入较多开发资源；
2. Saga：适合电商、物流等长流程场景，需设计完善的补偿机制。

五、实践中的关键问题与解决方案

1. 幂等性处理

• TCC：Confirm/Cancel阶段需通过唯一ID去重（如数据库唯一约束）；
• Saga：补偿操作需标记已执行状态（如Redis缓存）。

2. 空回滚问题

• 场景：Try未执行但触发Cancel；
• 解决方案：通过状态机检查Try是否执行（如记录Try日志）。

3. 悬挂问题

• 场景：Try执行后系统崩溃，恢复后触发Cancel；
• 解决方案：设置全局事务ID超时机制（如10分钟未完成则自动回滚）。

六、总结与展望

TCC和Saga作为分布式事务的核心模式，分别适用于不同场景：

• TCC：通过三阶段控制实现强一致性，适合资源预留类操作；
• Saga：通过补偿机制实现最终一致性，适合长流程事务。

未来，随着Service Mesh和Serverless的普及，分布式事务的实现将更加标准化（如通过Sidecar代理事务逻辑）。开发者需结合业务特点，权衡一致性、性能与开发成本，选择最适合的方案。