CN112817704A - 分布式柔性事务处理方法及装置、存储介质及电子设备 - Google Patents

Abstract

本公开提供一种分布式柔性事务处理方法及装置、存储介质及电子设备；涉及互联网分布式事务处理技术领域。所述分布式柔性事务处理方法包括：接收柔性事务处理请求，识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作；调用第一操作子模块执行所述风险操作；调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行；依据所述第一及第二操作子模块的执行结果发送消息通知所述调用方所述柔性事务的处理结果。本公开可以缩小需要回滚的事务处理范围，降低事务处理成本，提升事务处理效率。

Description

分布式柔性事务处理方法及装置、存储介质及电子设备

技术领域

本公开涉及互联网分布式事务处理技术领域，具体而言，涉及一种分布式柔性事务处理方法、分布式柔性事务处理装置、电子设备以及计算机可读存储介质。

背景技术

在很多情况下，计算机需要将多个任务结合在一起完成一个业务要求，当多个任务中的部分任务执行失败时，可能会导致系统处于不一致的状态。为了解决这一问题，提出了事务的概念，也即将事务作为最小工作单元，事务中包含的所有任务作为一个整体进行工作，只有当全部任务都成功执行时，才认为该事务执行成功。

然而，由于上述方法通过当任一任务失败时，对所有任务进行回滚操作的方式来保证系统的一致性，会降低事务处理的效率，增加事务处理的成本。

因此提供一种高效率、低成本的分布式柔性事务处理方法具有重要意义。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开实施例提供一种分布式柔性事务处理方法及装置、电子设备以及计算机可读存储介质，进而可以解决回滚事务范围大，事务处理成本高及事务处理效率低等问题。

根据本公开的第一方面，提供一种分布式柔性事务处理方法，包括：

接收柔性事务处理请求，识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作；

调用第一操作子模块执行所述风险操作；

调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行；

依据所述第一及第二操作子模块的执行结果发送消息通知所述调用方所述柔性事务的处理结果。

在本公开的一种示例性实施例中，所述调用第一操作子模块执行所述风险操作，包括：

执行所述风险操作；

在所述风险操作执行成功时，调用所述第二操作子模块执行所述无风险操作。

在本公开的一种示例性实施例中，所述方法还包括：

在所述风险操作执行失败时，执行回滚并将对应的所述柔性事务标记为处理失败。

在本公开的一种示例性实施例中，所述执行所述风险操作，包括：

执行所述风险操作的预提交；

在所述风险操作的预提交全部通过时，执行所述风险操作的提交。

在本公开的一种示例性实施例中，在所述调用第二操作子模块执行未被标记的无风险操作之前，所述方法还包括：

定义一个事务补偿队列；其中，所述事务补偿队列的存储方式为先进先出。

在本公开的一种示例性实施例中，所述调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行，包括：

执行所述无风险操作；

在所述无风险操作执行失败时，将所述执行失败的无风险操作存储至所述事务补偿队列中；

通过所述事务补偿队列重新调用所述无风险操作，直至所述无风险操作被成功执行。

在本公开的一种示例性实施例中，所述通过所述事务补偿队列重新调用所述无风险操作，包括：

设置时间节点；

依据所述时间节点定时调用所述事务补偿队列中存储的所述无风险操作。

根据本公开的第二方面，提供一种分布式柔性事务处理装置，包括：

事务协调模块，用于接收柔性事务处理请求，识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作；

第一操作子模块，用于执行所述风险操作；

第二操作子模块，用于执行未被标记的无风险操作，直至所述无风险操作被成功执行；

结果反馈模块，用于依据所述第一及第二操作子模块的执行结果发送消息通知所述调用方所述柔性事务的处理结果。

根据本公开的第三方面，提供一种电子设备，包括：

处理器；

存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述方法。

根据本公开的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述方法。

本公开示例性实施例可以具有以下部分或全部有益效果：

