在分布式系统中，跨服务的事务一致性是架构设计的核心挑战之一。尤其在电商、金融等高并发场景中，如何保障数据操作的原子性和一致性，直接影响系统的可靠性和用户体验。本文将深入剖析6种主流分布式事务方案，结合具体场景和Java代码示例，帮助开发者快速理解并应用。文末提供方案对比表及选型指南。

一、分布式事务的本质与挑战

分布式事务的核心目标是确保跨多个独立服务或数据库的操作满足 ACID 中的原子性（Atomicity）和一致性（Consistency）。其难点主要来自以下场景：

1. 写后读不一致：更新数据库后，缓存未及时失效

场景描述：
当应用程序更新了数据库中的数据后，如果缓存中的旧数据没有及时被清除或更新，后续的读取操作可能会从缓存中读取到过期的数据，导致“写后读不一致”。

举例说明：
假设有一个电商系统，用户A修改了自己的收货地址。系统首先将新地址写入数据库，但此时缓存中仍然保存着旧的收货地址。如果另一个用户B紧接着查询该用户的收货地址，可能会从缓存中读取到旧的地址信息，这就是典型的“写后读不一致”。

2. 并发读写竞争：多个线程同时修改同一数据

场景描述：
当多个线程或进程同时对同一数据进行读写操作时，可能会出现并发冲突，导致数据不一致或部分更新丢失。

举例说明：
在一个在线论坛系统中，两个用户几乎同时编辑同一篇文章。假设系统先处理了用户A的更新请求，并将新内容写入数据库和缓存。然而，在这之前，用户B也提交了编辑请求。如果系统没有适当的并发控制机制，用户B的更新可能会覆盖用户A的更改，或者两者的结果相互干扰，导致文章内容混乱。

3. 缓存与数据库事务不同步：部分成功导致数据错乱

场景描述：
在分布式系统中，缓存和数据库的操作通常不在同一个事务中管理。如果其中一个操作失败，而另一个成功，就会导致数据不一致。

举例说明：
考虑一个金融交易系统，用户发起一笔转账操作。系统需要同时更新数据库中的账户余额，并更新缓存中的用户余额信息。如果在更新数据库成功后，更新缓存时发生网络故障或其他异常，缓存中的余额将不会反映最新的转账结果。此时，用户再次查询余额时，可能会看到错误的金额。

---

二、六大分布式事务方案详解

1. 两阶段提交（2PC）——强一致性

适用场景

• 金融转账：如银行跨行转账，要求强一致性
• 传统企业系统：内部服务间严格的数据同步

实现原理

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

Java代码示例

// 协调者（简化版）
public class TwoPCController {
    public boolean transfer(Account from, Account to, BigDecimal amount) {
        List<Participant> participants = Arrays.asList(from, to);
        
        // 阶段一：Prepare
        boolean allPrepared = participants.stream()
            .allMatch(p -> p.prepare(amount));
        
        // 阶段二：Commit或Rollback
        if (allPrepared) {
            participants.forEach(p -> p.commit());
            return true;
        } else {
            participants.forEach(p -> p.rollback());
            return false;
        }
    }
}

// 参与者（银行账户）
public class BankAccount implements Participant {
    @Override
    public boolean prepare(BigDecimal amount) {
        // 检查余额是否充足并预冻结
        return accountDao.freezeBalance(amount);
    }
    
    @Override
    public void commit() {
        // 实际扣减预冻结金额
        accountDao.deductFrozenAmount();
    }
    
    @Override
    public void rollback() {
        // 释放预冻结金额
        accountDao.unfreezeAmount();
    }
}

特点

• 一致性：强一致性
• 缺点：同步阻塞、协调者单点故障

---

2. TCC（Try-Confirm-Cancel）——最终一致性

适用场景

• 电商下单：高并发场景下的订单创建与库存扣减
• 票务系统：演唱会门票抢购

实现原理

• Try：预留资源（如冻结库存）
• Confirm：确认操作（实际扣减）
• Cancel：补偿回滚（释放资源）

Java代码示例

public class OrderService {
    // Try阶段：冻结库存
    @Transactional
    public boolean tryCreateOrder(Long productId, int quantity) {
        if (!inventoryService.freezeStock(productId, quantity)) {
            throw new RuntimeException("库存不足");
        }
        return true;
    }

    // Confirm阶段：生成订单
    @Transactional
    public void confirmOrder(Long orderId) {
        orderDao.updateStatus(orderId, "CONFIRMED");
        inventoryService.deductStock(orderId);
    }

    // Cancel阶段：释放库存
    @Transactional
    public void cancelOrder(Long orderId) {
        orderDao.updateStatus(orderId, "CANCELED");
        inventoryService.unfreezeStock(orderId);
    }
}

特点

• 一致性：最终一致性
• 缺点：需手动实现补偿逻辑

---

3. Saga模式——最终一致性

适用场景

• 物流系统：订单创建 → 物流发货 → 支付结算
• 保险理赔：多步骤长流程业务

实现原理

• 将长事务拆分为多个本地事务，依次执行
• 任一事务失败，触发已执行事务的补偿操作

Java代码示例

public class InsuranceSaga {
    public void handleClaim(Long claimId) {
        // 步骤1：创建理赔申请
        claimDao.create(claimId);
        
        try {
            // 步骤2：审核资料
            auditService.verifyDocuments(claimId);
            
            // 步骤3：打款
            paymentService.transfer(claimId);
        } catch (Exception e) {
            // 补偿：撤销理赔申请
            claimDao.cancel(claimId);
            throw e;
        }
    }
}

