CN112671827A - 一种分布式事务最终一致性方法 - Google Patents

Abstract

本发明提供了一种分布式事务最终一致性方法，步骤依次为消息的预发送、执行业务逻辑、服务A更新消息状态、发送的消息、消息消费、执行业务逻辑、服务B更新消息状态、消息确认服务A、消息确认服务B、异常处理，本发明所述的一种分布式事务最终一致性方法，提供单独的消息服务和对应的消息SDK，相对强一致性方案实现简单，提高***并发量；相对于TCC方案，侵入性小，实现简单、开发维护成本低；能够分布式事务的最终完成，解决现有最终一致性方案不能完全保证一致性的问题。

Description

一种分布式事务最终一致性方法

技术领域

本发明属于事务处理技术领域，尤其是涉及一种分布式事务最终一致性方法。

背景技术

随着分布式服务架构的流行与普及，原来在单体应用中执行的多个逻辑操作，现在被拆分成了多个服务之间的远程调用。虽然服务化为我们的***带来了水平伸缩的能力，然而随之而来挑战就是分布式事务问题，多个服务之间使用自己单独维护的数据库，它们彼此之间不在同一个事务中，假如A执行成功了，B执行却失败了，而A的事务此时已经提交，无法回滚，那么最终就会导致两边数据不一致性的问题；尽管很早之前就有基于两阶段提交的XA分布式事务，但是这类方案因为需要资源的全局锁定，导致性能极差；因此后面就逐渐衍生出了消息最终一致性、TCC等柔性事务的分布式事务方案；

1、消息生成者发送消息；

2、MQ收到消息，将消息进行持久化，在存储中新增一条记录；

3、返回ACK给生产者；

4、MQ推消息给对应的消费者，然后等待消费者返回ACK；

5、如果消息消费者在指定时间内成功返回ACK，那么MQ认为消息成功，在存储中删除消息，即执行第6步；如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会尝试重新推消息,重复执行4、5、6步骤；

6、MQ删除消息；

现有技术的客观缺点：

两阶段提交XA分布式事务：实现复杂，强一致性，严重影响并发性能；TCC柔性事务分布式方案：对微服务的侵入性强，微服务的每个事务都必须实现try、confirm、cancel等3个方法，开发成本高，今后维护改造的成本也高；现有普通消息最终一致性方案：存在一致性的问题；例如：我们以订单创建为例，订单***先创建订单(本地事务)，再发送消息给下游处理；如果订单创建成功，然而消息没有发送出去，那么下游所有***都无法感知到这个事件，会出现脏数据；如果先发送订单消息，再创建订单；那么就有可能消息发送成功，但是在订单创建的时候却失败了，此时下游***却认为这个订单已经创建，也会出现脏数据。

发明内容

有鉴于此，本发明旨在提出一种分布式事务最终一致性方法，以云计算分布式架构下，不同的服务之间有事务一致性的要求，本发明主要解决这种场景下事务最终一致性的问题。

为达到上述目的，本发明的技术方案是这样实现的：

一种分布式事务最终一致性方法，包括以下步骤

S1、消息的预发送：服务A在执行本地业务逻辑之前，首先通过消息SDK调用消息服务接口，将消息保存消费服务对应数据库中；

S2、执行业务逻辑：服务A执行需要保证事务的业务逻辑；

S3、服务A更新消息状态：服务A通过SDK调用消息服务更新消息状态为CanSend；

S4、发送的消息：消息服务中的消息发送任务，定时的从消息服务的数据库中获取可发送但未发送状态的消息，并发送到RabbitMQ中；

S5、消息消费：消息消费者-服务B，通过SDK注册消费者到RabbitMQ，当RabbitMQ中存在消息则接收消息并消费；

S6、执行业务逻辑：服务B执行事务内的业务逻辑；

S7、服务B更新消息状态：服务B根据执行业务逻辑的结果，通过SDK调用消息服务，更新消息状态为Completed或Failed；

S8、消息确认服务A：消息服务中的消息确认任务A，定时获取状态为Created且超时未发送的消息，并且向消息源端(即服务A)确认该消息是否可发送；

S9、消息确认服务B：消息服务中的消息确认任务B，定时获取状态为Sended且超时未收到反馈的消息，并且向消息目标端(即服务B)确认该消息是否执行完成；

