[发明专利]一种分布式事务最终一致性方法

说明书

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

技术领域

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

背景技术

随着分布式服务架构的流行与普及，原来在单体应用中执行的多个逻辑操作，现在被拆分成了多个服务之间的远程调用。虽然服务化为我们的系统带来了水平伸缩的能力，然而随之而来挑战就是分布式事务问题，多个服务之间使用自己单独维护的数据库，它们彼此之间不在同一个事务中，假如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执行事务内的业务逻辑；