28 RocketMQ：事务消息机制的底层实现原理

Posted 2021-08-16 鮀城小帅

1.half 消息在commit前对消费者不可见的原因

回顾：当订单系统去发送一个half消息给MQ的时候。对于这个half消息，红包系统在这时是看不到它的，也无法去消费这条消息并进行处理。

ConsumeQueue的可见原理

场景解析：当写入一条half消息到OrderPaySuccessTopic这个Topic里去，会定位到这个Topic的一个MessageQueue，然后定位到上图RocketMQ的一台机器上去，接着，消息就会写入到CommitLog中。

与此同时，消息的offset会写入MessageQueue对应的ConsumeQueue，这个ConsumeQueue是属于OrderPaySuccessTopic的，但此时红包系统并不会马上从ConsumeQueue里获取到订单系统（生产者）写入的这个half消息。

实际上红包系统此时根本就看不到这条消息。原因是，RocketMQ一旦发现生产者发送的是一条half消息，就不会把这个half消息的offset写入OrderPaySuccessTopic的ConsumeQueue里去。

而是将这条half消息写入到自己内部的 “ RMQ_SYS_TRANS_HALF_TOPIC ” 这个Topic对应的一个ConsumeQueue里去。

所以，此时红包系统也就无法从OrderPaySuccessTopic的ConsumeQueue中看到这条half消息了。

2.什么情况下订单系统会收到half消息成功的响应

因为half消息是进入到RocketMQ内部的RMQ_SYS_TRANS_HALF_TOPIC的ConsumeQueue文件。所以，当MQ认为half消息写入成功了，就会返回响应给订单系统（生产者）。

3.订单系统（生产者）没有执行rollback或者commit会怎么样？

场景：在订单系统没有收到half消息的响应，或者是订单系统发送的rollback/commit请求失败了。

此时，MQ后台会有定时任务，该定时任务会去扫描RMQ_SYS_TRANS_HALF_TOPIC中的half消息，如果超过一定时间还是half消息（状态），MQ就会回调订单系统的接口，让订单系统（生产者）判断这个half消息是要rollback还是commit？

4.执行rollback操作，实现标记消息回滚的底层原理

OP操作

当订单系统执行了rollback请求后，就需要对消息进行回滚了。回滚的实现不是直接将MQ中的half消息给删除掉。

在MQ中，因为RocketMQ都是顺序把消息写入磁盘文件，基于这一点，当执行rollback时，MQ会用一个OP操作来标记half消息的状态。

所谓OP操作，在RocketMQ内部有一个OP_TOPIC，此时可以写一条rollback OP记录到这个Topic里，标记某个half消息是rollback了。

MQ自动rollback的条件

在订单系统（生产者）一直没有commit/rollback的情况下，RocketMQ会回调订单系统的接口去判断 half 消息的状态，但是最多只能回调 15 次。如果15 次之后订单系统都没法告知它 half 消息的状态，就会自动把消息标记为 rollback 。

5.当执行commit操作后，让消息对红包系统可见的原理

当订单系统（生产者）执行commit操作之后，RocketMQ就会在OP_TOPIC里写入一条记录，标记half消息已经是commit状态了。

接着就会把放在 RMQ_SYS_TRANS_HALF_TOPIC中的 half 消息给写入到 OrderPaySuccessTopic 的ConsumeQueue 里去，然后消费端的红包系统就可以看到这条消息进行消费了。

总结：在使用事务消息的前提下，生产者往broker发的每一条消息，都会先待在系统内部topic对应的ConsumeQueue中，等待验证完毕后，由生产者提交commit后才会回到相应topic对应的ConsumeQueue中。