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

Abstract

本公开实施例提供了一种分布式事务处理方法、装置、电子设备及存储介质，可涉及分布式服务、游戏和云技术等领域，该方法包括：生成待处理的分布式事务对应的流程实例；基于流程实例，依次调用流程实例对应的至少两个服务节点中的各节点执行各自对应的事务操作，直至流程实例执行成功，或者任一当前服务节点的事务操作执行异常；若出现当前服务节点的事务操作执行异常的情况，则根据流程实例的当前执行状态和流程补偿策略集，确定流程实例对应的流程补偿策略，流程补偿策略集中包括各种流程实例执行状态所对应的事务补偿策略；根据流程实例对应的流程补偿策略，执行对应的流程补偿操作。基于本公开的该方法，能够更好的满足实际应用需求。

Description

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

技术领域

本公开属于计算机技术领域，可涉及分布式服务、游戏和云技术等领域，具体而言，本公开涉及一种分布式事务处理方法、装置、电子设备及存储介质。

背景技术

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。随着分布式架构的普及，分布式事务问题已经很多应用系统需要解决的问题。

目前虽然已经存在多种不同的分布式解决方案，但是大多分布式事务的解决方案方式实现都不够灵活，有些实现逻辑复杂度过高，尤其是在业务种类比较繁多的业务场景中，都无法很好的覆盖数据一致性问题。比如，在游戏应用中的虚拟资源发放场景中，虚拟资源的种类繁多，不用虚拟资源发放的业务逻辑实现也会有所不同，目前的分布式解决方案都很难满足实际的业务需求，都有待改进。

发明内容

本公开实施例的目的旨在提供一种能够更好的满足实际应用需求的分布式事务处理方法，为了实现上述目的，本公开实施例提供的技术方案如下：

一方面，本公开实施例提供了一种分布式事务处理方法，该方法包括：

获取待处理的分布式事务，生成所述分布式事务对应的流程实例；

基于所述流程实例，依次通过所述流程实例对应的至少两个服务节点中的各节点执行第一操作，直至所述流程实例执行成功，或者任一当前服务节点的事务操作执行异常；第一操作包括：通过当前服务节点执行该服务节点对应的事务操作，若执行成功，将所述流程实例的执行状态更新为该服务节点的事务操作执行成功；

其中，若出现当前服务节点的事务操作执行异常的情况，则根据所述流程实例的当前执行状态，从流程补偿策略集中确定出所述流程实例对应的流程补偿策略，所述流程补偿策略集中包括各种流程实例执行状态所对应的流程补偿策略；

根据所述流程实例对应的流程补偿策略，对所述流程实例执行对应的流程补偿操作。

一方面，本公开实施例提供了一种分布式事务处理装置，该装置包括：

流程实例生成模块，用于获取待处理的分布式事务，生成所述分布式事务对应的流程实例；

流程实例执行模块，用于基于所述流程实例，依次通过所述流程实例对应的至少两个服务节点中的各节点执行第一操作，直至所述流程实例执行成功，或者任一当前服务节点的事务操作执行异常；第一操作包括：通过当前服务节点执行该服务节点对应的事务操作，若执行成功，将所述流程实例的执行状态更新为该服务节点的事务操作执行成功；

流程补偿处理模块，用于在出现当前服务节点的事务操作执行异常的情况下，根据所述流程实例的当前执行状态，从流程补偿策略集中确定出所述流程实例对应的流程补偿策略，根据所述流程实例对应的流程补偿策略，对所述流程实例执行对应的流程补偿操作，其中，所述流程补偿策略集中包括各种流程实例执行状态所对应的流程补偿策略。

可选的，所述流程实例包括实例标识和实例内容。

可选的，流程实例执行模块还用于：将所述流程实例的实例标识存储到未完成流程实例队列中；若所述流程实例执行成功，则将所述流程实例的实例标识从所述未完成流程实例队列删除；

若所述流程实例对应的流程补偿操作执行失败，流程补偿处理模块还用于：

响应于满足所述流程实例的延时补偿触发条件，再次对所述流程实例执行对应的流程补偿操作；

若所述流程补偿操作重试成功，则继续执行所述流程实例。

可选的，若所述流程实例对应的流程补偿操作执行失败，流程补偿处理模块还用于：

确定所述流程实例对应的延时补偿时间戳；

若所述延时补偿时间戳对应的时间到达，确定满足所述流程实例的延时补偿触发条件；

若所述流程补偿操作重试失败，更新所述未完成流程实例队列中存储的所述流程实例的延时补偿时间戳。

可选的，流程补偿处理模块还用于：若所述流程补偿操作的重试次数达到设定次数且流程补偿操作执行失败，根据所述当前执行状态，执行事务回滚操作或将所述流程实例写入指定队列。

流程补偿处理模块还用于：对所述未完成流程实例队列进行轮询操作，若所述未完成流程实例队列中存在存储时长达到设定时长的实例标识，则根据该实例标识对应的流程实例执行状态，执行对应的流程补偿操作。

可选的，流程补偿处理模块在从流程补偿策略集中确定所述流程实例对应的流程补偿策略时，可以用于：

根据所述流程实例的实例标识和所述当前执行状态，生成所述流程实例对应的流程补偿事件；

确定所述流程实例对应的流程标识，所述流程标识对应一种流程定义；

根据所述流程标识，从预配置的各流程补偿队列中确定出所述流程实例对应的目标流程补偿队列，其中，每个流程补偿队列对应一种流程定义；

将所述流程实例对应的流程补偿事件分发到所述目标流程补偿队列；

对各所述流程实例中的流程补偿事件进行处理，在到达所述目标流程补偿队列中所述流程实例对应的流程补偿事件的处理时机时，根据所述流程补偿事件对应的当前执行状态，从流程补偿策略集中确定出所述流程实例对应的流程补偿策略。

可选的，所述流程补偿策略集包括多种流程定义对应的流程补偿策略集；流程补偿处理模块在从流程补偿策略集中确定所述流程实例对应的流程补偿策略时可以用于：

确定所述流程实例对应的流程标识，所述流程标识对应一种流程定义；

根据所述当前执行状态，从所述流程标识对应的流程补偿策略集中确定所述流程实例对应的流程补偿策略。

可选的，对于各服务节点中的最后一个服务节点，服务节点的事务操作执行异常为：服务节点的事务操作执行失败；

对于除最后一个服务节点之外的各服务节点，服务节点的事务操作执行异常包括：服务节点的事务操作执行失败，或服务节点对应的执行状态更新失败。

可选的，所述分布式事务对应的各服务节点的事务操作执行流程为同步执行流程；

若所述流程实例的当前执行状态为最后一个服务节点的上一个服务节点的事务操作执行成功，所述流程实例对应的流程补偿策略包括：再次执行最后一个服务节点的事务操作；

若所述流程实例的当前执行状态为第一节点的事务操作执行成功或初始化状态，所述流程实例对应的流程补偿策略包括：执行事务回滚操作；

其中，所述第一节点是除最后一个服务节点的上一个服务节点之外的服务节点。

可选的，所述分布式事务对应的各服务节点的事务操作执行流程为异步执行流程；所述至少两个服务节点包括至少一个消息服务节点，所述消息服务节点对应的事务操作为：将该消息服务节点的下一个服务节点的事务操作写入消息队列中，其中，所述消息队列中的事务操作由该消息服务节点的下一个服务节点异步读取并执行；

若所述流程实例的当前执行状态为消息服务节点的事务操作执行成功，所述流程实例对应的流程补偿策略包括：

将该消息服务节点的下一个服务节点的事务操作写入补偿处理队列中，其中，所述补偿补偿队列中事务操作在满足执行条件时被再次执行，若一个事务操作的重试次数达到设定次数且重试未成功，将该流程实例写入指定队列中；

若所述流程实例的当前执行状态为初始化状态或第二节点的事务操作执行成功，所述第二节点是所有消息服务节点之前的节点，所述流程实例对应的流程补偿策略包括：执行事务回滚操作。

另一方面，本公开实施例还提供了一种电子设备，该电子设备包括存储器和处理器，存储器中存储有计算机程序，处理器执行该计算机程序以实现本公开任一可选实施例中提供的方法。

另一方面，本公开实施例还提供了一种计算机可读存储介质，该存储介质中存储有计算机程序，该计算机程序被处理器执行时实现本公开任一可选实施例中提供的方法。

另一方面，本公开实施例还提供了一种计算机程序产品，该计算机产品包括计算机程序，该计算机程序被处理器执行时实现本公开任一可选实施例中提供的方法。

本公开实施例提供的技术方案带来的有益效果如下：

本公开实施例提供的分布式事务处理方法，在通过分布式事务对应的各个服务节点(即流程实例对应的各服务间)对分布式事务进行处理的过程中，会根据服务节点的事务操作执行结果，动态更新记录流程的执行状态，在事务执行出现异常时，可以根据流程的当前执行状态从流程补偿策略中确定出相匹配的补偿策略，实现对分布式事务的流程补偿。基于该方案，在实际实施时，可以根据业务需求，按照事务对应的执行流程配置事务执行过程中的各种执行状态对应的流程补偿策略，一旦出现流程执行异常，即可根据流程的当前执行状态对流程进行即时补偿，可以更好的保障分布式事务处理的各个操作环节的数据一致性。此外，本公开的该方法在应用于业务系统时，不会对系统已有的业务实现逻辑有过多侵入，可以无需对系统架构进行较大改动，部署实现简单，能够更好的满足各种业务场景下的分布式事务的业务需求。

