1.RocketMq支持事务操作，其他mq和kafka不支持事务操作。
运行流程：第一阶段 Prepared 消息，会拿到消息的地址。 第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。
原理以及例子：
1、A系统向消息中间件发送一条预备消息
2、消息中间件保存预备消息并返回成功
3 、 A 执行本地事务
4 、 A 发送提交消息给消息中间件
对于以上的 4 个步骤，每个步骤都可能产生错误，下面一一分析：
步骤一出错，则整个事务失败，不会执行 A 的本地操作 步骤二出错，则整个事务失败，不会执行 A 的本地操作
步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是 A 系统实现一个消息中间件的回调接口，消 息中间件会去不断执行回调接口，检查A 事务执行是否执行成功，如果失败则回滚预备消息
步骤四出错，这时候 A 的本地事务是成功的，那么消息中间件要回滚 A 吗？答案是不需要，其实通过回调 接口，消息中间件能够检查到A 执行成功了，这时候其实不需要 A 发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务。
基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（ A 系统的 本地操作+ 发消息） +B 系统的本地操作，其中 B 系统的操作由消息驱动，只要消息事务成功，那么 A 操作 一定成功，消息也一定发出来了，这时候B 会收到消息去执行本地操作，如果本地操作失败，消息会重 投，直到B 操作成功，这样就变相地实现了 A 与 B 的分布式事务。
优点： 实现了最终一致性，不需要依赖本地数据库事务。
缺点： 实现难度大，主流 MQ 不支持，没有 .NET 客户端， RocketMQ 事务消息部分代码也未开源。
