用户U1从A银行系统转账给B银行系统的用户U2的处理过程如下：
第一步：A银行系统生成一条转账消息，以事务消息的方式写入RocketMQ，此时B银行系统不可见这条消息(Prepare阶段)
第二步：写入MQ成功后，回调A银行系统，对T1，T2表进行操作（很显然需要是一个事务）
我们重点关注下T2表，这个表是用来干嘛的呢？每条转账消息都会在T2表中，该表有2个特殊的字段：status，updatetime。
第三步：完成第二步，接下来发送确认消息给MQ，如果这个确认消息发送成功，那么这条转账消息，将对B银行系统可见。然后B银行系统，会在一个事务中完成对t3，t5的操作。
如果发送确认消息给MQ失败的处理思路：
首先，B银行系统，有一个定时任务（比如说每隔1MIN执行一次），扫描表t5，取得一段时间内的数据，发送给A银行系统。要知道t5中的数据，必然是A银行系统成功处理并发送确认消息成功的转账数据。为什么要发送给A银行系统呢，其实就是为了找到那些发送确认消息失败的转账数据。那么怎么发给A银行系统呢，这个方式比较多，可以考虑在来一个Topic，也可以考虑Netty等。发送给A银行系统，其实就是为了更新t2表的status，updatetime。
这里有一个关键，如何“扫描表t5，取得一段时间内的数据”？这就是t4的作用，在t4中记录一个time字段，每次定时任务启动，先更新time（比如设定为当前系统时间，设置前的的时间为old），然后扫描出t5中大于这个old时间的转账数据，如此循环往复。
其次，A银行系统，也有一个定时任务（可以根据业务消费能力定，可以大一些），扫描t2表（指定status及updatetime条件），将那些确认消息发送失败的转账消息找出来，更新updatetime并发送给MQ。
这样，我们并没有改动RocketMQ 3.2.6的源码，而是在外围解决了事务回查！
其实到这里，你可以发现RocketMQ的一个特点，就是将生产者和MQ绑定，而不需要特别处理消费者，这是为什么呢？因为消息只要发往RocketMQ成功，那么就意味着成功，为什么这么说？
前面，我们说过，消费者端消费消息只会产生2种错误，第一：timeout，第二：exception。要知道RocketMQ对于超时，会不断重试；对于消费异常，会根据消费端的返回码，会有重试机制保证。也就是，RocketMQ一定会让消息得到消费，如果消费有问题，只能是消费者的问题，而不会是RocketMQ的问题！
人工介入
可能有人又要说了，无论什么方案，发送端把消息成功放入了队列，但消费端消费失败怎么办？
消费失败了，重试，还一直失败怎么办？是不是要自动回滚整个流程？
答案是人工介入。从工程实践角度讲，这种整个流程自动回滚的代价是非常巨大的，不但实现复杂，还会引入新的问题。比如自动回滚失败，又怎么处理？
对应这种极低概率的case，采取人工处理，会比实现一个高复杂的自动化回滚系统，更加可靠，也更加简单。