附图说明

为了更清楚地说明本公开实施例中的技术方案，下面将对本公开实施例描述中所需要使用的附图作简单地介绍。

图1为本公开实施例所适用的一种实施环境的系统结构示意图；

图2为本公开实施例提供的一种分布式事务处理方法的流程示意图；

图3为本公开实施例所适用的一种可选的分布式业务系统的结构示意图；

图4为本公开实施例提供的一种应用场景中的用户界面的示意图；

图5a为本公开的场景实施例中提供的一种分布式事务的处理方法的流程示意图；

图5b为图5a中所示的分布式事务处理方案的各流程状态的示意图；

图6为本公开的场景实施例中提供的一种分布式事务的处理方法的流程示意图；

图7为图6中所示的分布式事务处理方案的各流程状态的示意图；

图8和图9为本公开实施例提供的一种分布式事务处理方案的系统架构示意图；

图10为本公开实施例提供的一种分布式事务处理装置的结构示意图；

图11为本公开实施例提供的一种电子设备的结构示意图。

具体实施方式

下面结合本公开中的附图描述本公开的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本公开实施例的技术方案的示例性描述，对本公开实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本公开实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”可以实现为“A”，或者实现为“B”，或者实现为“A和B”。在描述多个(两个或两个以上)项目时，如果没有明确限定多个项目之间的关系，这多个项目之间可以是指多个项目中的一个、多个或者全部，例如，对于“参数A包括A1、A2、A3”的描述，可以实现为参数A包括A1或A2或A3，还可以实现为参数A包括参数A1、A2、A3这三项中的至少两项。

本公开实施例提供了一种能够更好的满足实际应用需求的分布式事务处理方案，基于该方案，可以更好的保障系统的原子性。可选的，该处理方案还具备一定的容灾能力，可以提高事务的处理成功率。采用本公开实施例提供的方案，能够有效提升使用感知，可更好的满足不同业务场景下的分布式事务的处理需求。

可选的，本公开实施例提供的方案可涉及云技术，例如，本公开实施例中的业务服务器或服务节点可以是云服务器，其中所涉及的数据处理可基于云技术实现，实施例中所涉及的数据存储可以采用云存储的方案。

其中，云技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。而云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

下面通过对几个示例性实施方式的描述，对本公开实施例的技术方案以及本公开的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。

需要说明的是，在本公开的可选实施例中，所涉及到的对象信息(如游戏玩家的游戏账号信息、玩家已领取的虚拟资源的记录信息等)等相关的数据，当本公开中的实施例运用到具体产品或技术中时，需要获得对象许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。也就是说，本公开实施例中如果涉及到与对象有关的数据，需要经由对象授权同意、相关部门授权同意、且符合国家和地区的相关法律法规和标准的情况下获取的。实施例中如涉及个人信息，所有个人信息的获取需要获得个人的同意，如涉及到敏感信息，需要征得信息主体的单独同意，实施例也是需要在对象授权同意的情况下实施。

本公开实施例提供的分布式事务处理方法，理论上可以适用于各种分布式事务的业务处理场景中，可选的，图1示出了本公开实施例所适用的一种实施环境的系统结构示意图，如图1所示，该实施环境可以包括用户终端101和服务器102，其中，服务器102可以是任一应用的应用服务器(也可称为业务服务器)，终端101和服务器102可以通过网络通信连接，服务器102可以接收终端101发送的业务请求，服务器102可以对该业务请求进行处理，并将处理结果反馈给终端101。可选的，本公开实施例中，服务器102接收到的终端101业务请求是分布式事务的业务请求时，服务器102可以通过执行本公开实施例提供的该方法对分布式事务进行处理，或者服务器102可以通过调用与其通信连接的托管服务器，由托管服务器通过执行本公开实施例提供的该方法进行处理。具体的场景实施例将在后文中结合图3所示的业务系统进行详细说明。

图2示出了本公开实施例提供的一种分布式事务处理方法的流程示意图，其中，该方法可以由任意计算机设备执行，可选的，可以由服务器执行，该服务器可以通过本公开实施例提供的方案，对终端的业务处理请求所对应的分布式事务进行处理，并在处理流程出现异常时，可以执行相应的流程补偿操作，以更好的保障事务的处理结果。

其中，上述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端(也可以称为用户终端或用户设备)可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能语音交互设备(例如智能音箱)、可穿戴电子设备(例如智能手表)、车载终端、智能家电(例如智能电视)、AR/VR设备等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本公开在此不做限制。

如图2所示，本公开实施例提供的分布式事务处理方法可以包括以下步骤：

步骤S110：获取待处理的分布式事务，生成分布式事务对应的流程实例。

步骤S120：基于流程实例，依次通过流程实例对应的至少两个服务节点中的各节点执行第一操作，直至流程实例执行成功，或者任一当前服务节点的事务操作执行异常。

其中，上述第一操作包括：通过当前服务节点执行该服务节点对应的事务操作，若执行成功，将流程实例的执行状态更新为该服务节点的事务操作执行成功。

可以理解的是，在实际应用中，流程实例能够成功执行的流程中所涉及的每种执行状态可以有各自对应的状态标识，在流程实例过程中，流程实例当前的执行状态可以采用相应的状态标识进行标记。

步骤S130：若出现当前服务节点的事务操作执行异常的情况，则根据流程实例的当前执行状态，从流程补偿策略集中确定出流程实例对应的流程补偿策略。

步骤S140：根据流程实例对应的流程补偿策略，对流程实例执行对应的流程补偿操作。

其中，上述流程补偿策略集中包括各种流程实例执行状态所对应的流程补偿策略。

在分布式系统中，一次事务操作涉及多个系统(服务节点)通过网络协同完成的过程称为分布式事务，也就是说，分布式事务对应至少两个服务节点。例如，在电商系统中的下单扣库存的业务场景中，一次下单操作需要由订单系统的服务器和库存系统的服务器协同完成，该示例中的下单操作则为分布式事务，订单系统的服务器和库存系统的服务器为该事务的两个服务节点。再比如，在一些游戏应用中，会经常涉及虚拟资源(如虚拟游戏道具)的发放，但虚拟资源的领取通常都是有领取条件限制的，玩家可以在游戏应用的用户界面上触发领取虚拟资源的操作，游戏服务器接收到玩家的领取请求之后，会生成一个对应的虚拟资源发放事务，在执行该事务时，需要先判断是否满足领取条件，如果满足才会进行虚拟资源的发放，该示例中，虚拟资源发放事务可以是一个分布式事务，该事务可以由限量服务节点和资源发放服务节点协同完成，限量服务节点判断是否满足领取条件，资源发放服务节点用于执行资源的发放。

本公开实施例提供的分布式事务处理方法，理论上可以适用于各种分布式事务的业务处理场景中，可以应用于包括但不限于游戏运营、平台运营等需要发放虚拟资源的业务场景中。执行该分布式事务处理方法的服务器可以是分布式事务的业务服务器(如游戏应用的业务服务器)，也可以是独立于业务服务器的服务器(可称为托管服务器)。该服务器在获取到待处理的分布式事务之后，可以生成该事务对应的流程实例，基于该流程实例可以依次通过该分布式事务对应的各个服务节点来执行各节点对应的事务操作。

其中，一个分布式事务对应的流程实例(Process Instance)代表了该事务所对应的流程定义的执行实例，流程定义是完成一个具体流程的设计与配置，即，流程定义是定义了一项事务应该如何处理的全部流程，比如，应该调用哪些服务节点、如何调用、每个节点需要执行的事务操作是什么、服务节点之间的调用顺序等等。一个流程实例可以包括流程实例标识(流程实例ID)和流程实例内容，流程实例ID是一个流程实例的唯一标识，相应的也可以是一个分布式事务的唯一标识。

以上述游戏应用中的虚拟资源发放业务为例，该业务的流程定义是业务人员根据实际业务需求预先配置好的业务执行流程(包括各个执行步骤以及步骤之间的关系)，当游戏应用的业务服务器每接收到一个玩家的虚拟资源领取请求，会根据该业务的流程定义，生成一个流程实例，如果一个流程实例执行成功，该流程实例对应的玩家就会获取到对应的虚拟资源。

由于流程实例是包括了分布式事务的事务执行流程的相关内容的，因此，基于流程实例是可以确定各服务节点的事务操作的执行顺序的，如上述虚拟资源发放事务，需要先通过限量服务节点执行限量服务，如判断是否满足领取条件，在限量服务执行成功时，再通过虚拟资源发放节点执行虚拟资源发放操作。

需要说明的是，在实际应用中，上述所描述的流程实例对应的至少两个服务节点可以是分布式事务对应的所有服务节点，也可以是所有服务节点中的部分节点，是可以根据实际应用需求预配置的。比如，一项分布式事务对应5个节点，前2个节点所执行的操作是不涉及到业务数据的修改的，后3个节点所执行的事务操作是涉及到业务数据的修改的，该示例中上述至少两个服务节点可以是指后三个服务节点，可选的，前2个节点可以由业务服务器调度，后3个节点可以用托管服务器调度。

