Java `Distributed Transaction` (`Saga Pattern`, `Two-Phase Commit`) 解决方案

各位老铁，大家好！今天咱们聊聊Java分布式事务这块硬骨头，保证各位听完能啃下来，至少能啃掉一层皮！

开场白：为啥我们需要分布式事务？

想象一下，你经营一家电商网站，用户下单扣库存、生成订单、支付积分，这三个操作得要么一起成功，要么一起失败，保证数据一致性。如果这三个服务部署在不同的服务器上，那就变成了分布式事务。单机事务那一套就玩不转了，咋办？ 这就是我们今天要解决的问题。

第一部分：分布式事务的理论基础

分布式事务，简单来说，就是保证多个服务之间的数据操作要么全部成功，要么全部失败。有点像“不求同年同月同日生，但求同年同月同日死”的兄弟情义，要么一起活，要么一起挂。

1. CAP 理论:

CAP 理论是分布式系统的基石，它告诉我们，在一个分布式系统中，Consistency（一致性）、Availability（可用性）和 Partition Tolerance（分区容错性）这三个要素，最多只能同时满足两个。

• Consistency (一致性): 所有节点看到的数据都是最新的，就像照镜子一样，大家看到的是同一个自己。
• Availability (可用性): 每个请求都能得到响应，服务一直可用，就像 7×24 小时便利店。
• Partition Tolerance (分区容错性): 系统的一部分节点发生故障，系统仍然能正常运行，就像一艘船，即使一部分船舱漏水，船也能继续航行。

在分布式系统中，分区容错性是必须的，因为网络总是可能出现问题。所以，我们只能在一致性和可用性之间做出权衡。

2. BASE 理论:

BASE 理论是对 CAP 理论的一种妥协，它强调最终一致性。BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）的缩写。

• Basically Available (基本可用): 允许系统在出现故障时，损失部分可用性，保证核心功能可用。
• Soft state (软状态): 允许系统存在中间状态，这些状态可能会随着时间的推移而改变。
• Eventually consistent (最终一致性): 经过一段时间后，系统的数据最终会达到一致状态。

BASE 理论适用于对一致性要求不高的场景，例如社交应用的评论、点赞等。

第二部分：分布式事务解决方案

好了，理论铺垫完毕，现在进入正题，看看有哪些方案能解决分布式事务问题。

1. 两阶段提交 (Two-Phase Commit, 2PC):

2PC 是一种强一致性的分布式事务协议。它分为两个阶段：准备阶段 (Prepare Phase) 和提交阶段 (Commit Phase)。

• 准备阶段: 协调者 (Coordinator) 向所有参与者 (Participant) 发送准备请求，询问是否可以执行事务。参与者执行事务，但不提交，并返回准备结果（同意或拒绝）。
• 提交阶段: 如果所有参与者都同意，协调者向所有参与者发送提交请求，参与者提交事务。如果任何一个参与者拒绝，协调者向所有参与者发送回滚请求，参与者回滚事务。

优点: 强一致性，保证数据的一致性。

缺点: 性能差，阻塞时间长。协调者单点故障问题，如果协调者挂了，整个系统就瘫痪了。

代码示例 (伪代码):

// 协调者
public class Coordinator {
    private List<Participant> participants;

    public boolean prepare() {
        List<Boolean> results = new ArrayList<>();
        for (Participant participant : participants) {
            results.add(participant.prepare());
        }
        return results.stream().allMatch(result -> result == true);
    }

    public void commit() {
        for (Participant participant : participants) {
            participant.commit();
        }
    }

    public void rollback() {
        for (Participant participant : participants) {
            participant.rollback();
        }
    }
}

// 参与者
public interface Participant {
    boolean prepare();
    void commit();
    void rollback();
}

// 参与者实现
public class ParticipantImpl implements Participant {
    @Override
    public boolean prepare() {
        // 执行事务操作，但不提交
        // 返回 true 表示同意，false 表示拒绝
        return true; // 假设同意
    }

