分布式事务: 主流最终一致性方案对比

分布式事务的最终一致性方案旨在确保在分布式系统中，所有参与方最终将达到一致的状态，尽管在过程中可能存在短暂的不一致。这种模型在保证系统可用性和分区容错性的同时，牺牲了强一致性的实时性要求。以下是几种主流的最终一致性方案的汇总与详解。

主流最终一致性方案对比

方案	一致性模型	性能	实现复杂度	典型适用场景	核心思想
TCC	最终一致	高	高	金融、电商核心业务（如扣减库存）	业务侵入补偿型事务，分为Try、Confirm、Cancel三个阶段。
Saga	最终一致	高	高	长流程、跨服务业务编排	将长事务拆分为一系列本地事务，通过正向执行和反向补偿来保证最终一致。
本地消息表	最终一致	中	中	异步通知、对账场景	利用数据库本地事务，将消息生产和业务操作绑定，通过异步轮询重试保证下游消费。
可靠消息（基于MQ）	最终一致	高	低	高并发、最终一致场景（如状态同步）	借助消息队列的持久化、重试和确认机制，确保消息至少被成功消费一次。

方案详解与示例

1. TCC (Try-Confirm-Cancel)

TCC是一种业务侵入性较强的补偿型事务，要求每个服务提供三个接口：Try（预留资源）、Confirm（确认提交）、Cancel（取消释放）。

核心原理：在Try阶段锁定或预留必要资源，所有参与者Try成功后，在Confirm阶段提交；若任一Try失败，则在Cancel阶段执行补偿操作，释放预留资源。

适用场景：适用于对一致性要求较高且能容忍短暂资源锁定的核心业务，如电商下单时的库存扣减和优惠券核销。

代码示例（库存服务伪代码）：

// 库存服务接口定义
public interface InventoryService {
    // Try: 预扣库存
    boolean tryDeduct(Long productId, Integer quantity);
    // Confirm: 确认扣减
    boolean confirmDeduct(Long productId, Integer quantity);
    // Cancel: 取消预扣，回退库存
    boolean cancelDeduct(Long productId, Integer quantity);
}

// 实现示例
@Service
public class InventoryServiceImpl implements InventoryService {
    @Override
    @Transactional
    public boolean tryDeduct(Long productId, Integer quantity) {
        // 检查并预扣库存（如将可用库存转入冻结库存）
        int rows = inventoryMapper.freezeStock(productId, quantity);
        return rows > 0;
    }

    @Override
    @Transactional
    public boolean confirmDeduct(Long productId, Integer quantity) {
        // 确认扣减，清除冻结记录
        return inventoryMapper.confirmFreeze(productId, quantity) > 0;
    }

    @Override
    @Transactional
    public boolean cancelDeduct(Long productId, Integer quantity) {
        // 取消预扣，将冻结库存加回可用库存
        return inventoryMapper.unfreezeStock(productId, quantity) > 0;
    }
}

2. Saga

Saga模式将一个分布式事务拆分为一系列连续的本地事务。每个本地事务都有对应的补偿事务。执行流程中，如果某个本地事务失败，则会按相反顺序触发前面所有已成功事务的补偿操作。

适用场景：适用于业务流程长、步骤多、跨多个服务的场景，如机票酒店预订流程。

实现模式：

• 编排式：由一个中心协调器来触发并监听各个服务。
• 协同式：每个服务完成后触发下一个服务，并知晓自己的补偿操作。

3. 本地消息表

该方案利用数据库的本地事务原子性，将消息生产和业务操作放在同一个事务中。

核心流程：

1. 业务服务在完成本地数据库操作的同时，向同一数据库的“消息表”插入一条待发送的消息记录。
2. 有一个独立的“消息发送者”定时轮询消息表，将未发送的消息投递到消息队列。
3. 下游消费者从MQ消费消息，处理业务，处理成功后调用回调接口或发送确认消息。
4. 消息发送者收到确认后，将消息状态更新为“已发送”或删除。

代码示例（订单创建与消息存储）：

-- 在同一事务中执行订单创建和消息记录插入
START TRANSACTION;

-- 1. 创建订单
INSERT INTO `order` (order_id, user_id, amount, status) VALUES ('O001', 1001, 299.00, 'CREATED');

-- 2. 在本地消息表中记录待发送的“扣减库存”事件
INSERT INTO `outbox_message` (message_id, `topic`, payload, status, created_time)
VALUES (UUID(), 'inventory.deduct', '{"orderId":"O001","productId":"P1001","quantity":1}', 'PENDING', NOW());

COMMIT;

4. 可靠消息（基于消息队列）

此方案高度依赖消息队列（如RocketMQ、Kafka）的事务消息或类似机制来保证可靠性。

核心流程（以RocketMQ事务消息为例）：

1. 发送半消息：生产者向MQ发送一个“半消息”（对消费者不可见）。
2. 执行本地事务：生产者执行本地业务逻辑（如创建订单）。
3. 提交或回滚：根据本地事务执行结果，向MQ发送Commit或Rollback指令。
   • Commit：半消息变为正式消息，可供消费者消费。
   • Rollback：消息被丢弃。
4. 消费与重试：消费者消费消息并处理业务。如果消费失败，MQ会按重试策略重新投递，直到成功或进入死信队列。

配置示例（RocketMQ生产者）：

// 创建事务监听器，用于执行本地事务和检查本地事务状态
TransactionListener transactionListener = new TransactionListenerImpl();
TransactionMQProducer producer = new TransactionMQProducer("please_rename_unique_group_name");
producer.setNamesrvAddr("localhost:9876");
producer.setTransactionListener(transactionListener);
producer.start();

// 发送事务消息
Message msg = new Message("OrderTopic", "TagA", "OrderID001", "Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
SendResult sendResult = producer.sendMessageInTransaction(msg, null); // 第二个参数可用于传递业务参数

方案选型建议

• 高并发与业务复杂：优先考虑TCC，因其性能好且业务控制粒度细。
• 简单业务，允许延迟：使用本地消息表，实现相对简单，对中间件依赖小。
• 长流程、跨系统编排：Saga模式更为合适，适合流程化的业务场景。
• 已深度依赖消息队列：直接采用可靠消息方案，充分利用MQ的成熟能力实现最终一致。

在实际架构中，常组合使用多种方案。例如，一个电商下单系统可能：创建订单使用本地事务；扣减库存采用TCC或预扣库存；优惠券核销采用预冻结+最终扣减；而支付成功后的状态同步则通过消息队列保证最终一致性。系统必须设计完善的补偿机制，如订单超时未支付时触发库存回退和优惠券释放，并配合重试、告警等异常处理策略。

---

参考来源

• 分布式事务一致性方案介绍_分布式事务处理多喝保证库存、订单、优惠券核销原子性-优快云博客
• 分布式事务里的最终一致性
• 分布式事务处理与一致性保障方案详解