RocketMQ分布式事务

转自https://mp.weixin.qq.com/s/Kxk2Ag-7dbpBZEs1xBJYeQ

RocketMQ事务消息设计则主要是为了解决Producer端的消息发送与本地事务执行的原子性问题，RocketMQ的设计中broker与producer端的双向通信能力，使得broker天生可以作为一个事务协调者存在；而RocketMQ本身提供的存储机制，则为事务消息提供了持久化能力；RocketMQ的高可用机制以及可靠消息设计，则为事务消息在系统在发生异常时，依然能够保证事务的最终一致性达成。

 

1 RocketMQ 事务消息设计

事务消息作为一种异步确保型事务， 将两个事务分支通过MQ进行异步解耦，RocketMQ事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：

1. 事务发起方首先发送prepare消息到MQ。

2. 在发送prepare消息成功后执行本地事务。

3. 根据本地事务执行结果返回commit或者是rollback。

4. 如果消息是rollback，MQ将删除该prepare消息不进行下发，如果是commit消息，MQ将会把这个消息发送给consumer端。

5. 如果执行本地事务过程中，执行端挂掉，或者超时，MQ将会不停的询问其同组的其它producer来获取状态。

6. Consumer端的消费成功机制有MQ保证。

    

2 RocketMQ事务消息实现

RocketMQ事务消息在实现上充分利用了RocketMQ本身机制，在实现零依赖的基础上，同样实现了高性能、可扩展、全异步等一系列特性。

 

在具体实现上，RocketMQ通过使用Half Topic 以及Operation Topic 两个内部队列来存储事务消息推进状态，如下图所示：

 

其中，Half Topic对应队列中存放着prepare消息，Operation Topic对应的队列则存放了prepare message对应的commit/rollback消息，消息体中则是prepare message对应的offset，服务端通过比对两个队列的差值来找到尚未提交的超时事务，进行回查。

 

在具体实现上，事务消息作为普通消息的一个应用场景，在实现过程中进行了分层抽象，从而避免了对RocketMQ原有存储机制的修改，如下图所示：

 

从用户侧来说，用户需要分别实现本地事务执行以及本地事务回查方法，因此只需关注本地事务的执行状态即可；而在service层，则对事务消息的两阶段提交进行了抽象，同时针对超时事务实现了回查逻辑，通过不断扫描当前事务推进状态，来不断反向请求Producer端获取超时事务的执行状态，在避免事务挂起的同时，也避免了Producer端的单点故障。而在存储层，RocketMQ通过Bridge封装了与底层队列存储的相关操作，用以操作两个对应的内部队列，用户也可以依赖其它他存储介质实现自己的service，RocketMQ会通过ServiceProvider加载进来。

 

从上述事务消息设计中可以看到，RocketMQ事务消息较好的解决了事务的最终一致性问题，事务发起方仅需要关注本地事务执行以及实现回查接口给出事务状态判定等实现，而且在上游事务峰值高时，可以通过消息队列，避免对下游服务产生过大压力。

 

事务消息不仅适用于上游事务对下游事务无依赖的场景，还可以与一些传统分布式事务架构相结合，而MQ的服务端作为天生的具有高可用能力的协调者，使得我们未来可以基于RocketMQ提供一站式轻量级分布式事务解决方案，用以满足各种场景下的分布式事务需求。