一种实现分布式事物的方法及系统与流程

本发明属于信息处理技术领域，尤其涉及一种实现分布式事物的方法及系统。

【背景技术】

在传统的oltp系统领域，我们在很多场景下都会面临事物一致性方面的需求，例如最经典的bob给smith转账的案例。传统的企业开发，系统往往是以单体应用的形式存在的，也没有横跨多个数据库。而大型互联网平台往往是由一系列分布式系统都成的，开发语言和技术站也相对比较复杂，尤其是在soa和微服务架构盛行的今天，一个看起来简单的功能，内部可能需要调用多个“服务”并操作多个数据库或分片来实现，情况往往会复杂很多。单一的技术手段和解决方案已经无法应对和满足这些复杂的场景了。

提到分布式系统，必然要提到分布式事物。分布式事物就是在分布式环境下运行的事物，对于分布式事物来说，事物的每个操作步骤是运行在不同的机器上的服务。怎么保证运行与不同机器上的系统之间的一致性就是分布式事物所关注的问题。

提到分布式事物，很容易想到的是2pc，及两阶段提交。两阶段提交方案中参与事物的节点可以划分为两个角色，一个是协调者，一般是事物的发起方，一个是服务的参与者，及提供服务的一方。

现有技术中的二阶段提交(two-phase-commit)是指在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事物提交时保持一致性而设计的一种算法，如图1-2所示。所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段(执行阶段)

准备阶段：事物协调者(事务管理器)给每个参与者(资源管理器)发送prepare消息，每个参与者要么直接返回失败(入权限验证失败)，要么在本地执行事物，写本地的redo和undo日志，但是不提交事物，导到一种“完事具备，之前东风”的状态。

可以进一步将准备阶段分为以下三个步骤：

(1)协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待个参与节点的响应。

(2)参与者执行询问发起为止的所有事物操作，并将undo和redo信息写入日志。

(3)各参与者节点响应协调者节点发起的询问。如果参与者节点的事物操作实际执行成

功，则他返回一个统“同意”消息；如果参与者节点的事物操作实际执行失败，zeta返回一个“终止”消息。

提交阶段：如果协调者收到了参与者的失败消息或超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息；参与者根据协调者的指令执行提交或回滚操作，释放所有事物处理过程中使用的锁资源。

接下来分两种情况分别讨论提交阶段的过程。

当协调者从所有参与者节点获得的响应消息都为“是”时，如图1所示：

(1)协调者节点向所有参与者节点发出“正式提交”的请求。

(2)参与者节点正式完成事物操作，并释放在整个事物期间内占用的资源。

(3)参与者节点向协调者节点发送“完成”消息

(4)协调者节点收到所有参与组合节点反馈的“完成”消息后，完成事物

如果任意参与者节点在第一阶段返回拒绝消息“否”，如图2，或者协调者节点在询问超时之前无法获取所有节点的响应消息时：

(1)协调者节点向所有参与者节点发送“回滚”操作的请求

(2)参与者节点利用之前写入的undo信息执行回滚，并释放整个事物期间内占用的系统资源。

(3)参与者节点向协调者节点发送“回滚完成”消息。

(4)协调者节点收到所有参与者节点反馈的“回滚完成”消息后，取消事物。

不管最后结果如何，第二阶段都会结束当前事物。

现有技术中的两阶段提交存在以下缺点：

(1)同步阻塞问题。执行过程中，所有参与节点都是事物阻塞型的。当参与者占有公共资源时，其他第三方访问公共资源的应用节点将不得不处于阻塞状态。

(2)单点故障。由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去。

(3)数据不一致。在阶段二中，协调者向参与者发送commit请求的过程中，发生了局部网络故障，那么会导致只有一部分参与组接收到了commit请求，而另一部分协调者没有接受到commit请求。于是整个系统便出现了数据不一致的现象。

因此，迫切需要解决以下技术问题：

(1)通过对分布式事物中的一系列操作进行拓扑排序生成执行链，然后按照执行链来顺序执行，可以有效降低对整个系统中公共资源的占用，缓解同步阻塞问题。

(2)由于以合理的数据结构将执行链保存起来，以及各个子服务也将执行信息保存起来了，可以有效规避系统故障对整个系统一致性的影响。

(3)配合执行链的数据记录，以及子服务的执行记录，再加上集群容灾，可以在系统节点发生故障时，迅速恢复节点功能，避免单点故障性问题。

技术实现要素：

为了解决现有技术中的上述问题，本发明提出了一种实现分布式事物的方法，其特征在于，该方法包括如下步骤：

1)在执行分布式事物请求时，为所有操作生成一个执行链；

2)按照执行链的顺序，依次调用相关的子服务，发送相关数据，并等待反馈；

3)收到子服务的反馈消息后，刷新执行链的数据库记录，如果反馈消息是成功，则执行执行链中的下一步，跳转到步骤2)，如果反馈消息是失败消息，则按照执行链，反向执行逆向操作。

根据本发明的方法，优选的，采用数据结构保存所述执行链，所述数据结构包括关系型的数据库和/或非关系型数据库。