    @Override
    public void commit() {
        // 提交事务
    }

    @Override
    public void rollback() {
        // 回滚事务
    }
}

2. 三阶段提交 (Three-Phase Commit, 3PC):

3PC 是对 2PC 的改进，试图解决 2PC 的阻塞问题。它增加了预提交阶段 (PreCommit Phase)。

• 准备阶段: 协调者向所有参与者发送准备请求，询问是否可以执行事务。
• 预提交阶段: 如果所有参与者都同意，协调者向所有参与者发送预提交请求，参与者执行事务，但不提交，并返回确认结果。
• 提交阶段: 如果所有参与者都确认，协调者向所有参与者发送提交请求，参与者提交事务。如果任何一个参与者拒绝或超时，协调者向所有参与者发送回滚请求，参与者回滚事务。

优点: 相比 2PC，降低了阻塞时间。

缺点: 仍然存在数据不一致的可能，因为在预提交阶段，如果协调者挂了，参与者无法知道是否需要提交。

3. TCC (Try-Confirm-Cancel):

TCC 是一种柔性事务解决方案，它将事务分为三个阶段：

• Try: 尝试执行业务，完成所有业务检查 (一致性)，预留必须的业务资源 (准隔离性)。
• Confirm: 确认执行业务，真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源。Confirm 操作要满足幂等性。
• Cancel: 取消执行业务，释放 Try 阶段预留的业务资源。Cancel 操作也要满足幂等性。

优点: 性能好，解决了 2PC 的阻塞问题。

缺点: 开发难度大，需要针对每个业务操作编写 Try、Confirm 和 Cancel 三个方法。

代码示例:

// 扣库存的 TCC 接口
public interface InventoryTcc {
    @TwoPhaseBusinessAction(name = "inventoryTcc", commitMethod = "commit", rollbackMethod = "cancel")
    boolean tryDeduct(BusinessActionContext ctx, String productId, int quantity);

    boolean commit(BusinessActionContext ctx);

    boolean cancel(BusinessActionContext ctx);
}

// 扣库存的 TCC 实现
@Service
public class InventoryTccImpl implements InventoryTcc {

    @Override
    public boolean tryDeduct(BusinessActionContext ctx, String productId, int quantity) {
        // 检查库存是否足够
        if (inventoryService.checkInventory(productId, quantity)) {
            // 预留库存
            inventoryService.reserveInventory(productId, quantity);
            return true;
        } else {
            return false;
        }
    }

    @Override
    public boolean commit(BusinessActionContext ctx) {
        // 真正扣减库存
        String productId = (String) ctx.getActionContext("productId");
        int quantity = (Integer) ctx.getActionContext("quantity");
        inventoryService.deductInventory(productId, quantity);
        return true;
    }

    @Override
    public boolean cancel(BusinessActionContext ctx) {
        // 释放预留库存
        String productId = (String) ctx.getActionContext("productId");
        int quantity = (Integer) ctx.getActionContext("quantity");
        inventoryService.releaseInventory(productId, quantity);
        return true;
    }
}

4. Saga 模式:

Saga 模式将一个分布式事务拆分成多个本地事务，每个本地事务对应一个 Saga 步骤。Saga 模式有两种恢复策略：

• 补偿模式: 每个 Saga 步骤都有一个对应的补偿操作，如果 Saga 事务失败，就执行所有已成功 Saga 步骤的补偿操作，回滚数据。
• 重试模式: 如果 Saga 步骤失败，就不断重试，直到成功为止。

优点: 性能好，容错性高。

缺点: 最终一致性，数据一致性时间较长。需要处理幂等性问题。

代码示例:

// Saga 接口
public interface Saga {
    void compensate(SagaStep step);
}

// Saga 步骤接口
public interface SagaStep {
    void execute();
    void compensate();
}

// 下单 Saga
public class OrderSaga implements Saga {
    private List<SagaStep> steps = new ArrayList<>();

    public void addStep(SagaStep step) {
        steps.add(step);
    }