本公开实施例中，在依次通过该流程对应的各服务节点执行各节点各自对应的事务操作时，如果当前服务节点的事务操作的执行结果为执行成功时，则会随时更新并记录流程实例当前的执行状态，即将执行状态更新为当前服务节点对应的事务操作执行成功的状态(比如，对于上述限量服务节点，执行状态可以更新为限量成功)，基于此，如果在流程实例执行过程中，任一当前服务节点的事务操作执行异常，正常的流程实例执行流程会中断，此时则可以根据记录的流程实例的当前执行状态，确定相应的流程补偿策略，对执行出现异常的流程实例进行相应的即时流程补偿。

其中，各种不同的执行状态的流程补偿策略可以根据实际的业务应用场景和业务需求进行预配置，从而使得流程实例执行出现异常时，可以根据流程实例出现异常时的当前执行状态，自动执行与该执行状态相匹配的流程补偿操作，使得事务的处理结果能够更好的满足实际应用需求。

可选的，上述流程补偿策略可以包括但不限于事务回滚操作或再次执行出现异常的服务节点的事务操作。其中，事务回滚操作是指对已经执行的事务操作进行回滚，即撤销已执行的事务操作，保证分布式系统中事务处理的原子性，或者，也可以通过再次执行出现异常的事务操作实现流程补偿。

在实际的业务应用中，经常会有多种不同的业务，如游戏应用中，虚拟资源发放业务就可能有多种不同的具体业务，如多种类型的虚拟资源的发放，而不同的业务对应的流程定义即业务的执行流程以及实际的业务需求都很有可能是不同的，为了可以满足各种类型的业务需求，本公开的一可选方案中，上述流程补偿策略集可以包括多种流程定义对应的流程补偿策略集；上述根据流程实例的当前执行状态，从流程补偿策略集中确定出流程实例对应的流程补偿策略，包括：

确定流程实例对应的流程标识，流程标识对应一种流程定义；

根据当前执行状态，从流程标识对应的流程补偿策略集中确定流程实例对应的流程补偿策略。

不同的流程定义代表了不同的业务处理流程，基于该可选方案，可以根据实际业务需求配置每种流程定义各自对应的流程补偿策略，在一个流程实例对应的任一服务节点出现事务操作执行异常时，则可以根据该流程实例的流程标识，从该流程标识对应的补偿策略集中确定出相对应的流程补偿策略。其中，一个流程标识对应一种流程定义，对于流程标识的标识形式本公开实施例不做限定。

可选的，上述根据流程实例的当前执行状态，从流程补偿策略集中确定出流程实例对应的流程补偿策略，可以包括：

根据流程实例的实例标识和当前执行状态，生成流程实例对应的流程补偿事件；

确定流程实例对应的流程标识，流程标识对应一种流程定义；

根据流程标识，从预配置的各流程补偿队列中确定出流程实例对应的目标流程补偿队列，其中，每个流程补偿队列对应一种流程定义；

将流程实例对应的流程补偿事件分发到目标流程补偿队列；

对各流程补偿队列中的流程补偿事件进行处理，在到达目标流程补偿队列中流程实例对应的流程补偿事件的处理时机时，根据流程补偿事件对应的当前执行状态，从流程补偿策略集中确定出流程实例对应的流程补偿策略。

该可选方案中，可以为每种流程定义维护一个相应的流程补偿队列，该队列用于存储相应的流程定义所对应的流程补偿事件，采用该方案，可以对各种流程定义对应的流程补偿事件进行并行处理，每个队列可以对应一个或多个线程，每个队列中的流程补偿事件可以由该队列对应的各个线程进行并行处理，不同队列中的流程补偿事件也可以实现并行处理，从而可以有效提高流程补偿操作的执行效率。

其中，一个流程实例对应的流程补偿事件的处理时机，可以根据与配置的策略生成，可选的，对于每个流程补偿队列，可以按照先进先出的原则对处理事件可以该队列中所存储的各流程实例对应的流程补偿事件进行处理，一个流程实例对应的流程补偿事件的处理时机，则可以是达到该事件的处理顺序，对于每个流程补偿队列中的每个流程补偿事件，在到达该事件的处理时机时，则可以根据该事件对应的当前执行状态确定出相匹配的流程补偿策略，并根据确定出的流程补偿策略执行相应的流程补偿操作，如可以根据该事件对应的当前执行状态，从该事件所对应目标策略集(事件对应的流程标识对应的流程补偿策略集)中确定出匹配的补偿策略，也就是说，每个流程补偿队列可以对应各自的流程补偿策略集，一个队列对应的补偿策略集中包含的是该队列所对应的流程定义下的所有流程实例的各种流程实例执行状态的流程补偿策略。

本公开的可选实施例中，在生成流程实例之后，该方法还包括：

将流程实例的实例标识存储到未完成流程实例队列中；

若流程实例执行成功，则将流程实例的实例标识从未完成流程实例队列删除；

若流程实例对应的流程补偿操作执行失败，该分布式事务处理方法还可以包括：

响应于满足流程实例的延时补偿触发条件，再次对流程实例执行对应的流程补偿操作；

若流程补偿操作重试成功，则继续执行所述流程实例。

对于补偿失败的流程实例，本公开的该方案中提供了一种延时补偿的处理方式，该方案中，分布式系统可以维护一个未完成流程实例队列，分布式事务对应的流程实例生成之后，会将流程实例的实例ID写入到该队列，即写入到该队列中的流程实例为未执行完成的流程实例，该队列记录了哪些流程实例尚未执行成功。在流程实例执行成功时，会将执行成功的流程实例的实例标识从该队列中删除。若流程实例在执行过程中出现异常，则会对流程实例执行流程补偿操作，如果补偿操作执行成功则可以继续执行该流程实例的后续操作，如果流程实例执行成功则将该流程实例的实例ID从未完成流程实例队列中删除。在对流程实例执行补偿操作时，如果补偿操作未执行成功，可以按照预配置的策略再次执行该补偿操作，该可选方案为分布式事务的处理提供了一定的容灾能力，当某个服务节点执行出现异常时，可以再次尝试对流程实例执行对应的流程补偿操作，可以进一步提升分布式事务处理的成功率。

其中，流程实例对应的延时补偿触发条件的具体条件内容，可以根据实际应用需求配置，可以按照预配置好的延时处理策略确定流程实例对应的触发条件。作为一可选方案，延时补偿触发条件可以包括相邻两次流程补偿操作之间的延时时间，例如，当流程实例对应的流程补偿操作第一次执行失败(即时补偿失败)时，可以接着重试，即第一次重试为0延时，如果第一次重试失败，可以1分钟之后再重试，如果还失败，可以3分钟之后再重试。

需要说明的是，在实际应用中，对流程实例执行延时补偿处理的次数(即重试次数)可以是一次，也可以是多次，也可以是不断重试，直至执行成功，以保证未完成的流程可以得到最终补偿。相应的，上述流程实例对应的流程补偿操作执行失败，可以是第一次执行失败，也可以是重试执行失败。

作为一可选方案，若流程实例对应的流程补偿操作执行失败，该方法还包括：

确定流程实例对应的延时补偿时间戳；

若延时补偿时间戳对应的时间到达，确定满足流程实例的延时补偿触发条件；

若流程补偿操作重试失败，更新未完成流程实例队列中存储的流程实例的延时补偿时间戳。

本公开的该可选方案给出了一种基于时间戳的延时补偿方式，延时补偿时间戳的具体生成和更新方式本公开实施例不做限定，可以根据应用需求配置，不同业务场景对应的时间戳的生成和更新方式可以不同。比如，可以以流程实例对应的流程补偿操作执行失败的时间为基准，在该时间上增加设定时长，得到延时补偿时间戳，在达到该时间戳时，则可以对该流程实例再次执行其对应的流程补偿操作，如果重试失败，可以在该时间戳的基础上再次增加设定时长，得到新的延时补偿时间戳。基于该可选方案，如果流程实例对应的延时补偿时间戳达到，可以再次对该流程实例执行流程补偿操作。

可选的，流程实例可以预配置相应的设定次数，该次数为流程补偿操作的最大重试次数，其中，若流程补偿操作的重试次数达到设定次数且流程补偿操作执行失败，该方法还包括：

根据当前执行状态，执行事务回滚操作或者将流程实例写入指定队列。

在配置了流程补偿操作的最大重试次数，上述流程补偿策略的重试次数达到最大重试次数但仍执行失败时，可以通过执行事务回滚操作，以更好的保障事务处理的原子性。可选的，也可以是将流程实例存储到指定队列中，后续可以人工干预该流程实例的相关处理。

可选的，本公开实施例的该方法还可以包括：对未完成流程实例队列进行轮询操作，若未完成流程实例队列中存在存储时长达到设定时长的实例标识，则根据该实例标识对应的流程实例执行状态，执行对应的流程补偿操作。

该可选方案中，可以维护一个守护进程轮询未完成流程实例队列，若存在超过设定时长(可根据实际需求配置和修改，如5分钟)的流程，则进行再次补偿。因为只有在流程实例执行成功时才会将流程实例的实例ID从未完成流程实例队列中删除，采用该可选方案，可以保证未完成的流程可以得到最终补偿。

可见，在实际实施时，延时补偿机制可以包含两个策略：1.对于即时补偿失败的情况，可以设置多次补偿重试；2.有一个守护进程轮询未完成队列，若存在超过5分钟(可配置)的流程，则进行再次补偿。两种策略可以同时存在。

