一、简介
生产上最常用的分布式事务解决方案——可靠消息最终一致性方案。所谓可靠消息最终一致性方案，其实就是在分布式系统当中，把一个业务操作转换成一个消息，然后利用消息来实现事务的最终一致性。
比如从A账户向B账户转账的操作，当服务A从A账户扣除完金额后，通过消息中间件向服务B发一个消息，服务B收到这条消息后，进行B账户的金额增加操作。
可靠消息最终一致性方案一般有两种实现方式，原理其实是一样的：
-
基于本地消息表
-
基于支持分布式事务的消息中间件，如Kafka,RocketMQ等
二、本地消息表
基于本地消息表的分布式事务，是最简便的实现方式，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于eBay。
我们来看下面这张图，基于本地消息服务的分布式事务分为三大部分：
-
可靠消息服务：存储消息，因为通常通过数据库存储，所以也叫本地消息表
-
生产者（上游服务）：生产者是接口的调用方，生产消息
-
消费者（下游服务）：消费者是接口的服务方，消费消息
2.1 可靠消息服务
可靠消息服务就是一个单独的服务，有自己的数据库，其主要作用就是存储消息（包含接口调用信息，全局唯一的消息编号），消息通常包含以下状态：
-
待确认：上游服务发送待确认消息
-
已发送：上游服务发送确认消息
-
已取消（终态）：上游服务发送取消消息
-
已完成（终态）：下游服务确认接口执行完成
2.2 生产者
服务调用方（消息生产者）需要调用下游接口时，不直接通过RPC之类的方式调用，而是先生成一条消息，其主要步骤如下：
1、生产者调用接口前，先发送一条待确认消息（一般称为half-msg，包含接口调用信息）给可靠消息服务，可靠消息服务会将这条记录存储到自己的数据库（或本地磁盘），状态为【待确认】；
2、生产者执行本地事务，本地事务执行成功并提交后，向可靠消息服务发送一条确认消息；如果本地执行失败，则向消息服务发送一条取消消息；
3、可靠消息服务如果收到消息后，修改本地数据库中的那条消息记录的状态改为【已发送】或【已取消】。如果是确认消息，则将消息投递到MQ消息队列；（修改消息状态和投递MQ必须在一个事务里，保证要么都成功要么都失败）
为了防止出现：生产者的本地事务执行成功，但是发送确认/取消消息超时的情况。可靠消息服务里一般会提供一个后台定时任务，不停的检查消息表中那些【待确认】的消息，然后回调生产者（上游服务）的一个接口，由生产者确认到底是取消这条消息，还是确认并发送这条消息。
通过上面这套机制，可以保证生产者对消息的100%可靠投递。
2.3 消费者
服务提供方（消息消费者），从MQ消费消息，然后执行本地事务。执行成功后，反过来通知可靠消息服务，说自己处理成功了，然后可靠消息服务就会把本地消息表中的消息状态置为最终状态【已完成】 。
这里要注意两种情况：
1、消费者消费消息失败，或者消费成功但执行本地事务失败。
针对这种情况，可靠消息服务可以提供一个后台定时任务，不停的检查消息表中那些【已发送】但始终没有变成【已完成】的消息，然后再次投递到MQ，让下游服务来再次处理。也可以引入zookeeper，由消费者通知zookeeper，生产者监听到zookeeper上节点变化后，进行消息的重新投递。
2、如果消息重复投递，消息者的接口逻辑需要实现幂等性，保证多次处理一个消息不会插入重复数据或造成业务数据混乱。
针对这种情况，消费者可以准备一张消息表，用于判重。消费者消费消息后，需要去本地消息表查看这条消息有没处理成功，如果处理成功直接返回成功。
