揭开 RocketMQ 事务消息的神秘面纱

事务消息是 RocketMQ 的高级特性之一，相信很多同学都对于其实现机制很好奇。

这篇文章，笔者会从应用场景、功能原理、实战例子、实现细节四个模块慢慢为你揭开事务消息的神秘面纱。

1 应用场景

以电商交易场景为例，用户支付订单这一核心操作的同时会涉及到下游物流发货、积分变更、购物车状态清空等多个子系统的变更。

当前业务的处理分支包括：

• 主分支订单系统状态更新：由未支付变更为支付成功。
• 物流系统状态新增：新增待发货物流记录，创建订单物流记录。
• 积分系统状态变更：变更用户积分，更新用户积分表。
• 购物车系统状态变更：清空购物车，更新用户购物车记录。

1、传统XA事务方案：性能不足

为了保证上述四个分支的执行结果一致性，典型方案是基于 XA 协议的分布式事务系统来实现。将四个调用分支封装成包含四个独立事务分支的大事务。基于 XA 分布式事务的方案可以满足业务处理结果的正确性，但最大的缺点是多分支环境下资源锁定范围大，并发度低，随着下游分支的增加，系统性能会越来越差。

2、基于普通消息方案：一致性保障困难

该方案中消息下游分支和订单系统变更的主分支很容易出现不一致的现象，例如：

• 消息发送成功，订单没有执行成功，需要回滚整个事务。
• 订单执行成功，消息没有发送成功，需要额外补偿才能发现不一致。
• 消息发送超时未知，此时无法判断需要回滚订单还是提交订单变更。

3、基于 RocketMQ 分布式事务消息：支持最终一致性

上述普通消息方案中，普通消息和订单事务无法保证一致的原因，本质上是由于普通消息无法像单机数据库事务一样，具备提交、回滚和统一协调的能力。

而基于 RocketMQ 实现的分布式事务消息功能，在普通消息基础上，支持二阶段的提交能力。将二阶段提交和本地事务绑定，实现全局提交结果的一致性。

2 功能原理

RocketMQ 事务消息是支持在分布式场景下保障消息生产和本地事务的最终一致性。交互流程如下图所示：