本公开实施例提供的分布式事务处理方法，可以根据分布式事务操作中相互依赖的操作行为进行关联处理，具体的，可以根据分布式事务对应的各服务节点的事务操作的执行情况，在执行成功时会及时记录并更新流程实例处理过程中流程实例的执行，在某个节点执行出现异常时，便可以根据当前的最新执行状态执行相对应的流程补偿操作，基于该方式，可以最大可能的保障事务的原子性，另外，由于各种状态所对应的流程补偿策略是可以根据业务需求进行配置的，因此，可以根据实际需求配置各种业务类型在事务执行出现各种异常时的补偿策略，能够满足各种业务场景下的业务需求。

可选的，本公开的方法还可以包括：

获取流程补偿策略的更新请求，该请求中可以包括至少一个流程实例执行状态和每个执行状态对应的流程补偿策略；

根据上述更新请求，对流程补偿策略集进行更新。

采用该方案，可以根据业务需要对各种状态出现异常时的流程补偿策略进行调整。

目前，分布式事务的处理流程可以是同步执行流程，也可以是异步执行流程，对于同步执行流程，在依次通过各服务节点执行对应的事务操作时，需要等待各服务节点的执行结果，而异步执行流程中可以基于消息队列进行异步处理，当前服务节点可以无需等待后续服务节点的执行结果。

本公开实施例提供的方法，可以适用于同步业务处理场景，也适用于异步业务处理场景。其中，若分布式事务对应的各服务节点的事务操作执行流程为同步执行流程；可选的，在流程实例的当前执行状态为最后一个服务节点的上一个服务节点的事务操作执行成功(也就是最后一个服务节点的事务操作执行失败)时，流程实例对应的流程补偿策略可以包括：再次执行最后一个服务节点的事务操作。

可选的，对于同步执行流程，若流程实例的当前执行状态为第一节点的事务操作执行成功或初始化状态，流程实例对应的流程补偿策略包括：执行事务回滚操作；其中，第一节点是除最后一个服务节点的上一个服务节点之外的服务节点。

也就是说，在同步执行场景中，如果事务操作执行出现异常的节点是最后一个服务节点，可以通过再次执行最后一个服务节点对应的事务操作的流程补偿方式，提高事务执行的成功率，可选的，可以设置重试的最大次数，如果重试次数达到该最大次数，可以执行回滚操作即撤销已经执行的操作，以更好的保障事务的原子性。可选的，如果事务操作执行出现异常的节点不是最后一个服务节点，可以直接执行回滚操作。

在分布式事务对应的各服务节点的事务操作执行流程为异步执行流程时，至少两个服务节点包括至少一个消息服务节点，消息服务节点对应的事务操作为：将该消息服务节点的下一个服务节点的事务操作写入消息队列中，其中，消息队列中的事务操作由该消息服务节点的下一个服务节点异步读取并执行；

若流程实例的当前执行状态为消息服务节点的事务操作执行成功，流程实例对应的流程补偿策略包括：

将该消息服务节点的下一个服务节点的事务操作写入补偿处理队列中，其中，补偿补偿队列中事务操作在满足执行条件时被再次执行，若一个事务操作的重试次数达到设定次数且重试未成功，将流程实例写入指定队列中；

若流程实例的当前执行状态为初始化状态或第二节点的事务操作执行成功，第二节点是所有消息服务节点之前的节点，流程实例对应的流程补偿策略包括：执行事务回滚操作。

对于异步执行流程的该可选方案中，根据业务需求，服务节点中可以有一个或多个消息服务节点，消息服务节点是用于在其上一个服务节点的事务操作的执行状态为执行成功时，将其下一个服务节点的事务操作写入到一个消息队列中，该消息服务节点的下一个服务节点通过消费该消息队列来异步执行其所要执行的事务操作。采用该方案，在流程实例的执行过程中，消息服务队列之前的服务节点在其事务操作执行成功并流程状态更新成功时，服务器即可向分布式事务对应的请求方返回执行成功的执行结果，而无需一直等待后续服务节点的执行。

作为一个示例，对于上述游戏应用中的虚拟资源的发放事务，在采用异步实现方式时，该事务对应的至少两个服务节点可以包括一个限量服务节点一个消息服务节点一个资源发放节点，限量服务节点在执行限量操作成功并更新状态成功时，消息服务节点将资源发放节点需要执行的资源发放操作写入到资源发放节点对应的消息队列中，资源发放节点可以通过读取该消息队列来异步执行资源发放操作。在该场景中，在消息服务队列完成消息队列的写操作之后，就可以向发起虚拟资源领取操作的客户端，返回领取成功的提示信息，可有效提升用户的使用感知。

要说明的是，在实际应用中，消息服务节点的事务操作的执行状态可以是默认是执行成功的，也就是说，事物操作执行异常的情况可以仅发生在除消息服务节点之外的节点，这是因为消息服务节点所要执行的事务操作就是写操作，该操作通过一次或多次尝试总归是能够成功的，所以可以无需为该节点的配置，相应的流程补偿策略，当然也可以配置，该节点的事务操作的执行失时，补偿策略可以是再次执行直至执行成功。

在流程实例的执行过程发生异常情况，若流程实例的当前执行状态为消息服务节点的事务操作执行成功，说明异常是发生在消息服务节点的下一个服务节点，补偿策略可以是该消息服务节点下一个服务节点的事务操作写作到补偿处理队列中，通过再次执行该补偿队列中的事务操作对执行出现异常的流程实现补偿。如果异常是发生在所有消息服务节点之前的第二节点，即异常时流程实例的当前执行状态是初始化的状态或者是第二节点的事务操作执行成功的状态，此时没有向客户端反馈执行成功的结果，可以通过执行事务回滚操作来取消已经执行的所有操作，当然，如果此时没有执行实质性的操作(比如当前执行状态是初始化状态)，回滚操作可以是空回滚操作。

仍以上述虚拟资源发放事务为例，如果流程实例的事物操作执行异常的情况是发生在资源发放节点，则可以通过一次或多次(即设定次数)重新执行资源发放操作实现流程补偿。

本公开实施例提供的方案，可以适用于各种采用分布式系统架构且对于分布式事务的处理结果有原子性要求的应该场景中。比如，该方案可以应用于游戏运营、平台运营等业务场景中，为了提升玩家的游戏感知，这些业务场景下经常会涉及各种各样的虚拟资源发放(可称为发货)，如游戏道具、游戏礼包等等，在该种场景下，想要实现精准发货往往会面临两个问题：1)大部分虚拟资源都不支持回滚，一旦发出难以回收；2)虚拟资源类型多样，发货失败原因多样，有的可以补发，有的无法补发。目前传统的分布式事务方案不能解决所有的问题，而基于本公开实施例提出了分布式事务方案，可以通过可配置的流程补偿引擎支持各种类型虚拟资源的精准发放和补偿。

为了更好的理解和说明本公开实施例提供的方案和实用价值，下面结合一个具体的实施场景对本公开实施例的可选实施方案进行说明。本场景实施例中，以将本公开提供的方法应用于游戏应用中虚拟资源的发放场景为例，对于游戏应用的类型本公开实施例不做限定。

在虚拟资源的发放场景中，基于本公开实施例提供的方案，可以把虚拟资源发放流程中相互依赖的操作行为进行关联处理，可以实现流程处理中要不全部操作执行成功，要不一旦有操作行为失败，整个事务将失败，保证了事务处理的原子性。

可选的，本公开实施例提供的分布式事务处理方法可以实现为应用程序的功能插件，也可称为流程托管引擎，其中，该流程应用引擎可以部署在应用程序(如游戏应用)的应用服务器即业务服务器中，也可以部署于单独的电子设备(如流程托管服务器)中，业务服务器或电子设备通过运行该引擎实现本公开实施例的方法。

图3示出了本公开实施例所适用的一种业务系统的结构示意图，如图3所示，该业务系统可以包括用户终端10、业务服务器20和流程托管服务器30以及服务节点，对应于上述游戏中虚拟资源发放的业务场景中，用户终端10可以是游戏玩家的用户终端，其上可以运行有目标游戏应用，业务服务器20为目标游戏应用的游戏服务器，可以为玩家提供游戏服务，玩家还可以在玩游戏的过程中领取所发放的虚拟资源，如虚拟道具或虚拟游戏礼包。可选的，对于游戏中虚拟资源的发放可以由流程托管服务器30，业务服务器20在接收到玩家通过其用户终端10发送的虚拟资源领取请求时，可以将该请求交由流程托管服务器30执行，流程托管服务器30可以调用领取请求所对应的各服务节点对该请求对应的事务操作进行处理，并将处理结果反馈给业务服务器20，如果处理成功，则把所请求的虚拟资源发放给对应的玩家，如将虚拟资源发放到玩家账号对应的虚拟资源中心中，如个人礼包中心，玩家可以在此查看其具有的虚拟资源的详情。

其中，服务节点为分布式事务的事务执行节点，分布式事务包括至少两项事务操作，每个服务节点可以执行一项事务操作，服务节点也可以称为被调服务端，业务托管服务器30通过调用待处理事务对应的各服务节点来执行各节点对应的事务操作，只有在各服务节点对应的事务操作均执行成功时，分布式事务的处理结果才能算是成功。图3中仅示意性的示出了两个服务节点，即服务节点41和服务节点42，可以理解的是，对于不同的应用场景，分布式事务对应的服务节点可能不止两个。

