解决方案之可靠消息最终一致性
1. 可靠消息最终一致性事务
可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。此方案是利用消息中间件完成，如下图：事务发起方(消息生产方)将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方(消息消费方)和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。
1.1 本地事务与消息发送的原子性问题
本地事务与消息发送的原子性问题即：事务发起方在本地事务执行成功后消息必须发出去，否则就丢弃消息。即实现本地事务和消息发送的原子性，要么都成功，要么都失败。本地事务与消息发送的原子性问题是实现可靠消息最终一致性方案的关键问题。 先来尝试下这种操作，先发送消息，再操作数据库：
begin transaction；
//1.发送MQ
//2.数据库操作
commit transation;这种情况下无法保证数据库操作与发送消息的一致性，因为可能发送消息成功，数据库操作失败。 你立马想到第二种方案，先进行数据库操作，再发送消息：
begin transaction；
//1.数据库操作
//2.发送MQ
commit transation;这种情况下貌似没有问题，如果发送MQ消息失败，就会抛出异常，导致数据库事务回滚。但如果是超时异常，数据库回滚，但MQ其实已经正常发送了，同样会导致不一致。
1.2 事务参与方接收消息的可靠性
事务参与方必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息，甚至事务参与方接收成功后但是业务逻辑处理报错，也需要重新接收消息。
1.3 消息重复消费的问题
由于图中网络2的存在，若某一个消费节点超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复消费。要解决消息重复消费的问题就要实现事务参与方的方法幂等性。
2. 解决方案
2.1 本地消息表方案
本地消息表这个方案最初是eBay提出的，此方案的核心是通过本地事务保证数据业务操作和消息的一致性，然后通过定时任务将消息发送至消息中间件，待确认消息发送给消费方成功再将消息删除。
下面以注册送积分为例来说明：
下例共有两个微服务交互，用户服务和积分服务，用户服务负责添加用户，积分服务负责增加积分。
交互流程如下：
- 用户注册
用户服务在本地事务新增用户和增加 "积分消息日志"。(用户表和消息表通过本地事务保证一致) 下边是伪代码
begin transaction；
//1.新增用户
//2.存储积分消息日志
commit transation;这种情况下，本地数据库操作与存储积分消息日志处于同一个事务中，本地数据库操作与记录消息日志操作具备原子性。
2. 定时任务扫描日志
如何保证将消息发送给消息队列呢？
经过第一步消息已经写到消息日志表中，可以启动独立的线程，定时对消息日志表中的消息进行扫描并发送至消息中间件，在消息中间件反馈发送成功后删除该消息日志，否则等待定时任务下一周期重试。
3. 消费消息
如何保证消费者一定能消费到消息呢？ 这里可以使用MQ的ack(即消息确认)机制，消费者监听MQ，如果消费者接收到消息并且业务处理完成后向MQ发送ack(即消息确认)，此时说明消费者正常消费消息完成，MQ将不再向消费者推送消息，否则消费者会不断重试向消费者来发送消息。积分服务接收到"增加积分"消息，开始增加积分，积分增加成功后向消息中间件回应ack，否则消息中间件将重复投递此消息。由于消息会重复投递，积分服务的"增加积分"功能需要实现幂等性。
2.2 RocketMQ事务消息方案
RocketMQ是一个来自阿里巴巴的分布式消息中间件，于2012年开源，并在2017年正式成为Apache顶级项目。据了解包括阿里云上的消息产品以及收购的子公司在内，阿里集团的消息产品全线都运行在RocketMQ之上，并且最近几年的双十一大促中，RocketMQ都有抢眼表现。Apache RocketMQ4.3之后的版本正式支持事务消息，为分布式事务实现提供了便利性支持。
3. 小结
可靠消息最终一致性就是保证消息从生产方经过消息中间件传递到消费方的一致性，本案例使用了RocketMQ作为消息中间件，RocketMQ主要解决了两个功能：
- 本地事务与消息发送的原子性问题。
- 事务参与方接收消息的可靠性。
可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。