S10、异常处理：消息服务中的消息失败通知服务，定时的将状态为SendFailed、AckFailed和Failed的消息，发送给管理员，最终由管理员人工处理异常

进一步的，所述所述步骤S1，当消息的状态是Created时；服务A通过SDK的调用是同步调用，消息服务将消息保存本地库，然后返回保存本地库成功或失败；如果消息服务保存消息失败，则直接异常，服务A不再向下执行逻辑；如果成功则执行步骤2

进一步的，所述所述步骤S3，当消息状态为CanSend时，服务A通过SDK的调用是同步调用，保证更新状态成功，如果更新消息状态失败，则步骤8兜底验证消息状态

进一步的，所述步骤S4，消息发送任务是一个定时任务，定时时间需要自行配置；当获取消息的状态为CanSended时；消息发送包含重试策略，重试策略包括：只发送一次；每隔相同的时间发送N次；在最小间隔时间和最大间隔时间之间发送N次，每次发送间隔逐步增加相同的值

进一步的，所述步骤S5，服务B通过注册到RabbitMQ中的消费者接收消息；服务B获取到消息之后，会将唯一的消息ID缓存到Redis中

进一步的，所述步骤7，如果服务B业务逻辑执行成功，则更新消息状态为Completed，整个分布式事务完成；如果服务B业务逻辑执行失败，则更新消息状态为Failed；如果执行失败会由步骤10人工兜底

进一步的，所述步骤S8，消息服务中的消息确认任务A需要自定义设置超时时间和询问次数；如果该消息经过多次询问并未得到答复，则将该消息设置为SendFailed，并最终由步骤10人工兜底

进一步的，所述步骤S9，消息服务中的消息确认任务B需要自定义设置超时时间和询问次数；如果该消息经过多次询问并未得到答复，则将该消息设置为AckFailed，并最终由步骤10人工兜底

进一步的，所述步骤S10，消息失败通知服务自定义设置定时任务时间、发送管理员邮件或短信、消息的优先级，消息失败通知服务会根据优先级可以设置不同的反馈级别和定时任务的时间

相对于现有技术，本发明所述的一种分布式事务最终一致性方法具有以下优势：

(1)本发明所述的一种分布式事务最终一致性方法，提供单独的消息服务和对应的消息SDK，相对强一致性方案实现简单，提高***并发量；相对于TCC方案，侵入性小，实现简单、开发维护成本低；能够分布式事务的最终完成，解决现有最终一致性方案不能完全保证一致性的问题。

附图说明

构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明实施例所述的背景技术的框图；

图2为本发明实施例所述的一种分布式事务最终一致性方法框图。

具体实施方式

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”等的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以通过具体情况理解上述术语在本发明中的具体含义。

下面将参考附图并结合实施例来详细说明本发明。

名词解释：

服务A和服务B均为微服务，例如，服务A是用户服务服务B是订单服务，用户购买商品后需要从用户服务扣钱，从订单服务扣库存，从用户服务扣钱，从订单服务扣库存，要不同时成功、要不同时失败。

ANSI是一种字符代码，为使计算机支持更多语言，通常使用0x00-0x7f范围的1个字节来表示1个英文字符。

API(Application Programming Interface，应用程序接口)是一些预先定义的函数，或指软件***不同组成部分衔接的约定，用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

RabbitMQ是实现了高级消息队列协议(AMQP)的开源消息代理软件(亦称面向消息的中间件)，RabbitMQ服务器是用Erlang语言编写的，而集群和故障转移是构建在开放电信平台框架上的，所有主要的编程语言均有与代理接口通讯的客户端库。

SDK(Software Development Kit，软件开发工具包)它可以简单的为某个程序设计语言提供应用程序接口API的一些文件，嵌套在某个代码工程中，可以方便的给该程序提供实现某种功能的api。

XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器(数据库)与事务管理器的接口标准。

X/Open组织将各种UNIX标准汇集到一起，包括新近研究的通用开放***环境(daoCOSE，Common Open System Environment)，X/Open公布的一系列规范总称为X/OpenPortability，MOTIF用户界面是其中被广泛使用的标准之一。

Unix是20世纪70年代初出现的一个操作***，除了作为网络操作***之外，还可以作为单机操作***使用。

Redis(Remote Dictionary Server)，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

Created：消息已创建，不可发送。

CanSend：消息可发送。

SendFailed：消息发送失败。

Sended：消息已发送。

Completed：消息已完成。

Failed：消息执行失败。