特点

• 一致性：最终一致性
• 缺点：补偿逻辑复杂

---

4. 本地消息表——最终一致性

适用场景

• 订单状态通知：订单支付成功后通知物流系统
• 用户积分变更：异步更新用户积分

实现原理

• 业务与消息表在同一个数据库事务中写入
• 后台任务轮询消息表，发送消息到MQ并重试

Java代码示例

@Transactional
public void payOrder(Long orderId) {
    // 1. 更新订单状态为已支付
    orderDao.updateStatus(orderId, "PAID");
    
    // 2. 写入本地消息表（同一事务）
    LocalMessage message = new LocalMessage();
    message.setBizId("order_paid:" + orderId);
    message.setContent("{\"orderId\":" + orderId + "}");
    messageDao.insert(message);
}

// 后台任务发送消息
@Scheduled(fixedRate = 5000)
public void sendMessages() {
    List<LocalMessage> messages = messageDao.selectUnsent();
    messages.forEach(msg -> {
        try {
            rocketMQTemplate.send("order_topic", msg.getContent());
            messageDao.markAsSent(msg.getId());
        } catch (Exception e) {
            messageDao.increaseRetryCount(msg.getId());
        }
    });
}

特点

• 一致性：最终一致性
• 缺点：业务耦合度高

---

5. MQ事务消息——最终一致性

适用场景

• 支付回调：支付成功后通知订单系统
• 库存扣减：下单后异步扣减库存

为什么普通消息重试不行？

普通消息在发送后无法撤回，若本地事务失败，消费者仍会消费消息，导致数据不一致。例如：

1. 消息发送成功，本地事务失败：消费者处理无效数据
2. 本地事务成功，消息发送失败：业务状态无法同步

实现原理

• 半消息：发送预备消息到MQ（消费者不可见）
• 本地事务执行：执行业务逻辑
• 事务状态确认：提交或回滚消息

Java代码示例（RocketMQ）

public class OrderTransactionListener implements TransactionListener {
    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        try {
            Order order = (Order) arg;
            orderDao.create(order); // 本地事务
            return LocalTransactionState.COMMIT_MESSAGE;
        } catch (Exception e) {
            return LocalTransactionState.ROLLBACK_MESSAGE;
        }
    }

    @Override
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        String orderId = msg.getKeys();
        return orderDao.exists(orderId) ? 
            LocalTransactionState.COMMIT_MESSAGE : 
            LocalTransactionState.ROLLBACK_MESSAGE;
    }
}

// 发送事务消息
public void createOrder(Order order) {
    Message msg = new Message("order_topic", order.toJson().getBytes());
    rocketMQTemplate.sendMessageInTransaction(msg, order);
}

特点

• 一致性：最终一致性
• 缺点：免费版不稳定、好像也不支持事务消息

---

6. Seata AT模式——强一致性

适用场景

• 传统企业应用改造：单体应用拆分后的数据一致性
• 库存管理：多服务共享库存数据

实现原理

• 全局事务ID：Seata Server协调分布式事务
• 自动回滚：通过反向SQL生成补偿逻辑

Java代码示例

@GlobalTransactional
public void placeOrder(Order order) {
    // 服务A：扣减库存
    inventoryFeignClient.deduct(order.getProductId(), order.getQuantity());
    
    // 服务B：创建订单
    orderDao.insert(order);
    
    // 服务C：扣减优惠券
    couponFeignClient.use(order.getUserId(), order.getCouponId());
}

特点

• 一致性：强一致性
• 缺点：性能损耗较大

---

三、方案对比与选型指南

方案	一致性级别	性能	复杂度	适用场景
2PC	强一致性	低	高	金融转账
TCC	最终一致性	中	高	高并发订单系统
Saga	最终一致性	高	中	长流程业务（如保险理赔）
本地消息表	最终一致性	中	低	异步通知场景
MQ事务消息	最终一致性	高	中	支付回调、库存扣减
Seata AT	强一致性	中	低	企业级应用改造

---

四、为什么必须使用事务消息？

普通消息重试的致命缺陷：

1. 消息与事务状态割裂：

   • 若消息发送成功但本地事务失败，消费者将处理无效数据。
   • 若本地事务成功但消息未发送，业务状态无法同步。

2. 无法保证原子性：

   • 普通消息无法实现“消息发送”与“本地事务”的原子操作。

事务消息的核心优势：

1. 两阶段提交：

   • 半消息阶段：消息暂存MQ，消费者不可见。
   • 事务确认阶段：本地事务成功后提交消息，失败则回滚。

2. 事务状态回查：

   • MQ主动询问生产者事务状态，解决超时问题。

3. 自动丢弃无效消息：

   • 若事务回滚，MQ自动删除半消息，避免脏数据。

---

五、总结与最佳实践

1. 强一致性场景（如金融系统）：

   • 优先选择 2PC 或 Seata AT，但需接受性能损耗。

2. 高并发最终一致性场景（如电商下单）：

   • TCC 或 MQ事务消息 是最佳选择。

3. 长业务流程（如物流跟踪）：

   • 使用 Saga模式，配合补偿机制。

注意事项：

• 所有方案需配合 幂等设计 和 重试机制。
• 监控事务执行状态（如分布式链路追踪）。