rocketmq新扩容的broker没有tps_RocketMQ的事务消息机制

RocketMQ事务消息接口介绍

当我们在业务逻辑中发送消息时，消息与业务的事务之间难以保证一致性，如果业务代码出现异常，如果已发送的消息无法回滚，则很会出现数据不一致的情况，RocketMQ的事务消息支持在业务逻辑与发送消息之间提供事务保证，RocketMQ通过两阶段的方式提供事务消息的支持。

RocketMQ实现事务消息依赖于TransactionListener接口，此接口的定义如下：

其中包含两个方法：

• executeLocalTransaction方法会在发送消息后调用，用于执行本地事务，如果本地事务执行成功，rocketmq再提交消息
• checkLocalTransaction用于对本地事务做检查，rocketmq依赖此方法做补觉，后文再细说

以官方的示例为例子，我们看看如何使用RocketMQ的事务消息，首先实现一个TransactionListener:

然后我们再通过实现的TransactionListenerImpl类创建TransactionMQProducer，所有事务消息都需要通过TransactionMQProducer发送：

最后发送消息：

消息的消费和普通消息一样，这里不多说了。下面我们再看细说一下RocketMQ的事务消息的实现机制

事务消息的执行机制

如上图所示，RocketMQ通过两个内部的topic来实现对消息的两阶段支持，RocketMQ在实现事务消息时，实际上是通过将生产投递过来的消息（消息上带有事务标识）投递到一个名为RMS_SYS_TRANS_HALF_TOPIC的topic中，而不是投递到真正的topic中，这个过程是第一阶段(prepare)，然后producer再通过TransactionListener的executeLocalTransaction方法执行本地事务，当producer的localTransaction处理成功或者失败后，producer会向broker发送commit或rollback命令，如果是commit，则broker会将投递到RMQ_SYS_TRANS_HALF_TOPIC中的消息投递到真实的topic中，然后再投递一个表示删除的消息到RMQ_SYS_TRANS_OP_HALF_TOPIC中，表示当前事务已完成；如果是rollback，则没有投递到真实topic的过程，只需要投递表示删除的消息到RMQ_SYS_TRANS_OP_HALF_TOPIC。最后，消费者和消费普通的消息一样消费事务消息。

整个过程如果没有遇到问题，则一切OK，但整个过程中可能会遇到以下错误：

• 第一阶段（prepare）失败：给应用返回发送消息失败
• 事务失败：发送回滚命令给broker，由broker执行消息的回滚
• Commit或rollback失败：由broker定时向producer发起事务检查，如果本地事务成功，则提交消息事务，否则回滚消息事务

事务状态的检查有两种情况：

• commit/rollback：broker会执行相应的commit/rollback操作
• 如果是TRANSACTION_NOT_TYPE，则一段时间后会再次检查，当检查的次数超过上限（默认15次）则丢弃消息

异常情况示意图如下：

源码阅读

最后我们看看几处关键代码，首先是producer的发送消息部分，在DefaultMQMessageImpl类的sendMessageInTransaction方法中使用了丙阶段的方式处理事务：

发送prepare消息成功后表示第一阶段成功，然后再调用transactionListener.executeLocalTransaction执行本地事务，随便根据本地事务的执行结果调用endTransaction方法做第二阶段的处理：

接下来看看broker是如何处理两阶段的，首先我们看看prepare的处理，在SendMessageProcessor类的sendMessage方法中，我们可以看到获取事务标识并决定处理逻辑的代码：

如果事务标识为true，则调用TransactionalMessageService的prepareMessage方法，我们可以进入到此方法中，一直到TransactionalMessageBridge的parseHalfMessage方法，并最终找到消息的处理方式：

parseHalfMessage方法先将消息真实的topic和queueId加到到property里，然后将消息的topic设置成TransactionalMessageUtil.buildHalfTopic()调用的返回值，返回的topic正是RMQ_SYS_TRANS_HALF_TOPIC，这里对topic作了一个转换，因此在一阶段完成后，消费者还无法消费到事务消息

我们再来看看二阶段的处理方式，进入到EndTransactionProcessor类的processRequest方法中，可以看到如下代码：

其中两个核心代码的调用，一个是commit时调用的sendFinalMessage方法用于将消息投递到真实的topic中，另一个是TransactionalMessageService的deletePrepareMessage方法用于投递一个用于标识当前事务的一阶段消息为删除的消息，在看sendFinalMessage方法的实现前，我们先看一下在此方法调用前调用的endTransactionMessage方法的实现：

可以看到关键代码，将消息的topic和queueId设置回真实的topic和queueId，然后在sendFinalMessage中存储消息：

我们再来看看TransactionalMessageService的deletePrepareMessage方法的实现，很明显，是新写入了一个消息：

这里可以看到，新写入的消息的tag是REMOVETAG，我们进入到putOpMessage方法，在addRemoveTagInTransactionOp方法的调用中可以看到使用的topic是TransactionalMessageUtil.buildOpTopic()的返回值 ，即RMQ_SYS_TRANS_OP_HALF_TOPIC

最后，我们再来看看本地事务的check相关的代码，我们进入到TransactionalMessageCheckService类中，此类包含一个线程，此线程默认每分钟触发一次事务检查，在其onWaitEnd方法中，可以看到实际上还是调用了TransactionalMessageService的check方法：

这里默认的timeout是6秒和checkMax是15，表示的意思是6秒以上没commit/rollback的消息才做事务检查，检查次数越过15次则丢弃事务，我们可以进入到TransactionalMessageService的check方法中，其中有一大段的逻辑用于判断一个消息是否应该做事务检查，这里不解释了，我们直接看触发事务检查的代码：

很明显，listener.resolveHalfMsg方法用于触发事务的检查，其实现如下：

可以看到，它使用了broker到client的调用，触发producer的事务检查，至于事务检查如何处理，我们可以回到producer的DefaultMQProducerImpl类中，其中的checkTransactionState方法调用了TransactionListener的checkLocalTransaction方法用于处理事务的检查：

最后事务检查的结果会由processTransactionState方法做处理：这里和前文讲过的事务消息的第二阶段处理的代码一样，将事务结果发送到broker，并由broker的EndTransactionProcessor的processRequest做事务二阶段的处理

最后说一句，虽然RocketMQ的代码写的不优雅，而且for/if-else等嵌套非常深，但是理解了它的运行机制后还是能有所收获的。