这张图说明了事务消息的大致方案，分为两个逻辑：正常事务消息的发送及提交、事务消息的补偿流程
事务消息发送及提交：
发送消息（half消息）
服务端响应消息写入结果
根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）
补偿流程：
对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
Producer收到回查消息，检查回查消息对应的本地事务的状态
根据本地事务状态，重新Commit或者Rollback
补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。
以上RocketMQ事务消息的整体方案，对于了解Notify的同学应该是很熟悉的，下面是之前Notify相关的资料：
整体方案是完全相同的，只是两者的Storage不同。
RocketMQ事务消息设计
一阶段的消息如何对用户不可见
事务消息相对普通消息最大的特点就是一阶段发送的消息对用户是不可见的。
如何做到写入了消息但是对用户不可见?——写入消息数据，但是不创建对应的消息的索引信息。
熟悉RocketMQ的同学应该都清楚，消息在服务端的存储结构如上，每条消息都会有对应的索引信息，Consumer通过索引读取消息。
那么实现一阶段写入的消息不被用户消费（需要在Commit后才能消费），只需要写入Storage Queue，但是不构建Index Queue即可。
RocketMQ中具体实现策略是：写入的如果事务消息，对消息的Topic和Queue等属性进行替换，同时将原来的Topic和Queue信息存储到消息的属性中。