[面试题] 讲讲RocketMQ的事务消息原理及回查机制？

📖 版块 A：知识讲解版 (温故知新)

RocketMQ解决“本地事务执行（写库）”和“发消息”的两难境地，保证最终一致性。

• 发送半消息（Half Message）：生产者先发一条状态为“Prepared”的半消息给Broker。对消费者不可见。
• 执行本地事务：半消息发送成功后，生产者执行本地数据库事务。
• 二次确认：本地事务成功，发 Commit 给Broker，半消息转为可见；本地事务失败，发 Rollback，Broker删除半消息。
• 回查机制（补偿）：如果网络断了Broker一直没收到确认，Broker的定时任务会主动反向询问生产者（回查），生产者查询本地单据状态，重新返回 Commit/Rollback。

🎤 版块 B：面试实战版 (高手逐字稿)

Q：讲讲RocketMQ的事务消息原理及回查机制？

🧠 破局思路：点出是为了解决分布式一致性问题，讲清“半消息”和兜底的“回查机制”。

💬 高手逐字稿： RocketMQ的事务消息是为了解决分布式下“本地写库”和“发MQ消息”的强一致性问题。它底层采用了基于两阶段提交加上补偿机制的方案。

流程是这样的：

1. 生产者先发送一条“半消息”到Broker。这个消息被存入了内部的特殊队列 RMQ_SYS_TRANS_HALF_TOPIC 中，所以消费者是看不见的。如果第一阶段发送成功，生产者才开始执行本地的数据库事务。
2. 如果本地事务执行成功，生产者就向Broker发送 Commit 指令，Broker就把消息挪到真实的Topic下，消费者就能消费了；如果本地事务失败，就发 Rollback 指令丢弃消息。
3. 补偿机制——“回查”。如果网络断了Broker一直没收到确认，Broker的定时任务会主动反向询问生产者（回查），生产者查询本地单据状态，重新返回 Commit/Rollback。