AckFailed：消息反馈失败。

TCC：分布式事务之Try-Confirm-Cancel，简称tcc，TCC相比直接方式的好处就是在有的场景下，TCC让你的分布式事务更加的符合业务体验。

try，confirm，cancel：TCC需要服务方提供更多更具体的接口，分别有Try接口、Confirm接口和Cancel接口。

幂等性：用在编程领域，意为对同一个***，使用同样的条件，一次请求和重复的多次请求对***资源的影响是一致的。

如图2所示，一种分布式事务最终一致性方法包括以下步骤：

S1、消息的预发送：服务A在执行本地业务逻辑之前，首先通过消息SDK调用消息服务接口，将消息保存消费服务对应数据库中；

S2、执行业务逻辑：服务A执行需要保证事务的业务逻辑；

S3、服务A更新消息状态：服务A通过SDK调用消息服务更新消息状态为CanSend；

S4、发送的消息：消息服务中的消息发送任务，定时的从消息服务的数据库中获取可发送但未发送状态的消息，并发送到RabbitMQ中；

S5、消息消费：消息消费者-服务B，通过SDK注册消费者到RabbitMQ，当RabbitMQ中存在消息则接收消息并消费；

S6、执行业务逻辑：服务B执行事务内的业务逻辑；

S7、服务B更新消息状态：服务B根据执行业务逻辑的结果，通过SDK调用消息服务，更新消息状态为Completed或Failed；

S8、消息确认服务A：消息服务中的消息确认任务A，定时获取状态为Created且超时未发送的消息，并且向消息源端(即服务A)确认该消息是否可发送；

S9、消息确认服务B：消息服务中的消息确认任务B，定时获取状态为Sended且超时未收到反馈的消息，并且向消息目标端(即服务B)确认该消息是否执行完成；

S10、异常处理：消息服务中的消息失败通知服务，定时的将状态为SendFailed、AckFailed和Failed的消息，发送给管理员，最终由管理员人工处理异常，提供单独的消息服务和对应的消息SDK，相对强一致性方案实现简单，提高***并发量；相对于TCC方案，侵入性小，实现简单、开发维护成本低；能够分布式事务的最终完成，解决现有最终一致性方案不能完全保证一致性的问题；

所述所述步骤S1，当消息的状态是Created时；服务A通过SDK的调用是同步调用，同步调用促进后续消息分布的一致性；如果消息服务保存消息失败，则直接异常，服务A不再向下执行逻辑，促进最终一致性；如果成功则执行步骤2，促进最终一致性；

所述所述步骤S3，当消息状态为CanSend时，服务A通过SDK的调用是同步调用，保证更新状态成功，如果更新消息状态失败，则步骤8兜底验证消息状态，步骤8兜底验证能够进一步保证消息的处理效率；

所述步骤S4，消息发送任务是一个定时任务，定时时间需要自行配置；当获取消息的状态为CanSended时；消息发送包含重试策略，重试策略包括：只发送一次；每隔相同的时间发送N次；在最小间隔时间和最大间隔时间之间发送N次，每次发送间隔逐步增加相同的值，步骤S4保证消息一定发送，但是可能会出现同一个消息发送多次，所以需要步骤S5保证幂等性，本发明的消息发送和接收的可靠性完全有RabbitMQ自身特性保证，这里不再累述；

所述步骤S5，服务B通过注册到RabbitMQ中的消费者接收消息；服务B获取到消息之后，会将唯一的消息ID缓存到Redis中，如果有则表示该消息已经被消费过，则不再处理该消息，以此来保证幂等性；

所述步骤7，如果服务B业务逻辑执行成功，则更新消息状态为Completed，整个分布式事务完成；如果服务B业务逻辑执行失败，则更新消息状态为Failed；如果执行失败会由步骤10人工兜底，步骤10人工兜底提高了消息处理的可靠性；

所述步骤S8，消息服务中的消息确认任务A需要自定义设置超时时间和询问次数；如果该消息经过多次询问并未得到答复，则将该消息设置为SendFailed，并最终由步骤10人工兜底，自定义设置超时时间和询问次数提高了使用人员的自由度，步骤10人工兜底提高了消息处理的可靠性；

所述步骤S9，消息服务中的消息确认任务B需要自定义设置超时时间和询问次数；如果该消息经过多次询问并未得到答复，则将该消息设置为AckFailed，并最终由步骤10人工兜底，步骤10人工兜底提高了消息处理的可靠性；