    public void execute() {
        try {
            for (SagaStep step : steps) {
                step.execute();
            }
        } catch (Exception e) {
            // 执行补偿操作
            compensate(steps.get(steps.size() - 1)); // 从最后一个步骤开始补偿
            throw e;
        }
    }

    @Override
    public void compensate(SagaStep step) {
        for (int i = steps.indexOf(step); i >= 0; i--) {
            steps.get(i).compensate();
        }
    }
}

// 创建订单 Saga 步骤
public class CreateOrderStep implements SagaStep {
    @Override
    public void execute() {
        // 创建订单
    }

    @Override
    public void compensate() {
        // 删除订单
    }
}

5. 消息队列 (Message Queue):

使用消息队列来实现最终一致性事务。将事务操作封装成消息发送到消息队列，消费者监听消息队列，执行相应的事务操作。如果消费者执行失败，可以重试或者发送补偿消息。

优点: 解耦性好，异步处理，性能高。

缺点: 最终一致性，需要处理消息丢失、重复消费等问题。

代码示例:

// 发送消息
public void sendMessage(String message) {
    kafkaTemplate.send("topic", message);
}

// 监听消息
@KafkaListener(topics = "topic")
public void listen(String message) {
    // 执行事务操作
    try {
        // ...
    } catch (Exception e) {
        // 处理异常，可以重试或者发送补偿消息
    }
}

6. Seata:

Seata 是一款开源的分布式事务解决方案，它提供了 AT、TCC、Saga 和 XA 四种事务模式。Seata 通过全局事务管理器 (Transaction Coordinator, TC) 来协调分布式事务。

• AT (Automatic Transaction): 基于数据库的 undo log 实现，对业务代码无侵入。
• TCC: 前面已经介绍过。
• Saga: 前面已经介绍过。
• XA: 基于 XA 协议，适用于强一致性场景。

优点: 提供了多种事务模式，可以根据不同的场景选择合适的模式。

缺点: 需要引入 Seata 组件。

代码示例 (AT 模式):

@GlobalTransactional(timeoutMills = 300000, name = "order-create")
public void createOrder(Order order) {
    // ...
    orderService.create(order);
    accountService.debit(order.getUserId(), order.getAmount());
    storageService.deduct(order.getProductId(), order.getQuantity());
    // ...
}

第三部分：如何选择合适的分布式事务解决方案？

选择合适的分布式事务解决方案需要考虑以下因素：

• 一致性要求: 如果对数据一致性要求非常高，可以选择 2PC 或 XA。如果可以接受最终一致性，可以选择 TCC、Saga 或消息队列。
• 性能要求: 如果对性能要求很高，可以选择 TCC、Saga 或消息队列。2PC 的性能较差。
• 开发难度: TCC 的开发难度较高，需要针对每个业务操作编写 Try、Confirm 和 Cancel 三个方法。Saga 的开发难度也较高，需要设计补偿操作。
• 系统复杂度: 如果系统复杂度较高，可以选择 Seata，它提供了多种事务模式，可以根据不同的场景选择合适的模式。

总结:

方案	一致性	性能	开发难度	适用场景
2PC	强一致性	差	低	对一致性要求非常高的场景，例如银行转账
3PC	弱一致性	较差	低	对一致性要求较高的场景
TCC	最终一致性	好	高	对性能要求较高的场景，例如电商订单
Saga	最终一致性	好	高	适用于长事务，例如跨多个服务的业务流程
消息队列	最终一致性	好	中	适用于异步处理，例如异步通知
Seata	可配置	可配置	中	适用于复杂的分布式系统，提供了多种事务模式

尾声：分布式事务，任重道远

分布式事务是一个复杂的问题，没有银弹。我们需要根据具体的业务场景和系统架构，选择合适的解决方案。希望今天的讲座能帮助大家更好地理解分布式事务，并在实际项目中应用。

记住，没有最好的方案，只有最合适的方案！ 祝大家早日征服分布式事务这座大山！

最后，感谢各位老铁的耐心聆听！ 散会！