在本公开示例实施方式所提供的分布式柔性事务处理方法中，在接收到柔性事务处理请求后，首先识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作；在标记完成后，调用第一操作子模块执行所述风险操作；此外，还需要调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行；依据所述第一及第二操作子模块的执行结果发送消息通知所述调用方所述柔性事务的处理结果。一方面，在本公开实施方式提供的分布式柔性事务处理方法中，对该柔性事务中的风险操作进行了标记，并将风险操作及无风险操作分模块执行，提高了事务处理的效率。另一方面，该分布式柔性事务处理方法由于确保无风险操作一定会被成功执行，因此无需对无风险操作执行回滚操作，缩小了需要回滚的事务处理范围，减少了事务失败的比例，优化了事务处理效果。同时，本示例实施方式提出的分布式柔性事务处理方法由于无需数据库或专用事务处理器的支持，因此也可以降低事务处理的成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了可以应用本公开实施例的一种分布式柔性事务处理方法及装置的示例性系统架构的示意图；

图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图；

图3示意性示出了根据本公开的一个实施例的分布式柔性事务处理方法的过程的流程图；

图4示意性示出了本公开的一个实施例应用场景中分布式柔性事务处理方法的过程的示意图；

图5示意性示出了根据本公开的一个实施例的分布式柔性事务处理装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1示出了可以应用本公开实施例的一种分布式柔性事务处理方法及装置的示例性应用环境的系统架构的示意图。

如图1所示，系统架构100可以包括终端设备101、102、103中的一个或多个，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端设备101、102、103可以是具有显示屏的各种电子设备，包括但不限于台式计算机、便携式计算机、智能手机和平板电脑等等。应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。

本公开实施例所提供的分布式柔性事务处理方法可以由终端设备101、102、103执行，相应地，分布式柔性事务处理装置可以设置于终端设备101、102、103中。本公开实施例所提供的分布式柔性事务处理方法也可以由服务器105执行，相应地，分布式柔性事务处理装置可以设置于服务器105中。本公开实施例所提供的分布式柔性事务处理方法还可以由终端设备101、102、103与服务器105共同执行，相应地，分布式柔性事务处理装置可以设置于终端设备101、102、103与服务器105中，本示例性实施例中对此不做特殊限定。

例如，在本示例实施方式中，可以在终端设备101、102、103上发送柔性事务处理请求，终端设备在接收到柔性事务处理请求后，将该柔性事务处理请求通过网络104发送至服务器105中，服务器105接收到该柔性事务处理请求后，识别出该柔性事务中对调用方存在风险的操作，将存在风险的操作标记为风险操作，调用第一操作子模块执行风险操作，并调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行。服务器105还可以依据上述第一及第二操作子模块的执行结果发送至终端设备，并通过终端设备通知调用方柔性事务的处理结果。当上述的分布式柔性事务处理方法在本地执行时，上述操作由端设备101、102、103或服务器105单独执行。

图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图2所示，计算机系统200包括中央处理单元(CPU)201，其可以根据存储在只读存储器(ROM)202中的程序或者从存储部分208加载到随机访问存储器(RAM)203中的程序而执行各种适当的动作和处理。在RAM 203中，还存储有系统操作所需的各种程序和数据。CPU201、ROM 202以及RAM 203通过总线204彼此相连。输入/输出(I/O)接口205也连接至总线204。

以下部件连接至I/O接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分207；包括硬盘等的存储部分208；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至I/O接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入存储部分208。

在本领域的相关技术中，在很多情况下，计算机需要将多个任务结合在一起完成一个业务要求，当多个任务中的部分任务执行失败时，可能会导致系统处于不一致的状态。为了解决这一问题，提出了事务的概念，也即将事务作为最小工作单元，事务中包含的所有任务作为一个整体进行工作，只有当全部任务都成功执行时，才认为该事务执行成功。

上述事务可以分为刚性事务及柔性事务两种。刚性事务遵循ACID(Atomicity、Consistency、Isolation、Durability)原则，具有强一致性，但在实践中要正确实现ACID并不容易，因此提出了相对于刚性事务的柔性事务。柔性事务遵循BASE(Basically-Available、Soft-state、Eventually-consistent)理论，与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。

对应于刚性事务处理及柔性事务处理，经常采用两阶段提交事务处理方法及TCC(try-confirm-cancel)事务处理方法来实现对于事务的处理。下面分别对这两种事务处理方法进行详细地介绍：

