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等嵌套非常深，但是理解了它的运行机制后还是能有所收获的。
