RocketMQ 事务消息为什么要设计回查？回查超时或多次失败后，消息的最终状态如何确定？

完整讲解（权威版）

最后更新：2026-10-23 · 基于第 1 次作答

L1 · 30 秒速记

结论：回查是 Broker 对"半消息已落地但生产者没给结论"的兜底机制，让事务消息在生产者崩溃时仍能收敛。 关键词：半消息 · 回查 · 递增间隔 · 最大回查次数 边界：回查只判断本地事务状态，不能替代业务幂等与对账。

L2 · 核心讲解

核心考点定位：能否说清回查的触发原因（生产者失联）、判定依据（本地事务状态）和收敛规则（超时后按失败处理）。

机制链（≥3 环）：

1. 发送半消息 → 生产者把消息发给 Broker，Broker 落库但不投递给消费者，消费者不可见。
2. 本地事务执行 → 生产者执行本地业务，成功后 Commit（半消息转为可见），失败后 Rollback（Broker 删除半消息）。
3. 回查触发 → 生产者未在规定时间内给出结论（崩溃、超时、网络抖动），Broker 主动回查生产者。
4. 收敛判定 → 回查按递增间隔重试，达到最大次数仍无结论则按失败处理，删除半消息。

证据锚点：

• 半消息（Half Message）：已落库但对消费者不可见的消息状态。
• transactionCheckMax：最大回查次数，默认 15 次。
• transactionCheckInterval：回查间隔，默认 60 秒，且间隔递增。
• checkLocalTransaction：生产者实现的回查回调，返回 Commit / Rollback / Unknown。
• 事务状态表：回查判定的依据，必须与本地事务同库同事务写入。
• 死信队列：多次回查失败后的最终去向，需人工介入。

对比与权衡：

常见误区：

1. 错误：回查失败后消息直接丢弃 → 正确：达到最大回查次数后按 Rollback 处理并删除半消息 → 为什么：半消息不能永久悬挂，否则消费者永远看不到。
2. 错误：回查可以判断业务是否成功 → 正确：回查只能查询本地事务状态，无法判断下游是否消费成功 → 为什么：消费成功与否由消费端幂等和对账保证。
3. 错误：回查间隔固定 → 正确：间隔递增，避免高频回查打垮生产者 → 为什么：生产者可能正在恢复，需要缓冲时间。

适用边界：回查解决的是"生产者失联"，不解决"消费者处理失败"；后者要靠消费端重试、幂等和死信队列。

延伸追问（≥3）

1. 回查回调返回 Unknown 会发生什么？

• 要点：Broker 视为未决，继续按递增间隔重试，直到达到最大次数。
• 追问落点：Unknown 与 Rollback 的区别。

1. 生产者崩溃后事务状态表怎么保证可靠？

• 要点：状态表必须与本地业务在同一事务内写入，否则回查无依据。
• 追问落点：状态表与业务表分库怎么办。

1. 多次回查失败后如何避免数据丢失？

• 要点：转入死信队列 + 日终对账 + 人工补偿。
• 追问落点：对账发现不一致的修复流程。

面试者参考回答（400–700 字）

【结论】 面试官您好，回查是 RocketMQ 事务消息对"生产者失联"的兜底机制，让半消息在没人给出结论时也能收敛，不会永久悬挂。

【三点】 第一，先说正常流程。生产者先发送半消息，Broker 落库但不投递给消费者；然后生产者执行本地事务，成功就 Commit，半消息转为可见；失败就 Rollback，Broker 删除半消息。第二，回查解决的是异常路径。如果生产者崩溃、超时或网络抖动，Broker 收不到 Commit 或 Rollback，就会主动调用生产者的回查回调，询问本地事务的真实状态。回查间隔是递增的，默认 60 秒起步，最大回查次数默认 15 次，避免高频回查把正在恢复的生产者打垮。第三，最终状态这样确定。回查回调返回 Commit 就投递消息，返回 Rollback 就删除半消息，返回 Unknown 就继续重试；达到最大回查次数仍无结论，Broker 按失败处理，删除半消息并转入死信队列，由人工介入。这里的关键是回查只能判断本地事务状态，所以业务方必须把事务状态表和业务表放在同一个本地事务里写入，否则回查没有可靠依据。

【边界】 当然，回查只解决生产者失联的问题，不解决消费者处理失败。消费端还是要靠幂等、重试和死信队列兜底，核心业务再叠加日终对账，才能保证最终一致。

面试记录 2026-10-23（第 1 次）

题目：RocketMQ 事务消息为什么要设计回查？回查超时或多次失败后，消息的最终状态如何确定？

难度：medium

标签：arch/distributed/transaction, distributed/mq, distributed/rocketmq

评分：⭐⭐⭐☆☆（3/5）

练习次数：1

我的回答

rocketmq事务消息的回查实际上是给事务消息流程中细节的补偿;

事务消息的过程是,生产者创建事务消息发送半消息给到broker,broker落库,然后等待生产者发送后续的执行结果,是本地执行成功的commit,让消费者看到半消息进行消费,还是本地执行失败,把半消息移除,结束事务消息;

这里需要broker从生产者获取实际执行情况,如果生产者一直不发送,broker没什么处理方法,这里就有了回查去处理这个问题,broker主动找生产者询问当前情况,并且周期递增性的去进行轮询,如果多次都无法获取结果,那么认定生产者出现问题,对应的也就认定事务消息失败了

点评

评分：⭐⭐⭐☆☆（3/5）

优点：

• 正确描述半消息流程：发送半消息 → Broker 落库 → 等待 Commit/Rollback
• 正确点出回查的动机：生产者不发送结论时 Broker 无法自行推进
• 正确提到回查是递增间隔轮询，多次失败后认定事务失败

不足：

• 未提回查的判定依据：生产者实现的状态查询回调，依赖本地事务状态表
• 未提默认参数：最大回查次数 15 次、间隔 60 秒递增
• 未提最终状态的具体去向：删除半消息 + 死信队列 + 人工介入

补充：

• 回查只能判断本地事务状态，不能判断下游消费是否成功
• 状态表必须与业务表同库同事务写入，否则回查无可靠依据

完整讲解见上方「完整讲解（权威版）」