根据本发明的方法，优选的，所述步骤1)中，在执行分布式事物请求时，先对请求包含的所有操作进行拓扑排序，并为每个操作配置一个逆向操作，最终生成一个由所有操作组成的满足拓扑排序的执行链。

根据本发明的方法，优选的，子服务在接收到调用请求后，记录调用信息，并处理调用请求，执行完成后反馈成功/失败信息，并刷新本地调用记录；

所述数据结构中包含唯一的标识id、事物数据、上下游操作标识、当前操作节点、节点执行状态，以及节点执行节点信息；

通过缓存系统，对数据结构进行保存，更新。

根据本发明的方法，优选的，所述步骤3)中，在执行逆向操作的过程中，如果某操作发生失败，则表明本次事物执行失败，并刷新执行链的数据库记录记录，将其标为事物失败。

为了解决现有技术中的上述问题，本发明提出了一种实现分布式事物的系统，其特征在于，该系统包括：

执行链生成模块，在执行分布式事物请求时，为所有操作生成一个执行链；

服务调用模块，按照执行链的顺序，依次调用相关的子服务，发送相关数据，并等待反馈；

反馈接收处理模块，收到子服务的反馈消息后，刷新执行链的数据库记录，如果反馈消息是成功，则执行执行链中的下一步，如果反馈消息是失败消息，则按照执行链，反向执行逆向操作。

根据本发明的系统，优选的，采用数据结构保存所述执行链，所述数据结构包括关系型的数据库和/或非关系型数据库。

根据本发明的系统，优选的，所述执行链生成模块，在执行分布式事物请求时，先对请求包含的所有操作进行拓扑排序，并为每个操作配置一个逆向操作，最终生成一个由所有操作组成的满足拓扑排序的执行链。

根据本发明的系统，优选的，所述数据结构中包含唯一的标识id、事物数据、上下游操作标识、当前操作节点、节点执行状态，以及节点执行节点信息；

通过缓存系统，对数据结构进行保存，更新。

根据本发明的系统，优选的，还包括事物标记模块，在执行逆向操作的过程中，如果某操作发生失败，则表明本次事物执行失败，并刷新执行链的数据库记录记录，将其标为事物失败。

本发明的有益效果包括：可以缓解参与者子系统的阻塞问题；由于整个过程中记录了事物的失败情况，可以实现失败操作的修改，撤销，所以可以有效保证系统的一致性；本发明结合合理的记录数据，以及适当的集群容灾配置，可以有效避免单点故障问题，增强系统的健壮性。

【附图说明】

此处所说明的附图是用来提供对本发明的进一步理解，构成本发明的一部分，但并不构成对本发明的不当限定，在附图中：

图1是现有技术中的二阶段提交的成功示意图。

图2是现有技术中的二阶段提交的失败示意图。

图3是本发明的执行链示意图。

图4是采用本发明方案的执行方法流程图。

【具体实施方式】

下面将结合附图以及具体实施例来详细说明本发明，其中的示意性实施例以及说明仅用来解释本发明，但并不作为对本发明的限定。

事务：事务是指一系列操作要么全部执行，要么全部地不执行。事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关的操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。

acid：指的是数据库事物正确执行的四个基本要素的缩写。原子性(atomicity):整个事物中的一系列操作要么全部成功，要么全部失败，不会停留在某种中间状态；一致性(consistency)：事物的运行并不影响数据库中数据的一致性，如a+b＝10,如果a发生变化，那么b也随之变化。隔离性(isolation)：两个以上的事物不会出现交错执行的状态，因为这样可能会导致数据不一致。持久性(durability)：事物的持久性是指事物执行成功后，该事物对数据库的更改便会持久的保存在数据库中，不会无缘无故的回滚。

cap原则：cap原则又称cap定理，值得是在一个分布式系统中，consistency(一致性)，availability(可用性)，partitiontolerance(分区容错性)，三者不可兼得。consistency(一致性):分布式环境下，一致性值得是多个副本数据之间保持一致的特性，所有数据变动都是同步的；availability(可用性)：指的是分布式系统要一直可用，具有好的响应性，在有限的时间内返回结果；partitiontolerance(分区容错性)：分布式系统在遇到任何网络分区的故障时，仍然要能够对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

base理论：base是basicallyavailable(基本可用)，softstate(软状态)和eventuallyconsistent(最终一致性)三个短语的缩写。base理论是对cap原则中一致性，可用性权衡的结果，器来源于对大规模互联网分布式实践的总结，是基于cap定理逐步演化而来的，其核心思想是：及时无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。基本可用：指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，而不是系统不可用。软状态：值允许系统中的数据存在中间状态，不同节点的数据副本之间进行的数据同步可以存在延时，而不会影响系统的整体可用性。最终一致性：虽有的数据副本在经过一段时间的同步之后，最终都能达到一个一致的状态。