本场景实施例中，虚拟资源的发放事务可以包括两项事务操作，一项是限量操作，一项是虚拟资源发放操作，其中，限量操作是根据预配置的虚拟资源领取限制条件，判断虚拟资源领取请求是否满足领取条件，如果满足才可以领取，否则不能领取，比如，虚拟资源的领取限制条件为一个游戏账号只能领取一次，如果一个玩家已经领取过一次，该玩家再次进行领取时，则其领取请求是不满足领取条件的，可以直接向用户终端反馈领取失败提示信息。虚拟资源发放操作也可称为发货操作，是在限量操作执行成功之后，即领取请求满足领取条件时，发放领取请求对应的虚拟资源。

本公开实施例提供的方案，既可以适用于分布式事务的同步处理场景中，也适用于分布式事务的异步处理场景中。

为了描述方便，在本场景实施例中，虚拟资源将以虚拟礼包为例，将图3中的服务节点41和服务节点42分别作为限量操作和虚拟资源发放操作对应的服务节点，即服务节点41提供的是限量服务，服务节点42提供的是资源发送服务即虚拟礼包的发放(可简称为发货)。下面结合图3中所示的系统结构，对本场景实施例中的分布式事务(虚拟资源发放事务)的处理方案进行说明。

作为一个示例，图4中示出了一个游戏玩家的用户终端10上所显示的游戏应用的应用界面的示意图，该应用界面上显示有虚拟礼包领取控件，如图4中所示的“一键领取”的控件，玩家可以通过点击该控件来领取虚拟礼包，可选的，玩家在点击了该控件之后，可以在用户终端上显示相应的提示信息，如图4所示，可以提示玩家是否确定要领取，当前的领取账号(如游戏账号)是否“abc”，用户终端在接收到玩家的确认操作之后，将礼包领取请求发送给业务服务器20，业务服务器20接收到该请求之后，可以将该请求对应的虚拟礼包发放事务(待处理的分布式事务)发送给流程托管服务器30，流程托管服务器30通过执行本公开实施例提供的方案，对礼包发放事务进行处理，业务托管服务器30可以将事务处理结果通过业务服务器20发送给用户终端，以告知玩家，其中，如果事务处理成功(即礼包领取成功)，礼包领取请求对应的虚拟礼包将被发放给对应玩家，可以将领取成功的通知信息通过用户终端展示给玩家，如图4所示，可以在终端的用户界面上显示“成功领取1个礼包”的提示信息，可选的，该界面上还可以显示有礼包查看控件(如图4中的“查看详情”控件)、游戏触发控件(“进入游戏”控件)、领取结果分享控件等等，玩家通过点击礼包查看控件，可以查看礼包中所包含的虚拟资源的详情，点击游戏触发控件可以快速开启游戏，点击分享控件可以礼包领取成功的信息进行分享。

其中，在实际应用中，虚拟资源的发货场景可以是同步发货场景，也可以是异步发货场景。下面分别对同步发货场景中的礼包发货事务的处理流程和异步发货场景中的礼包发货事务的处理流程进行说明。

对于上述礼包发放的业务场景，业务服务器20在接收到用户终端10发送的礼包领取请求之后，可以将该请求(即待处理的礼包发放事务)托管给业务托管服务器30进行处理，其中，该请求中可以包括请求对应的业务标识和请求方标识(如玩家的游戏账号)，业务标识可以指示当前的礼包领取请求是具体是何种礼包的领取请求，其中，如果业务服务器可以通过提供多种不同的业务服务，该业务标识还可以指示当前的请求是哪种业务中的礼包领取请求，例如，业务服务器是云游戏服务器，该服务器可以提供多种不同游戏，礼包领取请求中可以带有指示该请求是哪个玩家对哪个游戏中的何种礼包的领取请求的标识，业务托管服务器30在接收到业务服务器20发送的礼包发放事务之后，可以根据预配置好的该事务的处理流程，生成该事务对应的流程实例(流程实例代表流程定义的执行实例，也就是按照流程定义内容发起的一个执行实例，对于礼包发放业务，流程定义定义了礼包发放的各个步骤，一个流程定义可以启动多个流程实例，该业务的一个流程实例则代表了一个具体的礼包发放事务)。

一个流程实例可以包括流程实例标识(流程实例ID)和流程实例内容，流程实例标识是流程实例的唯一标识，可以唯一的标识一个事务，流程实例内容中包含与该事务的执行流程相关的信息，如事务的执行要调用哪些服务节点、如何调用各服务节点、具体要执行哪些步骤等等，根据流程实例内容，流程托管服务器30通过调用相应的服务节点执行相应的事务操作。

图5a示出了本公开实施例提供的一种同步发货场景下的分布式事务的执行流程的示意图，该示意图中，业务托管服务器30可以包括控制器(或处理器)和流程状态引擎，其中，控制器可以执行分布式事务处理过程中的各个步骤，流程状态引擎可以用于记录并更新流程实例中的流程状态(流程实例的执行状态)，在流程实例的执行前向动作出现异常时，即某个服务节点的事务操作执行出现异常时，则可以根据所记录的流程实例的当前执行状态进行补偿操作。

对于同步发货场景，图5a中示出了流程托管服务器30的控制器执行礼包领取事务对应的流程实例的流程示意图，该流程可以包括如下步骤：

步骤1:初始化流程，如果成功进入下一步，如果失败或结果不可知返回失败；

要启动流程实例，需要先初始化流程，以提供一些初始化流程变量，流程实例可以具有一个初始的预设状态，如果流程初始化成功，可以通过流程状态引擎记录并更新流程实例的当前状态是初始化成功(如流程状态可以记为准备prepare状态)，如果初始化不成功(包括初始化失败或者是结果不可知，如一定时长内未得到初始化结果)，则可以无需执行后续步骤。

步骤2:执行限量，如果成功进入下一步，如果失败或结果不可知返回失败；

该步骤中，控制器根据流程实例内容，调用提供限量服务的服务节点41执行限量操作(节点41对应的事务操作)，例如，服务节点41判断流程实例是否满足礼包领取限制条件，比如每个游戏账号只能领取一次，如果该流程实例对应的游戏账号已经领取过一次，则不满足条件，限量失败，如果满足条件，限量成功。其中，如果控制器在一定时长内都没有接收到服务节点41反馈的限量操作的执行结果，此时结果不可知也认为是限量失败，限量操作执行异常，流程实例的当前状态为prepare状态。

步骤3:更新流程状态为限量成功，如果成功进入下一步，如果失败或结果不可知返回失败；

在限量成功(控制器接收到了服务节点42发送的限量成功的反馈信息)时，流程状态引擎可以更新流程实例的执行状态为限量成功，如果更新状态不成功，限量操作执行异常，流程实例的当前状态仍是prepare状态。

步骤4:执行发货，如果执行成功进入下一步，如果失败返回失败，如果结果不可知返回失败；

在流程的当前状态更新为限量成功后，控制器根据流程实例内容，调用提供发货服务的服务节点42执行发货操作(服务节点42对应的事务操作)，将礼包发放给发送礼包领取请求的请求方，如果发货失败则发货操作的执行出现异常，此时流程实例的执行状态仍为限量成功状态。

step 5:更新流程状态为发货成功，如果成功返回成功，如果失败或结果不可知也返回成功。

在发货成功时，流程状态引擎可以更新流程实例的当前状态为发货成功，因为服务节点42是礼包领取事务的最后一个服务节点，在该节点的事务操作执行成功时，即便是流程状态更新未成功，也仍可以认为是事务执行成功。

至此，一个同步发货场景下的流程实例执行结束，由上述执行流程可以看出，只有在各服务节点的事务操作的执行结果都是执行成功时，礼包发放事务才算执行成功，如果有一个服务节点的事务操作执行失败，那么整个事务则失败。

在礼包发放事务的某个操作执行失败时，基于本公开实施例提供的分布式事务处理方案，可以采用相应的补偿策略，对该事务对应的流程实例进行补偿即执行流程补偿操作，以使得事务处理成功或者将事务回滚，以保证事务处理的原子性(要不整个事务完整的被执行，要么完全不执行)。

可选的，本公开实施例提供的方案，在事务的流程补偿操作执行失败时，还可以进入重试流程，使得分布式事务的处理方案具备了一定的容灾能够力，使得当某个节点失败时，可以通过再次尝试执行该节点对应的事务操作，提高事务处理成功的概率，对于上述礼包发送事务而言，可以提高礼包发放的成功率，减少符合条件的玩家礼包领取礼包失败的情况的出现，提升游戏玩家的体验，。

对于上述礼包发放事务的同步处理流程，图5b示出了本公开实施例提供的一种分布式事务的补偿机制的原理示意图，如图5b所示，礼包同步发货的执行流程可以对应有3种流程状态，分别是准备状态(对应初始化流程)、限量成功状态(对应限量操作)和发货成功状态，如果在流程实例的执行过程中，出现限量失败或者限量成功但限量成功的流程状态更新失败(上述步骤3的执行结果为执行失败)，此时流程实例的当前执行状态为准备状态，如果是限量成功的流程状态更新成功但发货失败，此时流程实例的当前执行状态为限量成功状态，如果发货成功这说明礼包发放成功，也就是流程实例执行成功，礼包被成功发放到相应的客户端。

