分布式事务有哪些常见的实现方案？-MQ事务消息

MQ事务消息：

1、MQ事务消息的执行流程：

基于MQ的分布式事务方案本质上是对本地消息表的封装，整体流程与本地消息表一致，唯一不同的就是将本地消息表存在了MQ内部，而不是业务数据库中，如下图：

由于将本地消息表存在了MQ内部，那么MQ内部的处理尤为重要，下面主要基于 RocketMQ4.3 之后的版本介绍 MQ 的分布式事务方案

2、RocketMQ事务消息：

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

（1）正常情况：

在事务主动方服务正常，没有发生故障的情况下，发消息流程如下：

• 步骤①：发送方向 MQ Server(MQ服务方)发送 half 消息
• 步骤②：MQ Server 将消息持久化成功之后，向发送方 ack 确认消息已经发送成功
• 步骤③：发送方开始执行本地事务逻辑
• 步骤④：发送方根据本地事务执行结果向 MQ Server 提交二次确认（commit 或是 rollback）。
• 最终步骤：MQ Server 如果收到的是 commit 操作，则将半消息标记为可投递，MQ订阅方最终将收到该消息；若收到的是 rollback 操作则删除 half 半消息，订阅方将不会接受该消息

（2）异常情况：

在断网或者应用重启等异常情况下，图中的步骤④提交的二次确认超时未到达 MQ Server，此时的处理逻辑如下：

• 步骤⑤：MQ Server 对该消息发起消息回查
• 步骤⑥：发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果
• 步骤⑦：发送方根据检查得到的本地事务的最终状态再次提交二次确认。
• 最终步骤：MQ Server基于 commit/rollback 对消息进行投递或者删除。

3、MQ事务消息的优缺点：

（1）优点：相比本地消息表方案，MQ 事务方案优点是：

• 消息数据独立存储 ，降低业务系统与消息系统之间的耦合
• 吞吐量大于使用本地消息表方案

（2）缺点：

• 一次消息发送需要两次网络请求(half 消息 + commit/rollback 消息) 。
• 业务处理服务需要实现消息状态回查接口。