所述步骤S10，消息失败通知服务自定义设置定时任务时间、发送管理员邮件或短信、消息的优先级，多种媒介发送信息，提高了消息传达的成功率，消息失败通知服务会根据优先级可以设置不同的反馈级别和定时任务的时间，便于使用人员操作。

此发明为通用，在这里仅拿订单举例。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种分布式事务最终一致性方法，其特征在于：包括以下步骤

S1、消息的预发送：服务A在执行本地业务逻辑之前，首先通过消息SDK调用消息服务接口，将消息保存消费服务对应数据库中；

S2、执行业务逻辑：服务A执行需要保证事务的业务逻辑；

S3、服务A更新消息状态：服务A通过SDK调用消息服务更新消息状态为CanSend；

S4、发送的消息：消息服务中的消息发送任务，定时的从消息服务的数据库中获取可发送但未发送状态的消息，并发送到RabbitMQ中；

S5、消息消费：消息消费者-服务B，通过SDK注册消费者到RabbitMQ，当RabbitMQ中存在消息则接收消息并消费；

S6、执行业务逻辑：服务B执行事务内的业务逻辑；

S7、服务B更新消息状态：服务B根据执行业务逻辑的结果，通过SDK调用消息服务，更新消息状态为Completed或Failed；

S8、消息确认服务A：消息服务中的消息确认任务A，定时获取状态为Created且超时未发送的消息，并且向消息源端(即服务A)确认该消息是否可发送；

S9、消息确认服务B：消息服务中的消息确认任务B，定时获取状态为Sended且超时未收到反馈的消息，并且向消息目标端(即服务B)确认该消息是否执行完成；

S10、异常处理：消息服务中的消息失败通知服务，定时的将状态为SendFailed、AckFailed和Failed的消息，发送给管理员，最终由管理员人工处理异常。

2.根据权利要求1所述的一种分布式事务最终一致性方法，其特征在于：所述步骤S1，当消息的状态是Created时；服务A通过SDK的调用是同步调用，消息服务将消息保存本地库，然后返回保存本地库成功或失败；如果消息服务保存消息失败，则直接异常，服务A不再向下执行逻辑；如果成功则执行步骤2。

3.根据权利要求1所述的一种分布式事务最终一致性方法，其特征在于：所述步骤S3，当消息状态为CanSend时，服务A通过SDK的调用是同步调用，保证更新状态成功，如果更新消息状态失败，则步骤8兜底验证消息状态。

4.根据权利要求1所述的一种分布式事务最终一致性方法，其特征在于：所述步骤S4，消息发送任务是一个定时任务，定时时间需要自行配置；当获取消息的状态为CanSended时；消息发送包含重试策略，重试策略包括：只发送一次；每隔相同的时间发送N次；在最小间隔时间和最大间隔时间之间发送N次，每次发送间隔逐步增加相同的值。

5.根据权利要求1所述的一种分布式事务最终一致性方法，其特征在于：所述步骤S5，服务B通过注册到RabbitMQ中的消费者接收消息；服务B获取到消息之后，会将唯一的消息ID缓存到Redis中。

6.根据权利要求1所述的一种分布式事务最终一致性方法，其特征在于：所述步骤7，如果服务B业务逻辑执行成功，则更新消息状态为Completed，整个分布式事务完成；如果服务B业务逻辑执行失败，则更新消息状态为Failed；如果执行失败会由步骤10人工兜底。

7.根据权利要求1所述的一种分布式事务最终一致性方法，其特征在于：所述步骤S8，消息服务中的消息确认任务A需要自定义设置超时时间和询问次数；如果该消息经过多次询问并未得到答复，则将该消息设置为SendFailed，并最终由步骤10人工兜底。

8.根据权利要求1所述的一种分布式事务最终一致性方法，其特征在于：所述步骤S9，消息服务中的消息确认任务B需要自定义设置超时时间和询问次数；如果该消息经过多次询问并未得到答复，则将该消息设置为AckFailed，并最终由步骤10人工兜底。

9.根据权利要求1所述的一种分布式事务最终一致性方法，其特征在于：所述步骤S10，消息失败通知服务自定义设置定时任务时间、发送管理员邮件或短信、消息的优先级，消息失败通知服务会根据优先级可以设置不同的反馈级别和定时任务的时间。

Images