分布式事务 ：可靠消息最终一致性方案

本地消息表

本地消息表的关键在于本地有一张存储消息日志的记录表，需要启动一个定时任务去不停地扫描消息日志记录，确保消息能够被发送。具体流程如下图：

 上图流程：

1）事务发起方本地事务执行成功，在本地消息表中记录消息日志。

2）启动定时任务，循环扫描本地消息表。

3）定时任务扫描到消息则发送消息到消息中间件。

4）消息中间件收到消息，成功返回消息发送成功通知给事务发起方。

5）事务发起方收到消息发送成功则删除日志消息。

6）事务参与方订阅消息，消费消息。

7）事务参与方处理本地事务。

2、RocketMq事务消息方案

Apache <code>RocketMQ</code> 4.3之后的版本正式支持<code>事务消息</code>，为分布式事务实现提供了便利性支持。在RocketMQ 4.3后实现了完整的事务消息，实际上其实是<code>对本地消息表的一个封装</code>，将本地消息表移动到了<code>MQ内部</code>，解决 Producer 端的消息发送与本地事务执行的<code>原子性</code>问题。

实现流程：

1）事务发起方发送<code>Half</code>事务消息

2）RocketMq回复<code>Half</code>发送成功

3）事务发起方执行本地事务

4）事务发起方执行本地事务成功，发送commit到RocketMq，mq投递消息到事务参与方；事务发起方执行本地事务失败，发送<code>rollback</code>到RocketMq，mq删除消息。

5）当RocketMq一定时间内未收到来自事务发起方的确认信息，会对事务发起方进行<code>事务回查</code>。

6）事务发起方查询本地事务状态。

7）事务发起方根据查询到的事务状态发送<code>commint/rollback</code>到RocketMq。

8）当RocketMq发起<code>commit</code>后，收到失败或一定时间未收到成功ack，则会发起重试。

总结：

<code>　　优点</code>：

　　　　消息数据独立存储，降低业务系统与消息系统之间的耦合。

　　　　吞吐量优于本地消息表方案。

<code>　　缺点</code>：

　　　　一次消息发送需要两次网络请求(half消息 + commit/rollback)。

　　　　需要实现消息回查接口。

其实每种分布式事务的解决方案都有优劣，我们需要权衡利弊，选择最合适业务场景的一种才是王道！