当前位置：首页 > article >正文

面试基础---分布式事务深度解析：TCC、SAGA、2PC、XA 原理、实践与源码实现

article 2025/3/9 19:20:39

分布式事务深度解析：TCC、SAGA、2PC、XA 原理、实践与源码实现

引言

在互联网大厂的高并发、高可用分布式系统中，分布式事务是保证数据一致性的核心挑战。TCC（Try-Confirm-Cancel）、SAGA、2PC（两阶段提交）和 XA 协议是解决这一问题的经典方案。本文将从设计原理、工程实践、源码实现三个维度深入解析这些方案，并结合电商、金融等场景案例，为分布式事务设计提供全面指导。

1. 分布式事务的挑战与核心问题

1.1 分布式事务的挑战

网络不可靠性：节点间通信可能失败或延迟。
节点故障：部分节点宕机导致事务中断。
数据一致性：如何保证跨服务操作的原子性。

1.2 CAP 理论下的权衡

在分布式系统中，需在一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）之间做出权衡。柔性事务（如 TCC、SAGA）通常选择 最终一致性，而刚性事务（如 2PC、XA）追求 强一致性。

2. 刚性事务：2PC 与 XA 协议

2.1 2PC（两阶段提交）

2.1.1 工作原理

阶段一（Prepare）：协调者询问所有参与者是否可提交。
阶段二（Commit/Rollback）：根据参与者反馈决定提交或回滚。

2.1.2 源码实现：Atomikos

Atomikos 是 Java 领域流行的 2PC 实现框架，其核心逻辑如下：

// Atomikos 协调者逻辑（简化版）
public class Coordinator {
    public void executeTwoPhaseCommit(List<Participant> participants) {
        // Phase 1: Prepare
        boolean allPrepared = participants.stream().allMatch(Participant::prepare);
        // Phase 2: Commit or Rollback
        if (allPrepared) {
            participants.forEach(Participant::commit);
        } else {
            participants.forEach(Participant::rollback);
        }
    }
}

2.1.3 适用场景

金融转账：跨行转账需保证强一致性。
缺点：同步阻塞、单点故障、数据长时间锁定。

2.2 XA 协议

XA 是分布式事务的行业标准，基于 2PC 实现，由数据库和事务管理器协作完成。

2.2.1 架构

AP（Application）：应用程序。
RM（Resource Manager）：数据库、消息队列等资源管理器。
TM（Transaction Manager）：事务协调者（如 Narayana、Atomikos）。

2.2.2 MySQL XA 示例

-- 开启 XA 事务
XA START 'tx1';
INSERT INTO account (id, balance) VALUES (1, 100);
XA END 'tx1';
XA PREPARE 'tx1';
XA COMMIT 'tx1';

3. 柔性事务：TCC 与 SAGA

3.1 TCC（Try-Confirm-Cancel）

3.1.1 工作原理

Try：预留资源（如冻结库存）。
Confirm：提交资源（如扣减库存）。
Cancel：释放资源（如解冻库存）。

3.1.2 源码实现：Seata TCC

Seata 是阿里开源的分布式事务框架，其 TCC 模式核心逻辑如下：

// Seata TCC 服务接口定义
public interface InventoryService {
    @TwoPhaseBusinessAction(name = "prepareDeduct", commitMethod = "commitDeduct", rollbackMethod = "rollbackDeduct")
    boolean prepareDeduct(BusinessActionContext context, @BusinessActionContextParameter(paramName = "skuId") String skuId, int count);
    
    boolean commitDeduct(BusinessActionContext context);
    
    boolean rollbackDeduct(BusinessActionContext context);
}

3.1.3 实际案例：电商下单

场景：用户下单需扣减库存、创建订单、扣减余额。
方案：

Try 阶段：冻结库存、预扣余额。
Confirm 阶段：实际扣减库存和余额。
Cancel 阶段：解冻库存、返还余额。

3.2 SAGA 事务

3.2.1 工作原理

SAGA 通过补偿操作回滚已完成的本地事务，适用于长事务场景。

正向操作：执行业务逻辑（如创建订单）。
补偿操作：撤销正向操作（如取消订单）。

3.2.2 源码实现：Apache ServiceComb Saga

Apache ServiceComb Saga 的 Alpha 服务器协调 SAGA 事务：

// SAGA 补偿逻辑示例
@SagaStart
public class OrderSaga {
    @Compensable(compensationMethod = "cancelOrder")
    public void createOrder(Order order) {
        orderRepository.save(order);
    }

    public void cancelOrder(Order order) {
        orderRepository.delete(order);
    }
}

3.2.3 实际案例：机票预订

场景：用户预订机票需调用航空公司、酒店、支付服务。
方案：

正向操作：预订机票 → 预订酒店 → 支付。
补偿操作：取消支付 → 取消酒店 → 取消机票。

4. 方案对比与选型指南

方案	一致性	性能	复杂度	适用场景
2PC	强一致性	低	低	短事务、强一致性场景
XA	强一致性	低	中	数据库跨库事务
TCC	最终一致	高	高	高并发、需资源预留的业务
SAGA	最终一致	中	中	长事务、异步补偿场景