RocketMQ干货集|彻底看懂RocketMQ事务实现原理（下）

2.2 Broker端如何处理事务消息？

SendMessageProcessor#asyncSendMessage

跟进去看看真正处理半消息的业务逻辑，这段处理逻辑在类

TransactionalMessageBridge

• putHalfMessage

• 

• parseHalfMessageInner

• 

• RocketMQ并非将事务消息保存至消息中 client 指定的 queue，而是记录了原始的 topic 和 queue 后，把这个事务消息保存在

设计思想

特殊的内部 topic：RMQ_SYS_TRANS_HALF_TOPIC

序号为 0 的 queue

这套 topic 和 queue 对消费者不可见，因此里面的消息也永远不会被消费。这就保证在事务提交成功之前，这个事务消息对 Consumer 是消费不到的。

2.3 Broker端如何事务反查?

在Broker的TransactionalMessageCheckService服务中启动了一个定时器，定时从事务消息queue中读出所有待反查的事务消息。

AbstractTransactionalMessageCheckListener#resolveHalfMsg

针对每个需要反查的半消息，Broker会给对应的Producer发一个要求执行事务状态反查的RPC请求

AbstractTransactionalMessageCheckListener#sendCheckMessage

Broker2Client#checkProducerTransactionState

根据RPC返回响应中的反查结果，来决定这个半消息是需要提交还是回滚，或者后续继续来反查。

最后，提交或者回滚事务。首先把半消息标记为已处理

如果是提交事务，就把半消息从半消息队列中复制到该消息真正的topic和queue中

如果是回滚事务，什么都不做

EndTransactionProcessor#processRequest

最后结束该事务。

3 总结

• 整体实现流程

• 

• RocketMQ是基于两阶段提交来实现的事务，把这些事务消息暂存在一个特殊的queue中，待事务提交后再移动到业务队列中。最后，RocketMQ的事务适用于解决本地事务和发消息的数据一致性问题。

参考

https://juejin.im/post/6844904193526857742