RocketMQ 消息生产：事务消息详解

🚀 RocketMQ 消息生产：事务消息详解

半消息、本地事务、提交/回滚｜解决分布式事务一致性｜最终一致性思想

在分布式系统中，如何保证“本地事务执行”与“消息发送”之间的数据一致性，是一个经典难题。
RocketMQ 提供了强大的 事务消息（Transactional Message） 机制，通过“半消息 + 事务状态回查”方案，完美解决了这一问题。

本文将深入解析事务消息的核心流程、设计原理、应用场景以及背后的最终一致性思想。

---

一、问题背景：分布式事务的挑战

❌ 经典问题：

“先执行本地事务（如扣库存），再发消息” → 若本地事务成功但消息发送失败，怎么办？
“先发消息，再执行本地事务” → 若消息发送成功但本地事务失败，消费者收到无效消息。

📌 场景示例：订单系统

1. 用户下单
2. 扣减库存（本地事务）
3. 发送“订单创建”消息给物流系统

❌ 风险：
- 扣库存成功，但消息未发送 → 物流系统不知道订单，导致漏单
- 消息发送成功，但扣库存失败 → 物流系统收到错误订单

✅ 需要一种机制，确保：“本地事务成功 ⇔ 消息被投递”

---

二、RocketMQ 事务消息的核心思想

✅ 核心目标：

实现 “本地事务” 与 “消息发送” 的最终一致性。

🔑 实现方式：

引入 “半消息（Half Message）” + “事务状态回查” 机制，基于两阶段提交（2PC）思想。

---

三、事务消息的完整流程（六步）

1. 生产者发送“半消息”（Half Message）
   ↓
2. Broker 存储消息但不投递（消费者不可见）
   ↓
3. 执行本地事务（如扣库存、写数据库）
   ↓
4. 根据本地事务结果提交或回滚消息
   ↓
5. 若未提交，Broker 定期回查事务状态
   ↓
6. 生产者返回真实状态，Broker 决定是否投递

🔄 详细步骤解析：

Step 1：发送半消息（Prepare Phase）

• 生产者调用 sendMessageInTransaction() 发送消息
• Broker 接收后，将消息标记为 “半消息”，存入特殊主题 RMQ_SYS_TRANS_HALF_TOPIC
• 不投递给消费者（不可见）
• 返回 PREPARED 状态

Step 2：执行本地事务

• RocketMQ 回调 executeLocalTransaction 方法
• 开发者在此执行本地操作（如更新订单状态、扣减库存）

@Override
public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
    try {
        // 执行本地事务：扣库存
        inventoryService.reduce(msg.getOrderId());
        return LocalTransactionState.COMMIT_MESSAGE; // 成功
    } catch (Exception e) {
        return LocalTransactionState.ROLLBACK_MESSAGE; // 失败
    }
}

Step 3：提交或回滚事务

• 根据 executeLocalTransaction 返回结果：
  • COMMIT_MESSAGE → Broker 将消息转为“可消费”，投递给消费者
  • ROLLBACK_MESSAGE → Broker 删除半消息
  • UNKNOW → 暂不处理，等待回查

Step 4：事务状态回查（Check Phase）

• 如果生产者宕机，未返回事务状态
• Broker 从 prepare 状态开始，每隔 30 秒调用一次 checkLocalTransaction
• 生产者需实现该方法，返回本地事务的真实状态

@Override
public LocalTransactionState checkLocalTransaction(MessageExt msg) {
    String transactionId = msg.getTransactionId();
    // 查询本地事务日志表
    TransactionRecord record = transactionLogService.get(transactionId);
    if (record == null) {
        return LocalTransactionState.UNKNOW;
    } else if (record.getStatus() == "COMMITTED") {
        return LocalTransactionState.COMMIT_MESSAGE;
    } else if (record.getStatus() == "ROLLED_BACK") {
        return LocalTransactionState.ROLLBACK_MESSAGE;
    }
    return LocalTransactionState.COMMIT_MESSAGE;
}

✅ 回查机制确保：即使生产者崩溃，最终也能确定事务状态。

---

四、事务消息如何解决一致性问题？

问题	事务消息的解决方案
本地事务成功，消息未发送	消息已作为“半消息”存储，提交后即可投递
消息发送成功，本地事务失败	半消息不会投递，只有提交后才可见
生产者宕机未响应	Broker 回查本地事务状态，确保最终一致性
网络抖动、超时	支持重试和回查，避免状态不一致

✅ 实现了：“本地事务成功” ⇔ “消息最终被消费”

---

五、最终一致性（Eventual Consistency）思想

✅ 定义：

最终一致性 是分布式系统中的一种一致性模型，允许系统在一段时间内存在不一致，但最终会达到一致状态。

🔄 在事务消息中的体现：

• 半消息阶段：消息未投递，系统暂时不一致
• 提交后：消息可消费，系统恢复一致
• 回查机制：确保即使异常，最终也能达成一致

✅ 优势：

• 避免强一致性带来的性能瓶颈（如分布式锁、2PC 阻塞）
• 适用于高并发、高可用场景
• 符合 CAP 理论中的 AP 设计（可用性优先）

🚀 RocketMQ 事务消息是“最终一致性”的典型实践。

---

六、事务消息的使用场景

场景	说明
订单创建 + 扣库存	保证订单与库存一致
支付成功 + 更新订单状态	防止状态不一致
转账操作	扣款与通知同步
积分发放	发放积分与消息通知原子性
跨系统数据同步	A 系统写库 + B 系统接收通知

✅ 适用于：任何需要“本地操作 + 消息通知”原子性的场景

---

七、事务消息的限制与注意事项

限制	说明
❌ 不支持广播模式	仅支持集群消费
❌ 不支持延时消息	与事务机制冲突
⚠️ 回查可能多次执行	需保证 checkLocalTransaction 幂等
⚠️ 本地事务需记录日志	建议将事务状态写入数据库，供回查使用
⚠️ 性能略低于普通消息	多一次网络交互
⚠️ 最大回查次数可配置	默认 15 次，可通过 transactionCheckMax 配置

---

八、最佳实践建议

实践	说明
✅ 将事务状态写入数据库	如 transaction_log 表，包含 tx_id, status, create_time
✅ checkLocalTransaction 必须幂等	可能被多次调用
✅ 设置合理的回查间隔	默认 30s，可调
✅ 监控半消息堆积	防止大量未决事务
✅ 避免在本地事务中执行耗时操作	防止超时
✅ 使用 TransactionMQProducer	而非 DefaultMQProducer

---

✅ 总结：事务消息核心要点

概念	说明
半消息	暂不投递的消息，用于“预占位”
本地事务执行	开发者实现业务逻辑
提交/回滚	决定消息是否投递
事务状态回查	解决生产者宕机问题
最终一致性	允许短暂不一致，但最终达成一致

🚀 一句话总结：
RocketMQ 事务消息通过 “半消息 + 回查” 机制，实现了 “本地事务” 与 “消息发送” 的最终一致性，是解决分布式事务的经典方案。

掌握事务消息，你就能在高并发场景下，构建出可靠、一致、可恢复的异步业务流程。