事务想必大家并不陌生，比如经常被人提起的
ACID，但是为了后续的分布式事务的内容，我们先来聊聊ACID，然后再介绍下什么是分布式事务，最后着重讲下基于可靠消息的分布式事务解决方案。
什么是事务
严格意义上的事务应该是具备原子性、一致性、隔离性和持久性，简称 ACID。
原子性（Atomicity），可以理解为一个事务内的所有操作要么都执行，要么都不执行。一致性（Consistency），可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你钱包有100，我钱包有100，你给我打50块，此时你钱包的钱应该是50，我钱包的钱应该是150，不会存在我钱加了，你钱没扣的中间状态。隔离性（Isolation），指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。持久性（Durability），指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。
而通俗意义上事务就是为了使得一些更新操作要么都成功，要么都失败。
什么是分布式事务
分布式事务顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合而成。
一次大的操作由不同的小操作组成的，这些小的操作分布在不同的服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。从本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
常见的分布式事务的解决方案有以下几种:2PC,3PC,TCC,本地消息表、可靠消息最终一致性、尽最大努力通知等
今天我们就着重讲讲可靠消息最终一致性的解决方案
什么是可靠消息最终一致性方案
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后发出消息到消息中间件，事务参与方(消息消费者)一定能够接收到消息并处理事务成功，此方案强调的是只要消息发给事务参与方，则最终事务要达到一致。
这个方式存在哪些问题？
此方案是通过消息中间件实现的，事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，由于网络通信的不确定性会导致分布式事务问题，如下图：
本地事务与消息的原子性问题
如上图在虚线框内，存在以下几种情况：
1）本地事务提交失败，则消息不发送。
2）本地事务成功，消息发送失败，本地事务回滚。
3）本地消息成功，消息超时，本地事务回滚，消息最终失败。
4）本地消息成功，消息超时，本地事务回滚，消息最终成功。
综上所述，存在第四种情况，造成本地事务，与消息参与方的事务不一致。
事务参与方接收消息的可靠性。
消息中间件与事务参与方要确保能够成功消费到消息。
消息重复消费
注意事务参与方的接口幂等性问题，消息参与方可能已经成功消费，由于网络问题导致消息中间件认为消息未消费，发起重试之后产生的问题。
解决方案
本地消息表
本地消息表的关键在于本地有一张存储消息日志的记录表，需要启动一个定时任务去不停地扫描消息日志记录，确保消息能够被发送。具体流程如下图：
上图流程：
1）事务发起方本地事务执行成功，在本地消息表中记录消息日志。
2）启动定时任务，循环扫描本地消息表。
3）定时任务扫描到消息则发送消息到消息中间件。
4）消息中间件收到消息，成功返回消息发送成功通知给事务发起方。
5）事务发起方收到消息发送成功则删除日志消息。
6）事务参与方订阅消息，消费消息。
7）事务参与方处理本地事务。
8）本地事务处理成功，发送成功ack给消息中间件。
需要注意的点:事务参与方保证接口幂等性。
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)。
需要实现消息回查接口。
其实每种分布式事务的解决方案都有优劣，我们需要权衡利弊，选择最合适业务场景的一种才是王道！
