标签：事务 服务 可靠消息 发送 消息 本地 一致性 分布式

一、简介

生产上最常用的分布式事务解决方案——可靠消息最终一致性方案。所谓可靠消息最终一致性方案，其实就是在分布式系统当中，把一个业务操作转换成一个消息，然后利用消息来实现事务的最终一致性。

比如从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、如果消息重复投递，消息者的接口逻辑需要实现幂等性，保证多次处理一个消息不会插入重复数据或造成业务数据混乱。
针对这种情况，消费者可以准备一张消息表，用于判重。消费者消费消息后，需要去本地消息表查看这条消息有没处理成功，如果处理成功直接返回成功。

标签：事务,服务,可靠消息,发送,消息,本地,一致性,分布式
来源： https://www.cnblogs.com/Libbo/p/16035775.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。