两阶段事务处理方法包括预提交阶段及提交阶段两个阶段，设置有一个协调者节点及多个参与者节点。在预提交阶段，协调者节点询问所有参与者节点是否可以执行提交操作，各参与者节点在其事务操作实际执行成功时，向协调者节点返回“同意”消息，在执行失败时，则返回“中止”消息。协调者节点在接收到所有参与者节点“同意”的回应时，向所有参与者节点发出提交请求，进入提交阶段。在提交阶段，各参与者节点正式完成操作，释放在整个事务期间内占用的资源，并向协调者节点发送提交完成消息，协调者节点受到所有参与者节点反馈的提交完成消息后完成事务。协调者节点在接收到任何一或多个参与者节点的“中止”消息时，给每个参与者节点发送回滚消息，并在接收到所有参与者节点反馈的回滚完成消息后取消事务。但该方式需要数据库支持或者专用的事务处理器，成本较高。

TCC事务处理将事务中的每个操作都分解为try-confirm-cancel三个子操作，在事务处理时，首先执行每个操作的try操作，该操作通常是预占事务需要的资源，预占成功后则执行confirm确认操作，如果执行失败则执行cancel取消操作。总体操作流程中，某个环节失败则将需要将之前的confirm操作回滚，以释放资源。该种方式降低了对专用数据库的依赖，可以用在微服务中，但是开发成本较高，需要为每个操作都设置三个子操作。

为了解决上述方法中存在的回滚事务范围大，事务处理成本高及事务处理效率低等问题，在本示例实施方式中，发明人提出了一种新的技术方案，以下对本公开实施例的技术方案进行详细阐述：

本示例实施方式首先提供了一种分布式柔性事务处理方法，该分布式柔性事务处理方法如图3所示，具体包括以下步骤：

步骤S310：接收柔性事务处理请求，识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作；

步骤S320：调用第一操作子模块执行所述风险操作；

步骤S330：调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行；

步骤S340：依据所述第一及第二操作子模块的执行结果发送消息通知所述调用方所述柔性事务的处理结果。

在公开示例实施方式所提供的分布式柔性事务处理方法中，一方面，在本公开实施方式提供的分布式柔性事务处理方法中，对该柔性事务中的风险操作进行了标记，并将风险操作及无风险操作分模块执行，提高了事务处理的效率。另一方面，该分布式柔性事务处理方法由于确保无风险操作一定会被成功执行，因此无需对无风险操作执行回滚操作，缩小了需要回滚的事务处理范围，减少了事务失败的比例，优化了事务处理效果。同时，由于无需数据库或专用事务处理器的支持，也可以降低事务处理的成本。

下面，在另一实施例中，对上述步骤进行更加详细的说明。

在步骤S310中，接收柔性事务处理请求，识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作。

在本示例实施方式中，事务是一系列操作的集合，该事务中包含的所有操作作为一个整体进行工作，只有当全部操作都成功执行时，才认为该事务执行成功，否则则认为该任务执行失败。举例而言，上述事务可以为银行的转账业务，该事务通常包含有从源账户转出资金、向目标账户转入资金及赠送积分三个操作，只有在这三个操作都执行成功时，该事务才被认为成功执行，其中任何一个操作出现问题，该事务都会被认为执行失败。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，柔性事务是相对于刚性事务而言的，通常情况下，事务可以分为刚性事务及柔性事务两种。刚性事务遵循ACID(Atomicity、Consistency、Isolation、Durability)原则，即遵循原子性，一致性、隔离性及持久性原则，具有强一致性，举例而言，数据库事务便是常见的刚性事务。与刚性事务不同，柔性事务满足的是最终一致性，即允许在一定时间内，不同节点的数据不一致。柔性事务遵循的是BASE(Basically-Available、Soft-state、Eventually-consistent)理论，即遵循基本可用、软状态及最终一致性理论。举例而言，多数分布式事务都是指柔性事务。需要说明的是，上述列举只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，调用方为发起柔性事务请求，调用上述柔性事务的操作方。例如，在银行的转账业务中，事务的调用方为银行；在支付业务中，事务的调用方为发起收款的一方等，除此之外，其他符合上述定义的事务调用方也属于本示例实施方式的保护范畴。

