MQ事务方案（可靠消息事务）

基于 MQ 的分布式事务方案其实是对本地消息表的封装，"将本地消息表基于 MQ 内部"，其他方面的协议基本与本地消息表一致。
优点：相比本地消息表方案，MQ 事务方案优点是：
1、消息数据独立存储 ，降低业务系统与消息系统之间的耦合。
2、吞吐量大于使用本地消息表方案。
缺点
1、一次消息发送需要两次网络请求(half 消息 + commit/rollback 消息) 。
2、业务处理服务需要实现消息状态回查接口。
MQ事务方案整体流程和本地消息表的流程很相似，如下图：
可以看出和本地消息表方案唯一不同就是将本地消息表存在了MQ内部，而不是业务数据库中。

在本地消息表方案中，保证事务主动方发写业务表数据和写消息表数据的一致性是基于数据库事务
RocketMQ 的事务消息相对于普通 MQ提供了 2PC 的提交接口，方案如下：

这种情况下，事务主动方服务正常，没有发生故障，发消息流程如下：
步骤1：发送方向 MQ 服务端(MQ Server)发送 half 消息。
步骤2：MQ Server 将消息持久化成功之后，向发送方 ack 确认消息已经发送成功。
步骤3：发送方开始执行本地事务逻辑。
步骤4：发送方根据本地事务执行结果向 MQ Server 提交二次确认（commit 或是 rollback）。
步骤5：MQ Server 收到 commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；
      MQ Server 收到 rollback 状态则删除半消息，订阅方将不会接受该消息。

在断网或者应用重启等异常情况下，图中 4 提交的二次确认超时未到达 MQ Server，此时处理逻辑如下：
步骤5：MQ Server 对该消息发起消息回查。
步骤6：发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
步骤7：发送方根据检查得到的本地事务的最终状态再次提交二次确认。
步骤8：MQ Server基于 commit/rollback 对消息进行投递或者删除