RocketMQ 事务消息在实现上充分利用了 RocketMQ 本身机制，在实现零依赖的基础上，同样实现了高性能、可扩展、全异步等一系列特性。
在具体实现上，RocketMQ 通过使用 Half Topic 以及 Operation Topic 两个 内部队列 来存储事务消息推进状态，如下图所示：
Half Topic对应队列中存放着 prepare 消息，Operation Topic对应的队列则存放了 prepare message 对应的 commit/rollback 消息，- 消息体 则是 prepare 消息 对应的 offset，
- 服务端 通过比对两个队列的差值来找到尚未提交的超时事务，进行回查。
在具体实现上，事务消息作为普通消息的一个应用场景，在实现过程中进行了 分层抽象，从而避免了对 RocketMQ 原有存储机制的修改，如下图所示：
-
从用户侧来说，用户需要分别 实现本地事务执行 和 本地事务回查方法 ，因此只需关注本地事务的执行状态即可；
-
而在 service 层，则对事务消息的 两阶段提交 进行了抽象，同时针对超时事务实现了回查逻辑 ，通过不断扫描当前事务推进状态，来不断反向请求 Producer 端获取超时事务的执行状态，在避免事务挂起的同时，也避免了 Producer 端的单点故障。
-
而在存储层，RocketMQ 通过 Bridge 封装了与底层队列存储的相关操作，用以操作两个对应的内部队列，用户也可以依赖其他存储介质实现自己的 service，RocketMQ 会通过 ServiceProvider 加载进来。
从上述事务消息设计中可以看到，RocketMQ 事务消息较好的解决了事务的最终一致性问题，事务发起方仅需要关注 本地事务执行 和 实现回查接口 给出事务状态判定等实现，而且在上游事务峰值高时，可以通过消息队列，避免对下游服务产生过大压力。
事务消息不仅适用于上游事务对下游事务无依赖的场景，还可以与一些传统分布式事务架构相结合，而 MQ 的服务端作为天生的具有高可用能力的协调者，使得我们未来可以基于 RocketMQ 提供一站式轻量级分布式事务解决方案，用以满足各种场景下的分布式事务需求。
事务消息作为一种异步确保型事务， 将两个事务分支通过 MQ 进行异步解耦，RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：
-
事务发起方（消息生产者 producer）首先发送 prepare 消息 到 MQ （具体就是发送到 Half Message Queue）。
-
事务发起方（消息生产者 producer）在发送 prepare 消息成功后 （即收到Half Message Queue发送成功的回执消息） ，执行本地事务（自己写的，本地系统业务逻辑代码）。
-
根据本地事务执行结果，返回给MQ发送方发送：commit 或者 rollback。
- 如果发送的是 rollback 消息，MQ 将删除该 prepare 消息，不进行下发 ；
- 如果发送的是 commit 消息，MQ 将会把这个消息发送给 consumer 端；
-
如果执行本地事务过程中，执行端挂掉，或者超时，RocketMQ 将会不停的询问其同组的其他 producer 来获取状态。所以消息发送者需要实现一个 check 接口，RocketMQ 会根据消息发送者设置的策略来决定是 rollback 还是继续 commit。这样就保证了消息发送与本地事务同时成功或同时失败。
-
Consumer 端的消费成功机制有 MQ 保证。