在本示例实施方式中，上述调用方可以在终端设备上发起柔性事务请求，终端设备在接收到该柔性事务请求后，系统服务器通过网络或其他通信链路接收该柔性事务处理请求。举例而言，在上述的银行转账业务中，调用方可以通过终端设备上的网银应用或小程序发起转账请求，对应的网银服务器可以通过网络或其他通信链路接收该转账请求并执行后续操作。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，风险操作为对调用方存在风险的操作，也即存在失败风险，进而导致上述事务执行失败的操作。在本示例实施方式中，需要对上述风险操作进行标记。以上述银行的转账业务为例，该转账业务所包含的从源账户转出资金、向目标账户转入资金及赠送积分三个操作中，对于调用方银行来说，只有从源账户转出资金这一操作存在风险，而向目标账户转入资金及赠送积分这两项操作都是无风险的。因此，将从源账户转出资金这一操作视为风险操作并进行标记。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，系统在接收到上述柔性事务请求后，需要对上述风险操作进行识别及标记。举例而言，该步骤可以实现如下：在系统中为每个事务设置一张映射表，将事务中包含的所有操作通过该映射表映射为风险操作或无风险操作。当系统接收到事务请求时，通过上述映射表中的映射关系识别出该事务中包含的风险操作，并对识别出的风险操作对应的数据包的包头进行标记。需要说明的是，上述场景只是一种示例性说明，其他识别及标记事务中风险操作的方法也属于本示例实施方式的保护范畴。

在步骤S320中，调用第一操作子模块执行所述风险操作。

在本示例实施方式中，第一操作子模块为上述风险操作的执行模块，该第一操作子模块执行上述风险操作的方式可以为两阶段事务处理方法，也可以为TCC(try-confirm-cancel)事务处理方法，还可以其他的事务处理方法，本示例实施方式对此不做特殊限定。

在本示例实施方式中，采用两阶段事务处理方法执行上述风险操作具体实现可以如下：该方法包括预提交阶段及提交阶段两个阶段，设置有一个协调者节点及多个参与者节点，在本示例实施方式中，参与者节点为被标记的一个或多个上述风险操作。在预提交阶段，协调者节点询问所有参与者节点是否可以执行提交操作，各参与者节点在其风险操作实际执行成功时，向协调者节点返回“同意”消息，在执行失败时，则返回“中止”消息。协调者节点在接收到所有参与者节点“同意”的回应时，向所有参与者节点发出提交请求，进入提交阶段。在提交阶段，各参与者节点正式完成操作，释放在整个事务期间内占用的资源，并向协调者节点发送提交完成消息，协调者节点受到所有参与者节点反馈的提交完成消息后完成事务。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，采用TCC(try-confirm-cancel)事务处理方法执行上述风险操作的实现具体可以如下：首先执行每个风险操作的try操作，该操作通常是预占事务需要的资源，预占成功后则执行confirm确认操作，如果执行失败则执行cancel取消操作。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，在上述风险操作执行失败时，需要对上述风险操作执行回滚操作，并将对应的柔性事务标记为处理失败。例如，当采用两阶段事务处理方法执行上述风险操作时，上述回滚具体实现可以为：协调者节点在接收到任何一或多个参与者节点的“中止”消息时，给每个参与者节点发送回滚消息，并在接收到所有参与者节点反馈的回滚完成消息后取消事务；当采用TCC(try-confirm-cancel)事务处理方法执行上述风险操作时，上述回滚具体实现可以为：总体操作流程中的某个环节失败时，将之前的confirm操作回滚，以释放资源。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在上述风险操作被成功执行时，则跳转至步骤S330：

在步骤S330中，调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行。

