引言
事务的概念就不用多说了，我相信阅读文章的童鞋都是有着非常深刻的认识。我们都知道MQ可以实现微服务之间的异步以及解耦，那么引入MQ之后，如何实现微服务之间的数据一致性是一个值得思考的问题。事务消息将分为三篇文章进行介绍，本文主要介绍RocketMQ的事务原理，第二篇文章主要分析事务消息源码实现分析。在第三篇文章中将提供一种优化方案，解决RocketMQ对于业务代码侵入较大的问题。
- RocketMQ事务原理
- 总结
一、RocketMQ事务原理
1、消息发送问题分析
为了方便大家理解，我们以日常生活中的订单服务来进行原理的说明。当我们支付订单之后，我们账户的购物积分也会进行相应的积分调整。我们结合下面的订单服务、RocketMQ、积分服务的简化交互图来看下，如果没有事务消息，这样的服务间交互有没有问题。
可能有的童鞋会说，这不是很简单嘛，肯定是订单服务先执行本地事务，更新订单信息。然后再发消息到MQ中，积分服务消费消息更新积分啊。但是事实上并没有这么简单。
如果我们订单服务直接更新的了订单信息并进行持久化，而后在发送订单信息到MQ中。如果此时MQ服务不可用，消息发送报错，无法将订单消息发到MQ中，也就意味着积分服务不能收到订单信息，也就不会进行相应的积分操作。此时就会出现订单信息与积分信息数据不一致的问题。那么RocketMQ是怎么解决这个问题的呢？
2、半消息
实际上RocketMQ提供了一种half消息的机制，订单服务发送half消息到MQ中，这个half消息是不被消费者所见的。怎么理解这个half信息呢，按照我自己的理解，就是它实现了一半的消息功能，只在生产端可见，在消费端不可见。那么这个half消息是怎么实现在MQ中不被积分服务所见的呢？
订单服务发送half消息，并不是将消息投递到积分服务订阅的topic，而是将消息投递到RocketMQ中的RMQ_SYS_TRANS_HALF_TOPIC对应的messeageQueue。由于积分服务并没有订阅这个Topic，所以这个消息对于积分服务是不可见的。
另外有个OP_TOPIC用于记录对应half消息的commit/rollback状态。大致的交互如下如所示：
3、事务消息流程
交代完一些背景知识之后，我们来具体分析下事务消息的流程。订单服务先发送half消息到MQ中，相当于检查下此时RocketMQ是否可用。如果此时half消息可以正常发送到MQ中，订单服务可以收到响应。此时订单服务可以进行本地事务处理，更新订单信息。同时订单服务提供事务执行结果的接口用于RocketMQ进行回调。
如果订单服务half消息发送失败了，由于网络原因或者MQ挂了，那么此时需要执行一些回滚操作，让订单进行关闭。因为订单信息无法通知到下游服务了。
那么如果half消息已经写入MQ中，但是本地事务执行失败又该怎么办呢？也就是说当订单服务接收到half消息写入成功的响应后，更新订单信息时发生了异常，无法完成状态更新。那么此时订单服务需要发送rollback的请求给RocketMQ，通知其间原来的half信息进行删除。如果本地事务执行成功，则需要发送commit请求给RocketMQ，RocketMQ会将原先存在RMQ_SYS_TRANS_HALF_TOPIC中的消息重新投递到积分服务订阅的TOPIC中去，这样积分服务就可以正常消费信息进行下一步的积分操作了。
再考虑一种情况，如果订单服务发送commit或者rollback请求未正常投递到RocketMQ中，RocketMQ不知道half消息到底是对应的本地事务到底是执行成功了还是执行失败了。针对这种情况，订单服务需要提供状态回查接口，RocketMQ定时检测是否还有没有处理的half消息，当存在这样的消息时，RocketMQ调用会查接口确认本地事务执行情况。执行失败的则删除half消息，执行成功则重新投递消息。
二、总结
最后用一张完整的交互图来总结下事务消息的整体流程，如下所示：
