RocketMQ事务消息机制原理

RocketMQ工作流程

在RocketMQ当中，当消息的生产者将消息生产完成之后，并不会直接将生产好的消息直接投递给消费者，而是先将消息投递个中间的服务，通过这个服务来协调RocketMQ中生产者与消费者之间的消费速度。

那么生产者是如何投递自己的消息呢？这里向大家介绍一下RocketMQ当中的一个重要组件，topic。Topic，故名思意，主题嘛，消息生产者在生产投递消息的过程中，可以通过设定不同的topic将自身所生产的消息，投递到对应的topic当中。举一个通俗易懂的例子，我们可以把topic想象成是一个货物仓库，而topic是一个货架，对应的种类的物品要放到对应的货架上。

消费者则根据自身的需求，通过不同的topic来获取自己想要消费的消息。

RocketMQ事务消息的实现

RocketMQ事务消息的实现，其实也是非常的简单，我们只需要弄清一个原理即可，即分阶段实现。在RocketMQ当中，想要实现分阶段实现这一功能，首先要实现一个机制，就是TransactionListener--事务监听机制。事务监听机制有两个重要的方法，即executeLocalTransaction(执行本地事务)，checkLocalTransaction(回查本地事务)。

RocketMQ事务消息的流转过程其实也是十分简单。首先，消息事务生产端会生生一个half消息即半消息，和正常一样，生产者也是要将这个消息投递到Broker当中，但这个Broker当中用来接收这个半消息的topic和普通的topic并不一样，我们将这种用来接收生产者生产的half消息投递的topic称为half topic。特别注意,half topic对消费者来说是不可见的，即消费者无法直接从half topic当中获取信息进行消费。

那么如何将half topic当中的消息转移到正常的topic当中，让消费者能够消费呢？

首先，当Broker当中的半topic接收到这个半消息后，Broker便会返回一个ack给生产者，生产者接收到这个ack后，便会开始执行本地事务。执行本地事务后，会产生两种结果，一种执行成功一种执行失败。

事务执行成功

当本地事务执行成功之后，生产者便会将本地事务执行成功的状态提交个Broker，当Broker接收到这个信息时，便会将半topic当中的半消息给拿出来，放到目标topic当中，供消费者能够进行正常消费。

事务执行失败

若当本地事务执行的过程中产生异常或者没有执行成功，生产者则会将事务进行回滚并会给Broker返回一个Rollback状态，当Broker接收到Rollback这个状态时，便会将半topic中的消息进行逻辑删除，并且RocketMQ还会通过异步的方式单开一个线程，用来接收这种被Broker逻辑删除的消息，并将这些消息进行清除。

事务执行成功但无状态

若本地事务执行成功，但由于网络波动，本地事务的执行状态未及时反馈给生产者或生产者迟迟未接收到本地事物的状态，即处于无状态或中间态的情况下，Broker便会启动一个定时回查任务。Broker会调用事务监听器当中的checkTransaction接口，来查看当前事务的状态，根据回查的状态结果，来进行相应的操作。这个事务回查机制，有次数限制，默认回查十五次，超过十五次后，便不会再来回查本地事务的状态了。

总结

以上便是RocketMQ中事务消息的整个流程，笔者也将流程图置于下方，希望能够给各位小伙伴带来帮助。笔者小，中，大厂均有面试经验，目前正在从事全栈开发工作，主要分享java全栈开发知识与相关的面试真题，希望能够给大家带来帮助，同大家共同进步。