拓扑排序：对一个有向无环图(directedacyclicgraph简称dag)g进行拓扑排序，是将g中所有顶点排成一个线性序列，使得图中任意一对顶点u和v，若边(u,v)属于e(g)，则u在线性序列中出现在v之前。通常，这样的线性序列成为满足拓扑次序(topologicalorder)的序列，简称拓扑序列。

分布式事物往往涉及多个操作，而这些操作需要在不同的网络节点上执行，并且这些操作之间存在着依赖关系。故我们可以以拓扑排序的方式将这些操作进行排序，从而得到这些操作的一个满足拓扑次序的序列，并且为每个操作设计一个逆向操作。我们可以称这个序列为执行链。

为这条执行链精心设计一个数据结构，用来保存，传递这个执行链。这个数据结构中包含唯一的标识id，事物数据，上下游操作标识，当前操作节点，节点执行状态，以及节点执行节点信息等等一系列数据。借助高效的缓存系统，将这个数据结构进行保存，更新。这里的高效的缓存系统指的是一些非关系型的内存数据库，如redis，借助其发布订阅功能，每个服务对应一个主题，并只消费自己主题的消息，但是每个服务都可以发布其他主题的消息。

然后按照执行链的顺序一步步调用各个子服务。子服务在接收到调用请求后，记录调用信息，并处理请求，执行完成后反馈成功失败信息，并刷新本地调用记录。这里的本地调用记录指的是开始处理请求时记录的调用信息，是一个本地的一个调用日志。调用方在接到反馈信息后，如果是成功，则继续执行下一步，直至执行链执行完毕，如果是失败，则反向调用逆向操作，若果调用逆向操作的过程中发生失败，则直接将本次事物标记为失败。其中，执行链中的每个步骤就是一个操作，而这个操作是由具体的服务提供者完成的。

系统执行流程

1.在执行分布式事物时，先对请求包含的所有操作进行拓扑排序，并为每个操作配置一个逆向操作，最终生成一个由所有操作组成的满足拓扑排序的执行链。

2.为执行链设计合理的数据结构，将其保存起来，这里可以借助关系型的数据库也可以借助nosql型的非关系型数据库以及高效缓存系统。

3.按照执行链的顺序，依次调用相关的子服务，发送相关数据，并等待回馈。这里的相关数据指的是事物数据，包含事物的唯一标识，业务数据，以及上下游节点信息。

4.子服务在接收到请求后，先做调用记录，接着执行请求。如果成功，则向调用者反馈调用成功，如果失败，则向调用者反馈调用失败消息，并更新本地调用记录，执行回退。

5.调用者在收到子服务的反馈消息后，刷新执行链的数据库记录，如果是成功，则接着执行执行链中的下一步，如果是失败消息，则按照执行链，反向执行逆向操作。

6.在执行逆向操作的过程中，如果某操作发生失败，则直接表明本次事物执行失败，并刷新执行链的数据库记录记录，将其标为失败。

一次系统调用被分解成一个执行链，包含在多个服务上的操作。如果那个步骤失败，则按照执行链中的逆向操作进行回退，如果回退还失败，则直接终止回退操作，记录日志。

7.对于失败的事物，则需要系统自动或者手动的进行处理。

此外，本发明还公开了一种实现分布式事物的系统，该系统包括：

执行链生成模块，在执行分布式事物请求时，为所有操作生成一个执行链；

服务调用模块，按照执行链的顺序，依次调用相关的子服务，发送相关数据，并等待反馈；

反馈接收处理模块，收到子服务的反馈消息后，刷新执行链的数据库记录，如果反馈消息是成功，则执行执行链中的下一步，如果反馈消息是失败消息，则按照执行链，反向执行逆向操作。

采用数据结构保存所述执行链，所述数据结构包括关系型的数据库和/或非关系型数据库。

所述执行链生成模块，在执行分布式事物请求时，先对请求包含的所有操作进行拓扑排序，并为每个操作配置一个逆向操作，最终生成一个由所有操作组成的满足拓扑排序的执行链。

所述数据结构中包含唯一的标识id、事物数据、上下游操作标识、当前操作节点、节点执行状态，以及节点执行节点信息；

通过缓存系统，对数据结构进行保存，更新。

该系统还包括事物标记模块，在执行逆向操作的过程中，如果某操作发生失败，则表明本次事物执行失败，并刷新执行链的数据库记录记录，将其标为事物失败。

本发明方案中需要合理的使用缓存，巧妙精心的设计报文结构，结合合理的流程计算，可以使得分布式事物的执行中可以缓解参与者子系统的阻塞问题。

本发明方案所涉及的技术成熟，易于开发，实施。

由于整个过程中记录了事物的失败情况，可以实现失败操作的修改，撤销，所以可以有效保证系统的一致性。

本发明方案结合合理的记录数据，以及适当的集群容灾配置，可以有效避免单点故障问题，增强系统的健壮性。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、系统、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式发送机或其他可编程数据发送终端设备的发送器以产生一个机器，使得通过计算机或其他可编程数据发送终端设备的发送器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的系统。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据发送终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令系统的制造品，该指令系统实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据发送终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的发送，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的一种实现分布式事物的方法及系统，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。