在流程实例执行过程中，如果一旦某个服务节点执行前向动作出现异常，则需要根据实例的当前状态执行相应的流程补偿操作。

可选的，如图5a和图5b所示，同步发货流程的prepare状态的补偿策略可以是：流程补偿引擎处理prepare状态的流程，回滚限量(限量通过流水号支持空回滚)，并更新流程实例的状态为invalid(无效)，标识事务执行失败。限量成功状态的补偿策略可以是：流程补偿引擎处理限量成功状态的流程，执行发货(发货可以通过流水号支持不超发)，发货成功则更新状态为发货成功，否则回滚限量并更新状态为invalid。

需要说明的是，如果prepare状态对应的是限量操作执行成功但限量成功的状态更新失败的情况，prepare状态的补偿策略中的限量回滚则是需要真正执行回滚限量操作，即撤销已经执行的限量操作，恢复到限量操作之前的情况，并更新流程状态为特定状态如invalid，如果prepare状态对应的限量操作执行失败的情况，上述回滚限量操作可以是空回滚，因为限量操作并未真正执行。

采用上述补偿策略，在限量操作出现异常时，流程托管服务器可以通过执行回滚操作，将事务恢复至执行前的状态，可以保证最终数据的一致性。在发货操作出现异常时，可以通过再次执行发货操作的补偿操作，提高发货的成功率，如果补差失败可以再执行回滚操作。

其中，如果一个流程实例的发货操作执行成功，则说明礼包发放事务执行成功，可以返回处理成功的结果，如流程托管服务器30可以向业务服务器2反馈执行成功的处理结果，业务服务器20可以将领取成功的提示信息发送给用户终端以展示给游戏玩家，如可以在用户终端上显示图4所示的领取成功的提示页面。

对于异步发货场景，图6中示出了流程托管服务器30的控制器执行礼包领取事务对应的流程实例的流程示意图，该流程可以包括如下步骤：

步骤1:初始化流程，如果成功进入下一步，如果失败或结果不可知返回失败；

步骤2:执行限量，如果成功进入下一步，如果失败或结果不可知直接返回失败；

步骤3:更新流程状态为限量成功，如果成功进入下一步，如果失败或结果不可知直接返回失败；

步骤4:推送发货队列；

步骤5:更新流程状态为写MQ成功；

步骤6:离线发货服务消费发货队列并发货；

步骤7:更新消息状态为发货成功。

其中，上述步骤1至步骤3与同步发货流程的步骤1至步骤3可以相同。上述MQ是发货服务节点对应的消息队列，该队列可以用于存储发货服务节点待执行的发货操作，在步骤3的限量成功的流程状态更新成功时，流程补偿引擎的控制器可以通过消息服务节点(即步骤4对应的服务节点)将流程实例(即一个发货事务的执行实例)对应的发货操作写入MQ(推送入发货队列)，并更新流程状态为写MQ成功。步骤6和步骤7则是由发货服务节点读取MQ并执行所读取的发货操作(即消费发货队列，也就是执行该队列中待执行的发货操作)，在发货成功时，可以更新流程实例的流程状态为发货成功。

对于上述礼包发放事务的异步处理流程，图7示出了本公开实施例提供的一种分布式事务的补偿机制的原理示意图，如图7所示，礼包同步发货的执行流程可以对应有4种流程状态，分别是准备状态(对应初始化流程)、限量成功状态(对应限量操作)、写MQ成功状态(对应消息服务节点的事务操作)和发货成功状态。如果在流程实例的执行过程中，出现限量失败或者限量成功但限量成功的流程状态更新失败(上述步骤3的执行结果为执行失败)，此时流程实例的当前执行状态为准备状态，如果是限量成功的流程状态更新成功，此时流程实例的当前执行状态为限量成功状态，写MQ成功则是消息服务节点的执行状态，该节点对应的执行状态可以总是成功的状态，即只要限量成功的状态更新之后，写MQ的动作总能成功，如果发货成功则流程实例执行成功，执行状态是发货成功状态。对于异步发货场景，在执行状态是限量成功状态之后，即可以向用户终端返回礼包领取成功的结果。

可选的，如图6和图7所示，异步发货流程的prepare状态的补偿策略可以是：补偿引擎处理prepare状态的流程，执行限量回滚(限量通过流水号支持空回滚)，并更新状态为invalid，当然，根据限量操作是否真正被执行，这里的执行限量回滚可以是真正的回滚操作，也可以是空回滚操作。限量成功状态的补偿策略可以是：推送发货队列并更新状态为写MQ成功。写MQ成功状态的补偿策略：推送补发队列，重试次数达到上限将流程实例推送死信队列(指定队列)。可选的，死信状态的补偿策略可以是：人工干预，如增大重试次数(如图7中将死信队列中执行失败的发货操作再次执行写MQ成功状态的补偿策略)或者人工操作进行礼包补发(如图7中可以由人工参与的方式控制死信队列中的发货操作执行成功，状态更新为发货成功)。

作为一可选方案，图8示出了本公开实施例提供的一种分布式事务处理系统的架构示意图，如图8中所示，该分布式事务系统中流程补偿引擎可以包括以下几个部分：流程托管服务31及流程SDK(Software Development Kit，软件开发工具包)、补偿分发器32和补偿处理器33。

其中，在实际实施时，对于具体的业务，业务人员可以将具体的业务执行流程中所涉及的写操作(如上述虚拟资源发货业务中发货链路中涉及的写操作，也就是会涉及到数据更改的操作)提出来，实现前向动作(流程实例正常执行过程中各节点要执行的事务操作)和补偿动作(流程补偿操作)，然后可以通过流程SDK接入到流程托管服务中，由流程托管服务执行各项写操作以及维护流程状态。具体的，流程补偿引擎300在接收到业务服务器发送来的分布式事务(如上述虚拟资源发放事务)时，流程托管服务31可以生成分布式事务的流程实例并存储，并可以通过调用流程实例的各服务节点执行流程实例，也就是执行各节点各自对应的事务操作，在流程实例的执行过程中，对于流程出现异常的，可以由补偿分发器32和补偿处理器33完成流程补偿。其中，流程补偿机制可以包括两种：

1)即时补偿：流程托管服务执行前向动作一旦出现异常，就提交流程实例给到流程补偿分发器。流程补偿分发器即时处理，根据流程实例当前状态分发到对应的流程补偿处理队列，再由流程补偿器操作补偿动作完成补偿。对于补偿失败的，还可以根据配置策略写回流程补偿分发器进行延时补偿。

2)延时补偿：除了即时补偿失败会进行延时重试的情况，流程托管服务还维护了一个未完成流程实例队列，轮询写入流程补偿分发器，保证未完成的流程可以得到最终补偿。流程补偿分发器只会分发到达执行时间的流程实例，不会分发未到执行时间的流程实例。

图9示出了图8中的分布式事务系统架构的一种详细实现方案的示意图，图9中示意性的示出了流程实例的一种执行流程，如图9中50部分，该示意的执行流程中包括4个服务节点，第一个服务节点部分的更新状态可以理解是流程实例初始化对应的流程状态，第二个服务节点部分的更新状态是指第一个服务节点的事务操作执行成功之后要更新流程实例的执行状态为第一个服务节点的事务操作执行成功。每个节点部分的前向动作是指节点要执行的事务操作，后向动作可以是在节点的事务操作执行异常时的事务回滚操作，如果流程补偿策略是再次执行节点的事务操作，则相应的流程补偿操作就是再次执行节点的前向动作。其中，图9的示意图中50部分的第2个服务节点可以是异步处理流程中的消息服务节点，该节点可以采用异步处理，该节点的在将第3个服务节点的待处理事务操作写入对应的MQ并更新执行状态为写MQ成功之后，可以无需等待后续节点的执行结果即可以当客户端反馈执行成功的结果，第3个服务节点可以采用异步执行方式，通过读取其所对应的MQ来消费该节点的事务操作，执行成功后，更新流程的执行状态为该节点的事务操作执行成功，可以通过下个服务节点继续执行对应的事务操作。可以理解的是，图9中给出的只是一个流程执行的示例。

流程托管服务31在获取到待处理的分布式事务中，可以根据所定义好的执行流程，生成该事务对应的流程实例并存储(流程实例信息存储)，如图9中所示，流程实例可以采用K-V(键-值)存储方式，每个流程实例包括流程实例ID和流程实例内容，在流程实例生成之后，可以将流程实例的实例ID存储到未完成流程实例队列中。对于每个流程实例ID，可以根据该ID对应的流程实例内容，依次通过调用各个服务节点来执行各节点所要执行的事务操作。流程实例执行成功时，则可以将流程实例的实例ID从未完成流程实例队列中删除。一旦某个服务节点的前向动作执行出现异常，则可以提交流程实例(如流程实例ID)给流程补偿分发器32，流程补偿分发器32根据流程实例的流程标识将流程实例分发到对应的流程补偿处理队列，如图9中所示的流程1补偿队列、流程2补偿队列、……、流程M补偿队列，每个队列对应一种流程定义。可选的，流程标识也可以是业务标识，每种业务对应各自的一个流程补偿处理队列，每种业务的需要进行补偿的流程实例的相关内容会被写入该业务对应的补偿处理队列中，流程补偿处理器33可以对各个队列中存储的需要补偿的流程实例执行与流程实例的当前执行状态相匹配的流程补偿操作，完成流程补偿。

