RocketMQ 半事务消息核心流程

消息发送：生产者将消息发送至 Broker。
半事务消息标记：Broker 完成消息持久化后，向生产者返回 Ack 确认（表示消息发送成功），此时消息被标记为「暂不能投递」状态，即半事务消息。
本地事务执行：生产者收到 Ack 后，执行本地业务事务逻辑。
二次确认与消息处理：生产者根据本地事务执行结果，向 Broker 提交二次确认（Commit 或 Rollback），Broker 按以下规则处理：
- 若二次确认为「Commit」：Broker 将半事务消息标记为「可投递」，并推送给消费者；
- 若二次确认为「Rollback」：Broker 回滚事务，半事务消息不会投递给消费者。
异常场景：消息回查机制：
- 触发条件：断网、生产者应用重启等导致 Broker 未收到二次确认，或收到的确认结果为「Unknown」未知状态；
- 回查触发：Broker 经过固定时间后，向生产者集群中任一实例发起消息回查；
- 结果校验：生产者收到回查请求后，校验对应消息的本地事务最终执行结果；
- 再次确认：生产者根据校验结果重新提交二次确认，Broker 按照步骤 4 的规则处理半事务消息。

支付场景

flowchart TD
    A[本地事务]
    B[消息生产者]
    C[服务端]
    D[消费者]

    B -->|1.发送半事务消息| C
    C -->|2.半事务消息发送成功| B
    B -->|3.执行本地事务| A
    A -->|4. Commit or Rollback| B
    B -->|4. Commit or Rollback| C
    C -->|5. 未收到4的确认时，回查事务状态| B
    B -->|6. 检查本地事务的状态| A
    C -->|7. 根据事务的状态Commit/Rollback| B
    C -->|Commit 投递消息| D
    D -->|Rollback 不投递消息| C

    style A fill:#a9d18e,stroke:#333,stroke-width:2px
    style B fill:#fff2cc,stroke:#333,stroke-width:2px
    style C fill:#c9daf8,stroke:#333,stroke-width:2px
    style D fill:#d9d2e9,stroke:#333,stroke-width:2px

事务回查生命周期

初始化：半事务消息被生产者构建并完成初始化，待发送到服务端的状态。
事务待提交：半事务消息被发送到服务端，和普通消息不同，并不会直接被服务端持久化，而是会被单独存储到事务存储系统中，等待第二阶段本地事务返回执行结果后再提交。此时消息对下游消费者不可见。
消息回滚：第二阶段如果事务执行结果明确为回滚，服务端会将半事务消息回滚，该事务消息流程终止。
提交待消费：第二阶段如果事务执行结果明确为提交，服务端会将半事务消息重新存储到普通存储系统中，此时消息对下游消费者可见，等待被消费者获取并消费。
消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。具体信息，请参见消费重试。
消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。更多信息，请参见消息存储和清理机制。