基于本地消息表的分布式事务，是最简便的实现方式，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于 eBay。
我们来看下面这张图，基于本地消息服务的分布式事务分为三大部分：
- 可靠消息服务：存储消息，因为通常通过数据库存储，所以也叫本地消息表
- 生产者（上游服务）：生产者是接口的调用方，生产消息
- 消费者（下游服务）：消费者是接口的服务方，消费消息
可靠消息服务
可靠消息服务就是一个单独的服务，有自己的数据库，其主要作用就是存储消息（包含接口调用信息，全局唯一的消息编号），消息通常包含以下状态：
- 待确认：上游服务发送待确认消息
- 已发送：上游服务发送确认消息
- 已取消（终态）：上游服务发送取消消息
- 已完成（终态）：下游服务确认接口执行完成
生产者
服务调用方（消息生产者）需要调用下游接口时，不直接通过 RPC 之类的方式调用，而是先生成一条消息，其主要步骤如下：
- 生产者调用接口前，先发送一条待确认消息（一般称为 half-msg，包含接口调用信息）给可靠消息服务，可靠消息服务会将这条记录存储到自己的数据库（或本地磁盘），状态为【待确认】；
- 生产者执行本地事务，本地事务执行成功并提交后，向可靠消息服务发送一条确认消息；如果本地执行失败，则向消息服务发送一条取消消息；
- 可靠消息服务如果收到消息后，修改本地数据库中的那条消息记录的状态改为【已发送】或【已取消】。如果是确认消息，则将消息投递到 MQ 消息队列（修改消息状态和投递 MQ 必须在一个事务里，保证要么都成功要么都失败）
为了防止出现：生产者的本地事务执行成功，但是发送确认/取消消息超时的情况。可靠消息服务里一般会提供一个后台定时任务，不停的检查消息表中那些【待确认】的消息，然后回调生产者（上游服务）的一个接口，由生产者确认到底是取消这条消息，还是确认并发送这条消息。
通过上面这套机制，可以保证生产者对消息的 100% 可靠投递。
消费者
服务提供方（消息消费者），从 MQ 消费消息，然后执行本地事务。执行成功后，反过来通知可靠消息服务，说自己处理成功了，然后可靠消息服务就会把本地消息表中的消息状态置为最终状态【已完成】 。
这里要注意两种情况：
- 消费者消费消息失败，或者消费成功但执行本地事务失败。
- 针对这种情况，可靠消息服务可以提供一个后台定时任务，不停的检查消息表中那些【已发送】但始终没有变成【已完成】的消息，然后再次投递到 MQ，让下游服务来再次处理。也可以引入 Zookeeper，由消费者通知 Zookeeper，生产者监听到 Zookeeper 上节点变化后，进行消息的重新投递。
- 如果消息重复投递，消息者的接口逻辑需要实现幂等性，保证多次处理一个消息不会插入重复数据或造成业务数据混乱。
- 针对这种情况，消费者可以准备一张消息表，用于判重。消费者消费消息后，需要去本地消息表查看这条消息有没处理成功，如果处理成功直接返回成功。
总结
这个方案的优点是简单，但最大的问题在于可靠消息服务是严重依赖于数据库的，即通过数据库的消息表来管理事务，不太适合并发量很高的场景。
Reference