可选的，流程补偿分发器32可以采用消息订阅与发布机制实现，如图9中所示，事件PUB为消息发布者，事件SUB为事件订阅者，流程补偿分发器32在收到需要进行补偿处理的流程实例时，可以通过事件PUB将流程实例对应的流程补偿事件(可以包括流程实例的ID和时间戳信息，时间戳指示了事件的执行时机)分发到桶(bucket，可以理解为队列)中，桶中的流程补偿事件可以由事件SUB部分的事件分发协程分发到补偿处理器33部分的各个流程补偿队列中，由补偿处理器33执行对应的流程补偿操作。

如图9所示的一种可选方案中，事件PUB部分的协程1可以理解为一个同步维护协程，协程2是事件发布协程，该协程可以有多个，处理流程补偿事件的桶可以有多个如图中所示的N个，协程1用于顺序地依次向同步通道中写入各个桶的标识，比如先写入1，此时，对于补偿分发器32接收到需要补偿的流程实例(如实例ID)，协程2通过读取同步信道中的桶标识，将流程补偿事件写入到桶1中(push event)，同步通道中的桶标识1被消费，协程1将2写入同步信道，下一个流程补偿事件被写入到桶2中，同步不断重复上述过程，当同步通道的桶标识为N且被消费后，协程1再从1开始写入。

其中，每个流程补偿事件可以带有事件对应的执行时间戳，每个桶中的流程补偿事件的执行时间戳(如图中的时间戳1)达到时，流程补偿分发器32会通过每个桶各自对应的订阅者协程将该桶中执行时间到达的流程补偿事件分发到该补偿事件对应的流程处理队列(不同的流程定义可以对应不同的流程补偿队列)中，由流程补偿处理器对各个队列中的流程补偿事件进行补偿处理。

如图9所示，可选的，事件SUB部分的事件分发协程可以有多个，如可以与桶的数量一致，每个桶对应一个协程，协程N用于将桶N中达到分发时间的流程补偿事件写入到流程补偿队列中，以被补偿处理器执行。

如图9中补偿处理器33所示的部分，每个流程补偿处理队列可以对应各自的消费线程池，消费线程池中的各线程用于消费队列中的待处理事件，也就是根据流程实例的当前执行状态，确定补偿策略，根据确定出的补偿策略执行相应的补偿动作。对于补偿失败的流程实例，还可以根据配置策略写回流程补偿分发器进行延时补偿，具体的，可以确定该流程实例对应的延时补偿事件戳(如图中的时间戳2)，将需要延时补偿的流程实例再次写入流程补偿分发器，在达到延时补偿时间戳时，将流程实例对应的流程补偿事件再次分发到对应的流程补偿队列中，由流程补偿处理器再次执行补偿动作。

需要说明的是，在流程实例的执行过程中，流程实例的实例内容也是在不断变化的，流程实例内容中记录了一个流程实例的各种相关信息，根据流程实例内容可以知晓流程实例目前处于何种状态，某个服务节点如果执行存在异常，流程补偿策略已经执行了几次等等。

将本公开实施例提出的分布式事务机制应用于虚拟资源的发放业务场景中，可以有效解决传统的分布式事务方案无法覆盖各种类型虚拟资源发放的数据一致性问题，保证各个操作环节(如限量操作、发货操作、写领取记录操作等)的数据一致性。本公开提供的方案支持自定义配置发货托管流程和补偿策略，能够在流程的每个环节支持独立的可前可后的补偿策略。对于无论是同步还是异步发货形式中可能存在的各种可补发/不可补发的失败原因，都可以得到解决，并保证最终数据的一致性。

基于与本公开实施例提供的方法相同的原理，本公开实施例还提供了一种分布式事务处理装置，如图10所示，该分布式事务处理装置100可以包括流程实例生成模块110、流程实例执行模块120和流程补偿处理模块130。

流程实例生成模块110，用于获取待处理的分布式事务，生成分布式事务对应的流程实例；

流程实例执行模块120，用于基于流程实例，依次通过流程实例对应的至少两个服务节点中的各节点执行以下操作，直至流程实例执行成功，或者任一当前服务节点的事务操作执行异常：

通过当前服务节点执行该服务节点对应的事务操作，若执行成功，将流程实例的执行状态更新为表征该服务节点的事务操作执行成功；

流程补偿处理模块130，用于在出现当前服务节点的事务操作执行异常的情况时，根据流程实例的当前执行状态，从流程补偿策略集中确定出流程实例对应的流程补偿策略，根据流程实例对应的流程补偿策略，对流程实例执行对应的流程补偿操作，其中，流程补偿策略集中包括各种流程实例执行状态所对应的流程补偿策略。

可选的，流程实例包括实例标识和实例内容，若流程实例对应的流程补偿操作执行失败，流程补偿处理模块130还用于：

将流程实例的相关信息存储到未完成流程实例队列中，相关信息包括流程实例的实例标识；

响应于满足流程实例的延时补偿触发条件，再次对流程实例执行对应的流程补偿操作；

若流程补偿操作重试成功，将流程实例的实例标识从未完成流程实例队列中删除。

可选的，若流程实例对应的流程补偿操作执行失败，流程补偿处理模块130还用于：

确定流程实例对应的延时补偿时间戳，相关信息还包括延时补偿时间戳；

若延时补偿时间戳对应的时间到达，确定满足流程实例的延时补偿触发条件；

若流程补偿操作重试失败，更新未完成流程实例队列中存储的流程实例的延时补偿时间戳。

可选的，流程补偿处理模块130还用于：

若流程补偿操作的重试次数达到设定次数且流程补偿操作执行失败，根据当前执行状态，执行事务回滚操作。

可选的，流程补偿处理模块130在根据流程实例的当前执行状态，从流程补偿策略集中确定出流程实例对应的流程补偿策略时，可以用于：

根据流程实例的实例标识和当前执行状态，生成流程实例对应的流程补偿事件；

确定流程实例对应的流程标识，流程标识对应一种流程定义；

根据流程标识，从预配置的各流程补偿队列中确定出流程实例对应的目标流程补偿队列，其中，每个流程补偿队列对应一种流程定义；

将流程实例对应的流程补偿事件分发到目标流程补偿队列；

对各流程实例中的流程补偿事件进行处理，在到达目标流程补偿队列中流程实例对应的流程补偿事件的处理时机时，根据流程补偿事件对应的当前执行状态，从流程补偿策略集中确定出流程实例对应的流程补偿策略。

可选的，流程补偿策略集包括多种流程定义对应的流程补偿策略集；流程补偿处理模块130可以用于：

确定流程实例对应的流程标识，流程标识对应一种流程定义；

根据当前执行状态，从流程标识对应的流程补偿策略集中确定流程实例对应的流程补偿策略。

可选的，对于各服务节点中的最后一个服务节点，服务节点的事务操作执行异常为：服务节点的事务操作执行失败；

对于除最后一个服务节点之外的各服务节点，服务节点的事务操作执行异常包括：

服务节点的事务操作执行失败，或服务节点对应的执行状态更新失败。

可选的，分布式事务对应的各服务节点的事务操作执行流程为同步执行流程；

若流程实例的当前执行状态为最后一个服务节点的上一个服务节点的事务操作执行成功，流程实例对应的流程补偿策略包括：

再次执行最后一个服务节点的事务操作；

若流程实例的当前执行状态为第一节点的事务操作执行成功或初始化状态，流程实例对应的流程补偿策略包括：执行事务回滚操作；

其中，第一节点是除最后一个服务节点的上一个服务节点之外的服务节点。

可选的，分布式事务对应的各服务节点的事务操作执行流程为异步执行流程；

上述至少两个服务节点包括至少一个消息服务节点，消息服务节点对应的事务操作为：将该消息服务节点的下一个服务节点的事务操作写入消息队列中，其中，消息队列中的事务操作由该消息服务节点的下一个服务节点异步读取并执行；

若流程实例的当前执行状态为消息服务节点的事务操作执行成功，流程实例对应的流程补偿策略包括：

将该消息服务节点的下一个服务节点的事务操作写入补偿处理队列中，其中，补偿补偿队列中事务操作在满足执行条件时被再次执行，若一个事务操作的重试次数达到设定次数且重试未成功，将该流程实例写入指定队列中；

若流程实例的当前执行状态为初始化状态或第二节点的事务操作执行成功，第二节点是所有消息服务节点之前的节点，流程实例对应的流程补偿策略包括：执行事务回滚操作。

本公开实施例的装置可执行本公开实施例所提供的方法，其实现原理相类似，本公开各实施例的装置中的各模块所执行的动作是与本公开各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

本公开实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行存储器中存储的计算机程序时可实现本公开任一可选实施例中的方法。

图11示出了本发明实施例所适用的一种电子设备的结构示意图，如图11所示，该电子设备可以为服务器或者用户终端，该电子设备可以用于实施本发明任一实施例中提供的方法。

如图11中所示，该电子设备2000主要可以包括至少一个处理器2001(图11中示出了一个)、存储器2002、通信模块2003和输入/输出接口2004等组件，可选的，各组件之间可以通过总线2005实现连接通信。需要说明的是，图11中示出的该电子设备2000的结构只是示意性的，并不构成对本公开实施例提供的方法所适用的电子设备的限定。

