RocketMQ 事务消息：解决分布式事务一致性问题

分布式系统中，跨服务的事务一致性是核心挑战。传统两阶段提交（2PC）存在性能瓶颈和协调者单点故障问题。RocketMQ 的事务消息机制通过异步解耦和最终一致性模型，提供高效解决方案。

一、核心原理：两阶段事务

1. 第一阶段：发送半消息
   生产者发送事务消息（半消息）到 Broker：

   • 消息对消费者不可见
   • Broker 持久化消息并返回确认
   • 状态：$$ \text{Prepared} $$

2. 第二阶段：提交/回滚
   生产者执行本地事务后通知 Broker：

   • 提交：消息变为可见状态（$$ \text{Committed} $$）
   • 回滚：消息直接删除（$$ \text{Rollbacked} $$）
   • 超时机制：未确认时触发回查

graph LR
A[生产者] -->|1. 发送半消息| B(Broker)
A -->|2. 执行本地事务| C[DB]
A -->|3. 提交/回滚| B
B -->|4. 投递消息| D[消费者]

二、事务状态回查机制

当生产者宕机或超时未响应时，Broker 主动发起回查：

1. 生产者需实现 TransactionListener 接口
2. 通过回调查询本地事务状态
3. 保证消息最终一致性

Java 实现示例：

public class OrderTransactionListener implements TransactionListener {
    // 执行本地事务
    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        try {
            createOrder(msg); // 数据库操作
            return LocalTransactionState.COMMIT_MESSAGE;
        } catch (Exception e) {
            return LocalTransactionState.ROLLBACK_MESSAGE;
        }
    }

    // 事务回查
    @Override
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        return orderExists(msg) ? 
            LocalTransactionState.COMMIT_MESSAGE : 
            LocalTransactionState.ROLLBACK_MESSAGE;
    }
}

三、典型应用场景

1. 电商下单流程

   • 事务消息：订单创建（生产者） → 扣减库存（消费者）
   • 保证：订单创建成功 ⇔ 库存扣减最终执行

2. 跨行转账

   • 事务消息：A银行扣款 → B银行入账
   • 避免：A扣款成功但B入账失败

四、优势与局限

优势	局限
✅ 解耦业务系统	⚠️ 最终一致性（非强一致）
✅ 高吞吐（异步）	⚠️ 需实现回查逻辑
✅ 避免单点故障	⚠️ 消息延迟（通常<3s）

五、最佳实践

1. 幂等设计：消费者需处理重复消息
2. 超时控制：回查超时建议设 60s
3. 事务日志：记录本地事务与消息ID关联
4. 监控告警：跟踪 COMMIT/ROLLBACK 比例

关键结论：RocketMQ 事务消息通过 $$ \text{半消息} + \text{事务回查} $$ 机制，在保证数据最终一致性的同时，实现比传统 2PC 高 10 倍以上的吞吐量，成为分布式事务的首选方案之一。