说到分布式事务，就会谈到那个经典的”账号转账”问题：2个账号，分布处于2个不同的DB，或者说2个不同的子系统里面，A要扣钱，B要加钱，如何保证原子性？
一般的思路都是通过消息中间件来实现“最终一致性”：A系统扣钱，然后发条消息给中间件，B系统接收此消息，进行加钱。
为了能解决该问题，同时又不和业务耦合，RocketMQ提出了“事务消息”的概念。
具体来说，就是把消息的发送分成了2个阶段：Prepare阶段和确认阶段。
具体来说，上面的2个步骤，被分解成3个步骤：
(1) 发送Prepared消息
(2) update DB
(3) 根据update DB结果成功或失败，Confirm或者取消Prepared消息。
可能有人会问了，前2步执行成功了，最后1步失败了怎么办？这里就涉及到了RocketMQ的关键点：RocketMQ会定期（默认是1分钟）扫描所有的Prepared消息，询问发送方，到底是要确认这条消息发出去？还是取消此条消息？
由于rocketmq是不保证excetly once，所以接收方是有可能收到多次消息的。这样可以在接受方加一张表 用来判重。这样可以防止重复执行。当然是如果业务可以幂等就不需要这个步骤。