在本示例实施方式中，无风险操作为上述柔性事务中未被标记为风险操作的其他操作。以上述银行的转账业务为例，该转账业务所包含的从源账户转出资金、向目标账户转入资金及赠送积分三个操作中，只有从源账户转出资金这一操作存在风险，而向目标账户转入资金及赠送积分这两项操作都是无风险的，向目标账户转入资金及赠送积分即为上述无风险操作。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，第二操作子模块为上述无风险操作的执行模块，在该模块中采用技术手段确保上述无风险操作被成功执行，从而达到减少失误回滚的范围的效果。举例而言，该第二操作子模块执行上述无风险操作的具体实现可以如下：定义一个事务补偿队列，在上述无风险操作执行失败时，将执行失败的无风险操作存储至该事务补偿队列中，并通过该事务补偿队列重新调用所述无风险操作，直至所述无风险操作被成功执行。需要说明的是，上述实现过程只是一种示例性说明，使用其他技术手段确保上述无风险操作被成功执行的过程也属于本示例实施方式的保护范畴。

在本示例实施方式，以银行的转账业务为例，对应于上述示例中提出的确保无风险操作成功执行的技术手段，具体过程可以如下：定义一个事务补偿队列，在上述向目标账户转入资金和/或赠送积分这两项无风险操作执行失败时，将执行失败的无风险操作存储至该事务补偿队列中，并通过该事务补偿队列重新调用执行失败的向目标账户转入资金和/或赠送积分，直至其被成功执行。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，上述事务补偿队列存储执行失败的上述无风险操作的方式为先进先出，即先存储进该事务补偿队列的执行失败的无风险操作会先被调用。以上述银行的转账业务为例，该转账业务所包含的从源账户转出资金、向目标账户转入资金及赠送积分三个操作中，向目标账户转入资金及赠送积分这两项操作是无风险操作，假设向目标账户转入资金先于赠送积分被存储至该事务补偿队列中，则在上述通过该事务补偿队列重新调用这两项执行失败的无风险操作时，先调用向目标账户转入资金，后调用赠送积分。需要说明的是，上述场景只是一种示例性说明，本示例实施方式的保护范畴并不以此为限。

在本示例实施方式中，可以通过定时的方式重新调用存储在上述事务补偿队列中执行失败的无风险操作。定时的方式可以为设置一个单位时间，每隔一个该单位时间重新调用一次存储在上述事务补偿队列中执行失败的无风险操作，举例而言，该单位时间可以为十分钟，也可以为一小时，还可以为根据实际需要确定的任意时间间隔，本示例实施方式对此不做特殊限定。

在步骤S340中，依据所述第一及第二操作子模块的执行结果发送消息通知所述调用方所述柔性事务的处理结果。

在本示例实施方式中，执行结果为上述第一及第二操作子模块对上述风险操作及无风险操作执行成功或执行失败的结果。该第一操作子模块及第二操作子模块需要对该执行结果进行反馈，系统接收到反馈结果后，依据该反馈结果将上述柔性事务的处理结果发送至调用方。以上述银行的转账业务为例，若从源账户转出资金这一风险操作执行失败，上述第一操作子模块会对该操作执行回滚，将上述柔性事务标记为处理失败，并对这一结果进行反馈，系统接收到该反馈后，发送消息通知调用方所调用的柔性事务处理失败。若从源账户转出资金、向目标账户转入资金及赠送积分三个操作均成功，上述第一操作子模块及第二操作子模块分别将执行成功的结果反馈至系统，系统接收到该反馈后，发送消息通知调用方所调用的柔性事务处理成功。需要说明的是，上述场景只是一种示例性说明，并不涵盖所有情形，本示例实施方式的保护范畴也并不以此为限。

下面结合图4所示的具体场景，以银行的转账业务为例，对本示例实施方式中的分布式柔性事务处理方法进行进一步的说明。

在步骤S410中，接收事务操作请求。

在本具体应用场景中，以银行的转账业务为例，该步骤体现为接收来自调用方的转账请求。

在步骤S420中，标记风险操作。

在本具体应用场景中，以银行的转账业务为例，该银行转账业务包含从源账户转出资金、向目标账户转入资金及赠送积分三个操作，标记风险操作的步骤具体可以为：识别出该银行转账业务中可能存在失败风险的操作，这上述三个操作中，从源账户转出资金这一操作可能会因为源账户余额不足或资金被冻结等原因存在无法转出进而导致操作失败的风险，而向目标账户转入资金及赠送积分这两个操作是利用技术手段可以确保成功的操作，因此识别出从源账户转出资金为风险操作并进行标记。