其中，存储器2002可以用于存储操作系统和应用程序等，应用程序可以包括在被处理器2001调用时实现本发明实施例所示方法的计算机程序，还可以包括用于实现其他功能或服务的程序。存储器2002可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和计算机程序的其他类型的动态存储设备，也可以是EEPROM(ElectricallyErasable Programmable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(CompactDisc Read Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

处理器2001通过总线2005与存储器2002连接，通过调用存储器2002中所存储的应用程序实现相应的功能。其中，处理器2001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application Specific Integrated Circuit，专用集成电路)，FPGA(FieldProgrammable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合，其可以实现或执行结合本发明公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器2001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

电子设备2000可以通过通信模块2003(可以包括但不限于网络接口等组件)连接到网络，以通过网络与其它设备(如用户终端或服务器等)的通信，实现数据的交互，如向其他设备发送数据或从其他设备接收数据。其中，通信模块2003可以包括有线网络接口和/或无线网络接口等，即通信模块可以包括有线通信模块或无线通信模块中的至少一项。

电子设备2000可以通过输入/输出接口2004可以连接所需要的输入/输出设备，如键盘、显示设备等，电子设备200自身可以具有显示设备，还可以通过接口2004外接其他显示设备。可选的，通过该接口2004还可以连接存储装置，如硬盘等，以可以将电子设备2000中的数据存储到存储装置中，或者读取存储装置中的数据，还可以将存储装置中的数据存储到存储器2002中。可以理解的，输入/输出接口2004可以是有线接口，也可以是无线接口。根据实际应用场景的不同，与输入/输出接口2004连接的设备，可以是电子设备2000的组成部分，也可以是在需要时与电子设备2000连接的外接设备。

用于连接各组件的总线2005可以包括一通路，在上述组件之间传送信息。总线2005可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(Extended Industry Standard Architecture，扩展工业标准结构)总线等。根据功能的不同，总线2005可以分为地址总线、数据总线、控制总线等。

可选的，对于本发明实施例所提供的方案而言，存储器2002可以用于存储执行本发明方案的计算机程序，并由处理器2001来运行，处理器2001运行该计算机程序时实现本发明实施例提供的方法或装置的动作。

基于与本公开实施例提供的方法相同的原理，本公开实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的相应内容。

本公开实施例还提供了一种计算机程序产品，该产品包括计算机程序，该计算机程序被处理器执行时可实现前述方法实施例的相应内容。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除图示或文字描述以外的顺序实施。

应该理解的是，虽然本公开实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本公开实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本公开实施例对此不限制。

以上所述仅是本公开部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本公开的方案技术构思的前提下，采用基于本公开技术思想的其他类似实施手段，同样属于本公开实施例的保护范畴。

Claims (14)

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

获取待处理的分布式事务，生成所述分布式事务对应的流程实例；

基于所述流程实例，依次通过所述流程实例对应的至少两个服务节点中的各节点执行以下操作，直至所述流程实例执行成功，或者任一当前服务节点的事务操作执行异常：

通过当前服务节点执行该服务节点对应的事务操作，若执行成功，将所述流程实例的执行状态更新为该服务节点的事务操作执行成功；

其中，若出现当前服务节点的事务操作执行异常的情况，则根据所述流程实例的当前执行状态，从流程补偿策略集中确定出所述流程实例对应的流程补偿策略，所述流程补偿策略集中包括各种流程实例执行状态所对应的流程补偿策略；

根据所述流程实例对应的流程补偿策略，对所述流程实例执行对应的流程补偿操作。

2.根据权利要求1所述的方法，其特征在于，所述流程实例包括实例标识和实例内容，所述方法还包括：

将所述流程实例的实例标识存储到未完成流程实例队列中；

若所述流程实例执行成功，则将所述流程实例的实例标识从所述未完成流程实例队列删除；

若所述流程实例对应的流程补偿操作执行失败，所述方法还包括：

响应于满足所述流程实例的延时补偿触发条件，再次对所述流程实例执行对应的流程补偿操作；

若所述流程补偿操作重试成功，则继续执行所述流程实例。

3.根据权利要求2所述的方法，其特征在于，若所述流程实例对应的流程补偿操作执行失败，所述方法还包括：

确定所述流程实例对应的延时补偿时间戳；

若所述延时补偿时间戳对应的时间到达，确定满足所述流程实例的延时补偿触发条件；

若所述流程补偿操作重试失败，更新所述未完成流程实例队列中存储的所述流程实例的延时补偿时间戳。

4.根据权利要求2所述的方法，其特征在于，还包括：

若所述流程补偿操作的重试次数达到设定次数且流程补偿操作执行失败，根据所述当前执行状态，执行事务回滚操作或将所述流程实例写入指定队列。

5.根据权利要求2所述的方法，其特征在于，所述方法还包括：

对所述未完成流程实例队列进行轮询操作，若所述未完成流程实例队列中存在存储时长达到设定时长的实例标识，则根据该实例标识对应的流程实例执行状态，执行对应的流程补偿操作。

6.根据权利要求1所述的方法，其特征在于，所述根据所述流程实例的当前执行状态，从流程补偿策略集中确定出所述流程实例对应的流程补偿策略，包括：

根据所述流程实例的实例标识和所述当前执行状态，生成所述流程实例对应的流程补偿事件；

确定所述流程实例对应的流程标识，所述流程标识对应一种流程定义；

根据所述流程标识，从预配置的各流程补偿队列中确定出所述流程实例对应的目标流程补偿队列，其中，每个流程补偿队列对应一种流程定义；

将所述流程实例对应的流程补偿事件分发到所述目标流程补偿队列；

对各所述流程补偿队列中的流程补偿事件进行处理，在到达所述目标流程补偿队列中所述流程实例对应的流程补偿事件的处理时机时，根据所述流程补偿事件对应的当前执行状态，从流程补偿策略集中确定出所述流程实例对应的流程补偿策略。

7.根据权利要求1或5所述的方法，其特征在于，所述流程补偿策略集包括多种流程定义对应的流程补偿策略集；

所述根据所述流程实例的当前执行状态，从流程补偿策略集中确定出所述流程实例对应的流程补偿策略，包括：

确定所述流程实例对应的流程标识，所述流程标识对应一种流程定义；

根据所述当前执行状态，从所述流程标识对应的流程补偿策略集中确定所述流程实例对应的流程补偿策略。

8.根据权利要求1所述的方法，其特征在于，对于各服务节点中的最后一个服务节点，服务节点的事务操作执行异常为：服务节点的事务操作执行失败；

对于除最后一个服务节点之外的各服务节点，服务节点的事务操作执行异常包括：

服务节点的事务操作执行失败，或服务节点对应的执行状态更新失败。

9.根据权利要求1至5以及8中任一项所述的方法，其特征在于，所述分布式事务对应的各服务节点的事务操作执行流程为同步执行流程；

若所述流程实例的当前执行状态为最后一个服务节点的上一个服务节点的事务操作执行成功，所述流程实例对应的流程补偿策略包括：

再次执行最后一个服务节点的事务操作；

若所述流程实例的当前执行状态为第一节点的事务操作执行成功或初始化状态，所述流程实例对应的流程补偿策略包括：执行事务回滚操作；

其中，所述第一节点是除最后一个服务节点的上一个服务节点之外的服务节点。

10.根据权利要求1至5以及8中任一项所述的方法，其特征在于，所述分布式事务对应的各服务节点的事务操作执行流程为异步执行流程；

所述至少两个服务节点包括至少一个消息服务节点，所述消息服务节点对应的事务操作为：将该消息服务节点的下一个服务节点的事务操作写入消息队列中，其中，所述消息队列中的事务操作由该消息服务节点的下一个服务节点异步读取并执行；

若所述流程实例的当前执行状态为消息服务节点的事务操作执行成功，所述流程实例对应的流程补偿策略包括：

将该消息服务节点的下一个服务节点的事务操作写入补偿处理队列中，其中，所述补偿补偿队列中事务操作在满足执行条件时被再次执行，若一个事务操作的重试次数达到设定次数且重试未成功，将所述流程实例写入指定队列中；

若所述流程实例的当前执行状态为初始化状态或第二节点的事务操作执行成功，所述第二节点是所有消息服务节点之前的节点，所述流程实例对应的流程补偿策略包括：执行事务回滚操作。

11.一种分布式事务处理装置，其特征在于，所述装置包括：

流程实例生成模块，用于获取待处理的分布式事务，生成所述分布式事务对应的流程实例；

流程实例执行模块，用于基于所述流程实例，依次通过所述流程实例对应的至少两个服务节点中的各节点执行以下操作，直至所述流程实例执行成功，或者任一当前服务节点的事务操作执行异常：

通过当前服务节点执行该服务节点对应的事务操作，若执行成功，将所述流程实例的执行状态更新为该服务节点的事务操作执行成功；

流程补偿处理模块，用于在出现当前服务节点的事务操作执行异常的情况时，根据所述流程实例的当前执行状态，从流程补偿策略集中确定出所述流程实例对应的流程补偿策略，根据所述流程实例对应的流程补偿策略，对所述流程实例执行对应的流程补偿操作，其中，所述流程补偿策略集中包括各种流程实例执行状态所对应的流程补偿策略。

12.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序以实现权利要求1-10任一项所述的方法。

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

14.一种计算机程序产品，其特征在于，所述计算机产品包括计算机程序，所述计算机程序被处理器执行时实现权利要求1-10任一项所述的方法。