解决方案
-
本地消息表
本地消息表的关键在于本地有一张存储消息日志的记录表，需要启动一个定时任务去不停地扫描消息日志记录，确保消息能够被发送。具体流程如下图：
上图流程：
1）事务发起方本地事务执行成功，在本地消息表中记录消息日志。
2）启动定时任务，循环扫描本地消息表。
3）定时任务扫描到消息则发送消息到消息中间件。
4）消息中间件收到消息，成功返回消息发送成功通知给事务发起方。
5）事务发起方收到消息发送成功则删除日志消息。
6）事务参与方订阅消息，消费消息。
7）事务参与方处理本地事务。
2、RocketMq事务消息方案
Apache RocketMQ 4.3之后的版本正式支持事务消息，为分布式事务实现提供了便利性支持。在RocketMQ 4.3后实现了完整的事务消息，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ内部，解决 Producer 端的消息发送与本地事务执行的原子性问题。
实现流程：
1）事务发起方发送Half事务消息
2）RocketMq回复Half发送成功
3）事务发起方执行本地事务
4）事务发起方执行本地事务成功，发送commit到RocketMq，mq投递消息到事务参与方；事务发起方执行本地事务失败，发送rollback到RocketMq，mq删除消息。
5）当RocketMq一定时间内未收到来自事务发起方的确认信息，会对事务发起方进行事务回查。
6）事务发起方查询本地事务状态。
7）事务发起方根据查询到的事务状态发送commint/rollback到RocketMq。
8）当RocketMq发起commit后，收到失败或一定时间未收到成功ack，则会发起重试。
总结：
优点：
消息数据独立存储，降低业务系统与消息系统之间的耦合。
吞吐量优于本地消息表方案。
缺点：
一次消息发送需要两次网络请求(half消息 + commit/rollback)。
需要实现消息回查接口。
其实每种分布式事务的解决方案都有优劣，我们需要权衡利弊，选择最合适业务场景的一种才是王道！