在步骤S430中，将操作提交给事务协调器。

在本具体应用场景中，上述事务协调器用来对系统中的各模块进行协调及调用。以银行的转账业务为例，该步骤具体实现可以为：将从源账户转出资金、向目标账户转入资金及赠送积分三个操作提交给上述事务协调器。

在步骤S440中，执行风险操作。

在本具体应用场景中，上述事务协调器调用风险操作执行模块执行被标记的风险操作。以银行的转账业务为例，该步骤具体实现可以为：执行从源账户转出资金这一被标记的风险操作。

在步骤S450中，判断风险操作是否成功，以银行的转账业务为例，该步骤具体实现可以为：判断从源账户转出资金这一风险操作是否执行成功，并依据判断结果，执行相应的操作，具体包括以下步骤S451至步骤S453：

在步骤S451中，在风险操作执行成功时，跳转至步骤S460。

在本具体应用场景中，以银行的转账业务为例，该步骤具体实现可以为：在从源账户转出资金这一风险操作执行成功时，则跳转至步骤S460。

在步骤S452中，在风险操作执行失败时，执行回滚操作。

在本具体应用场景中，以银行的转账业务为例，该步骤具体实现可以为：在从源账户转出资金这一风险操作执行失败时，则对该风险操作执行回滚，也即系统恢复至执行从源账户转出资金这一风险操作前的状态。

在步骤S453中，标记事务处理失败，并跳转至步骤S490。

在本具体应用场景中，以银行的转账业务为例，该步骤具体实现可以为：在从源账户转出资金这一风险操作执行失败时，将该操作对应的事务即银行转账请求标记为失败，并跳转至步骤S490。

在步骤S460中，执行无风险操作。

在本具体应用场景中，上述事务协调器调用风险操作执行模块执行被标记的风险操作。以银行的转账业务为例，该步骤具体实现可以为：执行向目标账户转入资金及赠送积分这两项未被标记的无风险操作。

在步骤S470中，判断无风险操作是否成功，以银行的转账业务为例，该步骤具体实现可以为：判断向目标账户转入资金及赠送积分是否执行成功，并依据判断结果，执行相应的操作，具体包括以下步骤S471至步骤S474：

在步骤S471中，在无风险操作执行成功时，跳转至步骤S480。

在本具体应用场景中，以银行的转账业务为例，该步骤具体实现可以为：在向目标账户转入资金及赠送积分这两项无风险操作都执行成功时，跳转至步骤S480。

在步骤S472中，将执行失败的无风险操作加入事务补偿队列。

在本具体应用场景中，事务补偿队列用来存储执行失败的无风险操作。以银行的转账业务为例，当向目标账户转入资金及赠送积分这两项无风险操作中的一项执行失败或者两项都失败时，将执行失败的操作存储至该事务补偿队列中。

在步骤S473中，定时调用事务补偿队列中存储的无风险操作，跳转至步骤S460。

在本具体应用场景中，上述事务补偿队列存储执行失败的无风险操作采取先进先出的方式，故上述定时调用该事务补偿队列中存储的无风险操作也采用先进先出的方式。以银行的转账业务为例，若向目标账户转入资金这一操作执行失败后赠送积分也执行失败，这两项无风险操作先后被存储进上述事务补偿队列中，在通过该事务补偿队列调用无风险操作时，会先调用向目标账户转入资金的操作，后调用赠送积分的操作，该重新调用跳转至步骤S460。

在本具体应用场景中，定时调用是指设置一个单位时间，每隔该单位时间调用一次上述事务补偿队列存储的无风险操作。以银行的转账业务为例，可以设置一个五分钟的单位时间，每隔五分钟调用一次存储在上述事务补偿队列中的向目标账户转入资金和/或赠送积分操作。

在步骤S480中，标记事务处理成功。

在本具体应用场景中，以银行的转账业务为例，该步骤具体实现可以为：在上述风险操作从源账户转出资金，及无风险操作向目标账户转入资金和赠送积分操作都执行成功时，该这三个操作所对应的事务银行转账请求标记为处理成功。

在步骤S490中，通知调用者。

在本具体应用场景中，以银行的转账业务为例，该步骤具体实现可以为：事务银行转账请求的处理结果发送消息至发起转账请求的调用者。

在本具体应用场景中，一方面，对事务中的风险操作进行了标记，并将风险操作及无风险操作分模块执行，提高了事务处理的效率。另一方面，该方法由于确保无风险操作一定会被成功执行，因此无需对无风险操作执行回滚操作，缩小了需要回滚的事务处理范围，减少了事务失败的比例，优化了事务处理效果。同时，由于无需数据库或专用事务处理器的支持，也可以降低事务处理的成本。

应当注意，上述应用场景只是一种示例性说明，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

进一步地，本示例实施方式提供了一种分布式柔性事务处理装置。参考图5所示，该分布式柔性事务处理装置500可以包括事务协调模块510、第一操作子模块520、第二操作子模块530以及结果反馈模块540。

其中：

事务协调模块510可以用于接收柔性事务处理请求，识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作；

第一操作子模块520可以用于执行所述风险操作；

第二操作子模块530可以用于执行未被标记的无风险操作，直至所述无风险操作被成功执行；

结果反馈模块540可以用于发送消息通知调用者所述柔性事务的处理结果。

上述分布式柔性事务处理装置中各模块或单元的具体细节已经在对应的分布式柔性事务处理方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如上述实施例中所述方法。例如，所述电子设备可以实现如图3～图4所示的各个步骤等。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种分布式柔性事务处理方法，其特征在于，包括：

接收柔性事务处理请求，识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作；

调用第一操作子模块执行所述风险操作；

调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行；

依据所述第一及第二操作子模块的执行结果发送消息通知所述调用方所述柔性事务的处理结果。

2.根据权利要求1所述的分布式柔性事务处理方法，其特征在于，所述调用第一操作子模块执行所述风险操作，包括：

执行所述风险操作；

在所述风险操作执行成功时，调用所述第二操作子模块执行所述无风险操作。

3.根据权利要求2所述的分布式柔性事务处理方法，其特征在于，所述方法还包括：

在所述风险操作执行失败时，执行回滚并将对应的所述柔性事务标记为处理失败。

4.根据权利要求1所述的分布式柔性事务处理方法，其特征在于，所述执行所述风险操作，包括：

执行所述风险操作的预提交；

在所述风险操作的预提交全部通过时，执行所述风险操作的提交。

5.根据权利要求1所述的分布式柔性事务处理方法，其特征在于，在所述调用第二操作子模块执行未被标记的无风险操作之前，所述方法还包括：

定义一个事务补偿队列；其中，所述事务补偿队列的存储方式为先进先出。

6.根据权利要求5所述的分布式柔性事务处理方法，其特征在于，所述调用第二操作子模块执行未被标记的无风险操作，直至所述无风险操作被成功执行，包括：

执行所述无风险操作；

在所述无风险操作执行失败时，将所述执行失败的无风险操作存储至所述事务补偿队列中；

通过所述事务补偿队列重新调用所述无风险操作，直至所述无风险操作被成功执行。

7.根据权利要求6所述的分布式柔性事务处理方法，其特征在于，所述通过所述事务补偿队列重新调用所述无风险操作，包括：

设置时间节点；

依据所述时间节点定时调用所述事务补偿队列中存储的所述无风险操作。

8.一种分布式柔性事务处理装置，其特征在于，包括：

事务协调模块，用于接收柔性事务处理请求，识别出所述柔性事务中对调用方存在风险的操作，并将所述存在风险的操作标记为风险操作；

第一操作子模块，用于执行所述风险操作；

第二操作子模块，用于执行未被标记的无风险操作，直至所述无风险操作被成功执行；

结果反馈模块，用于依据所述第一及第二操作子模块的执行结果发送消息通知所述调用方所述柔性事务的处理结果。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7任一项所述的方法。

10.一种电子设备，其特征在于，包括：

处理器；

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-7任一项所述的方法。

Images