CN113900785A - 一种分布式事务处理方法、装置及电子设备 - Google Patents

Abstract

本公开提供了一种分布式事务处理的方法，涉及计算机技术领域，尤其涉及数据库技术领域。具体实现方案为：获取业务状态机的当前动作状态，作为第一动作状态，所述业务状态机为呈现业务处理情况的状态机；调用所述业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行所述第一业务操作接口对应的操作。从而，使得事务协调器与各个业务解耦，减少了事务协调器对业务端业务的侵入，降低了业务的运维成本。

Description

一种分布式事务处理方法、装置及电子设备

技术领域

本公开涉及计算机技术领域，尤其涉及数据库技术领域。

背景技术

当前，在分布式系统环境下进行事务处理时，需要保证微服务多操作序列的原子性提交问题。

发明内容

本公开提供了一种分布式事务处理方法方法、装置、设备以及存储介质。

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

获取业务状态机的当前动作状态，作为第一动作状态，所述业务状态机为呈现业务处理情况的状态机；

调用所述业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行所述第一业务操作接口对应的操作。

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

业务状态机状态获取模块，用于获取业务状态机的当前动作状态，作为第一动作状态，所述业务状态机为呈现业务处理情况的状态机；

第一接口调用模块，用于调用所述业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行所述第一业务操作接口对应的操作。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开的分布式事务处理方法的一种流程示意图；

图2是根据本公开的分布式事务处理方法的另一种流程示意图；

图3是根据本公开的分布式事务处理方法的另一种流程示意图；

图4是根据本公开的分布式事务处理方法的另一种流程示意图；

图5是根据本公开的分布式事务处理方法的另一种流程示意图；

图6是根据本公开的分布式事务处理装置的一种结构示意图；

图7是用来实现本公开实施例的分布式事务处理方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在分布式系统环境下，一个业务处理单元通常需要组合请求多个服务，特别在业务已经有大量微服务的系统内，组合服务的请求可能多达数十个。此外，对于一个复杂的可分步骤执行的业务逻辑，往往是通过数量较多的操作实现的。为了保证分布式系统的正常运行，需要保证这些请求和操作的一致性，而保证这些请求和操作的一致性的机制称为分布式事务。

相关技术中，有多种分布式事务处理方案，如XA(X/Open DTP组织定义的两阶段提交协议)、TCC(Try、Confirm、Cancel)等实现方案可以分布式事务进行处理，但是相关技术中，在实施时将出现业务端和事务协调器端强耦合的问题。导致事务协调器的代码侵入业务，因此用户对业务进行运维时需要同步地对事务协调器进行运维，造成业务运维的成本较高。

基于上述技术问题，本公开的实施例提供了一种分布式事务处理方法，该方法如图1所示，包括：

S101，获取业务状态机的当前动作状态，作为第一动作状态。

S102，调用业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行第一业务操作接口对应的操作。

选用该实施例，事务协调器可以基于业务状态机的第一动作状态调用不同状态对应的业务操作接口，使得各业务端按照业务操作接口执行对应操作，可见，本公开的事务协调器只根据业务状态机的状态来调用业务操作接口，业务端的各业务则只根据业务操作接口来执行对应操作，并不需要对不同的业务应用该业务对应的操作步骤，事务调节器通过接口形式与业务交互，事务协调器只需要获得业务的状态，为业务调用该状态对应的操作接口，使得事务协调器与各个业务解耦，减少了事务协调器对业务端业务的侵入，降低了业务的运维成本。

其中，在S101中，业务状态机为呈现业务处理情况的状态机，业务状态机可以根据业务内容的不同预先定义好业务状态机上各节点的动作，示例性的，以网上购物的应用场景为例，在网上购物的应用场景中存在用户支付订单业务，假设该业务在处理过程中存在步骤：修改订单状态，则可以在该业务对应的业务状态机中，将一个节点上对应的动作定义为修改订单状态，并将修改订单状态是否成功定义为该节点对应的状态。可以理解，若业务端的一个业务修改订单状态的动作没有执行成功，则该业务的业务状态机的对应节点上的当前动作状态即第一动作状态为修改订单状态失败。

而本实施例中，可以获取业务端业务对应的业务状态机各节点的动作状态，将各节点的动作状态作为业务状态机的第一动作状态。

在S102中，在确定了业务状态机的第一动作状态之后，就可以根据各节点的第一动作状态，调用对应的业务操作接口。示例性的，还是以网上购物的应用场景中用户支付订单业务为例，若业务端在处理业务时，只有步骤：修改订单状态没有执行成功，业务状态机显示对应的第一动作状态。可以理解的是，由于步骤：修改订单状态没有执行成功，为保证业务的一致性，该网上购物的应用场景中的用户支付订单业务中的其他步骤都应该回滚到未开始状态，因此，根据业务状态机的第一动作状态，事务协调器应该调用该第一动作状态对应的补偿业务操作接口来使得业务端恢复到开始状态重新进行操作。

再例如，若网上购物的应用场景中的用户支付订单业务中各步骤都执行成功，业务状态机对应显示第一动作状态，则事务协调器为该第一动作状态调用的对应业务操作接口应该为校验业务操作接口，使得业务端对各个已完成的步骤进行校验。

在实施过程中，业务的执行步骤和执行状态会经常发生变化，示例性的，还是以上述网上购物的应用场景为例，在一位用户购买了某物品之后，若有另一位用户购也买了相同物品，则业务端需要处理该用户支付订单业务，业务状态机的动作状态也应该相应改变，基于此，本公开还提供了一种分布式事务处理方法，如图2所述，包括：

S201，获取业务状态机的当前动作状态，作为第一动作状态。

该步骤与前述S101相同，可以参见前述S101的相关说明，在此不再赘述。

S202，调用业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行第一业务操作接口对应的操作。

该步骤与前述S102相同，可以参见前述S102的相关说明，在此不再赘述。

S203，获取业务端的业务的各预设执行步骤的执行结果。

对于一个业务来说，根据业务内容的不同对应的执行步骤可以不同，而技术人员可以根据不同的业务预先设置该业务对应的各个执行步骤。示例性的，在网上购物的应用场景中，有另一个用户购买了上一个用户相同的物品，则业务端需要处理该新生成的用户支付订单业务。该支付订单业务的预设执行步骤可以为修改订单状态、扣减库存、创建销售出库单，而上述预设步骤的执行结果就可以分别为修改订单状态是否成功、扣减库存是否正确、创建销售出库单是否正确。可以理解的是，业务端在执行各预设执行步骤之后必然会获得各个执行结果，因此，业务端可以将各预设执行步骤对应的执行结果发送到事务协调器端。

S204，根据业务的执行结果，更新业务状态机的当前动作状态，获得业务状态机的第二动作状态。

事务协调器在获取业务的各预设执行步骤的执行结果后，就可以根据执行结果，更新业务状态机的当前动作状态。示例性的，若业务的各预设执行步骤的执行结果分别为修改订单状态成功、扣减库存正确、创建销售出库单正确，则业务状态机就需要按照各执行结果来更新各步骤对应节点的动作状态，从而得到业务状态机的第二动作状态。

S205，调用业务状态机的第二动作状态对应的第二业务操作接口，使业务端执行第二业务操作接口对应的操作。

该步骤与前述S102类似，可以参见前述S102的相关说明，在此不再赘述。

选用该实施例，可以根据不同的业务的处理情况，实时更新业务状态机的动作状态，进而实时调用不同动作状态对应的业务操作接口，使得各业务可以尽快得到进一步处理，进而提高了分布式事务处理的时效性。

在一种可能的实施例中，由于业务的实际实施过程中，可能会出现网络异常或服务器异常等各种问题，使得业务端的业务请求出现重复上报、乱序上报、丢失上报等问题，进一步的，使得事务协调器根据异常的业务请求重复、乱序或丢失调用业务操作接口，从而导致业务无法正常处理，基于此，本申请还提供了一种分布式业务处理方法，如图3所示，包括：

S301，获取业务状态机的当前动作状态，作为第一动作状态。

该步骤与前述S101相同，可以参见前述S101的相关说明，在此不再赘述。

S302，调用业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行第一业务操作接口对应的操作。

该步骤与前述S102相同，可以参见前述S102的相关说明，在此不再赘述。

S303，根据业务端执行对应操作的结果更新事务状态机的状态，获得事务状态机的第三动作状态。

事务状态机为呈现业务端的事务处理情况的状态机。事务状态机可以根据业务操作接口的不同而在对应节点预设不同的动作，例如在某一节点上预设修改订单状态的动作为补偿或校验，而相应的，该节点上中的动作状态就可能为校验成功或校验失败。因此，事务状态机可以根据业务端执行对应的业务操作接口的操作结果，来更新事务状态机的动作状态。

示例性的，以前述网上购物应用场景中用户支付订单业务为例，若该业务中各步骤都执行成功，则业务端要根据事务协调器调用的第一动作状态对应的校验业务操作接口执行操作，校验各执行步骤的执行结果，确定校验是否成功，由此，事务调节器可以从业务端获得业务端执行业务操作接口操作的操作结果。若此时，只有扣减库存的步骤校验失败，其他执行步骤都校验成功，事务状态机就可以根据该操作结果，更新各节点的动作状态，即，将校验修改订单状态更新为校验成功，将校验扣减库存更新为校验失败，将校验创建销售出库单更新为校验成功，从而获得事务状态机的第三动作状态。

S304，接收业务端的业务请求，获取业务请求对应的上下文。

事务调节器在根据业务状态机的动作状态调用业务操作接口的同时，业务端自身也会根据自身的业务处理情况向事务调节器发送业务请求，使得事务调节器协调业务进行下一步处理。可以理解的是，业务请求中包含用于表示业务请求所请求的业务的内容，例如用于表示该业务是用户订单支付业务或用户退款业务的业务信息等等，业务请求也包含用于表示该业务请求所请求的业务操作接口的内容，例如该业务端中的某个步骤执行失败，业务端将请求补偿，则用于表示该请求补偿的接口的接口信息也会包含在业务请求中。而业务请求对应的上下文可以为处理该业务请求所需要的相关信息，也可以是业务端发送该业务请求时的背景，例如该业务的处理进程。

S305，根据上下文和第三动作状态判断业务请求是否为异常业务请求。

从上下文中可以获取到该业务请求的发送的背景，而从事务状态机的第三动作状态可以确定出业务端的业务按照业务操作接口进行操作的操作结果，基于此，事务协调器可以根据上下文和第三动作状态确定出一个业务的处理进程、按照业务操作接口进行操作及操作结果。而根据事务协调器上述确定出的业务的状态，就可以判断所接收到的业务请求是否为一个异常业务请求。例如，若一个业务请求中请求补偿业务操作接口，而事务协调器根据该业务对应的事务状态机此时的动作状态确定出该业务已经根据补偿业务操作接口进行补偿，并且补偿成功，则该业务请求就应该被判断为一个重复请求，即异常业务请求。再例如，若一个业务请求中请求校验业务操作接口，此时该业务对应的事务状态机显示的最新节点状态为补偿成功，根据该业务请求的上下文确定出该业务发出业务请求时，已经在该业务请求包含的内容已经请求过校验操作，而再查看事务状态机的上一个节点的状态，显示了该业务中包含的内容对应的校验动作的状态为成功，可以理解，该业务请求已经处理过，此时，事务协调器就可以判断该业务请求为乱序请求，即异常业务请求。

S306，如果是，拒绝根据业务请求进行操作。

若事务协调器判断接收到的业务请求为异常业务请求，则事务协调器将拒绝为该业务调用其所请求的业务操作接口，更不会根据其操作结果来更新事务状态机的动作状态。

S307，如果否，调用业务请求请求的业务操作接口，使业务端根据业务操作接口执行对应操作，更新事务状态机的第三动作状态。

选用该实施例，可以避免事务协调器为因网络异常或服务器异常等原因导致的异常业务请求调用业务操作接口，过滤重复请求、修正乱序请求、补齐丢失上报问题使得事务状态和业务处理异常，提高了分布式事务处理的容错性。

在一种可能的实施例中，业务请求是通过幂等的事务接口从业务端发送到事务协调器的。

可以理解的是，事务接口是业务从业务端发送业务请求到事务协调器的接口，而幂等的事务接口可以使得同一业务请求的一次或多次的请求结果是一致的。

选用该实施例，通过幂等的事务接口的特性，可以避免异常业务请求导致的业务处理和事务状态异常，进一步提高了分布式事务处理的容错性。

在分布式事务处理中，业务虽然对延迟不敏感，但是实施中事务协调器需要保证时效性，避免事务阻塞，基于此，本公开还提供了一种分布式事务处理方法，如图4所示，包括：

S401，根据业务类型和事务类型将多个业务请求分为不同类型的业务请求。

业务类型用于表示生成业务请求的业务的类型，所述事务类型用于表示业务请求所请求的事务的类型。而在实际业务处理过程中，事务协调器往往会同时接收到多个业务请求，又如前所述，业务请求中会包含业务的具体内容即业务类型和该业务所请求的业务操作接口即事务类型，基于此，可以将多个业务请求分为不同类型的业务请求，以便后续进行处理。

S402，将各不同类型的业务请求排入对应的请求队列。

请求队列为根据业务请求的类型而划分的队列，在根据业务请求划分了请求队列之后就可以将各个业务请求按照其类型排入对应的请求队列。

S403，将多个业务请求按照对应的请求队列投递到同一机房中，接收多个请求队列的业务请求。

在根据业务请求类型的不同将业务请求排入对应的队列之后，需要将各个队列中的业务请求投递到机房进行处理，具体的，可以将多个业务请求都投递到同一机房进行处理，同时，多个业务请求可以按照请求队列被投递到同一机房中，使得事务协调器可以根据请求队列的不同即业务请求的类型不同精细化接收处理业务请求，而将多个业务请求同机房投递也可以进一步的降低业务请求的处理延迟。

在一种可能的实施例中，可以将优先级较高的业务请求排入同一请求队列，使得事务协调器在处理业务请求时根据队列的不同而优先处理优先级较高的业务请求。

选用该实施例，在业务和事务维度将业务请求精细化拆分，并将业务请求同机房投递，事务调节器再接收业务请求，提高了事务协调器的业务请求接收效率，降低了业务请求处理延迟。

在一种可能的实施例中，在判断业务请求不为异常业务请求之后，需要根据业务请求进行处理，而一个业务请求往往会触发多个动作，例如若某个业务的多个预设执行步骤都需要补偿，则该业务中的多个预设执行步骤都需要按照补偿业务操作接口进行补偿，因此，该业务发送的一个业务请求中可以包括请求多个补偿业务操作接口，而事务协调器在面对同时需要调用多个业务操作接口时，可能会出现难以及时处理的情况，基于此，本公开还提供了一种分布式事务处理方法，如图5所示，包括：

S501，获取业务状态机的当前动作状态，作为第一动作状态。

该步骤与前述S101相同，可以参见前述S101的相关说明，在此不再赘述。

S502，调用第一动作状态对应的第一业务操作接口，使业务端执行第一业务操作接口执行对应的操作。

该步骤与前述S102相同，可以参见前述S102的相关说明，在此不再赘述。

S503，根据业务端执行对应操作的结果更新事务状态机的状态，获得事务状态机的第三动作状态。

该步骤与前述S303相同，可以参见前述S303的相关说明，在此不再赘述。

S504，接收业务端的业务请求，获取业务请求对应的上下文。

该步骤与前述S304相同，可以参见前述S304的相关说明，在此不再赘述。

S505，根据上下文和第三动作状态判断业务请求是否为异常业务请求。

该步骤与前述S305相同，可以参见前述S305的相关说明，在此不再赘述。

S506，如果否，将业务请求根据业务请求包含内容分为多个第一业务消息。

此时已经判断业务请求不是异常业务请求，就可以根据业务请求的内容拆分业务请求，以网上购物的应用场景中用户支付订单业务为例，若其中修改订单状态执行失败，则业务端可能会发送一个业务请求，其中可能包含了补偿修改订单状态、补偿扣减库存、补偿创建销售出库单等操作，此时，就可以将该业务请求按照其内容分为补偿修改订单状态第一业务消息、补偿扣减库存第一业务消息、补偿创建销售出库单第一业务消息。

S507，并发调用多个第一业务消息对应的业务操作接口。

在将一个业务请求拆分为多个第一业务消息之后，事务协调器可以根据各个第一业务消息的具体内容按照顺序并发的调用业务操作接口，以此处理业务请求。

选用该实施例，可以将一个业务请求拆分为多个业务消息，并按照业务消息的内容，按照顺序为业务消息调用业务操作接口，从而可以并发处理业务请求中的多个第一业务消息，提升了业务请求处理的时效性。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种分布式事务处理装置，如图6所示，包括：

业务状态机状态获取模块601，用于获取业务状态机的当前动作状态，作为第一动作状态，所述业务状态机为呈现业务处理情况的状态机；

第一接口调用模块602，用于调用所述业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行所述第一业务操作接口对应的操作。

在一种可能的实施例中，所述装置还包括：

执行结果获取模块，用于获取业务端的业务的各预设执行步骤的执行结果；

业务状态机状态更新模块，用于根据业务的所述执行结果，更新所述业务状态机的当前动作状态，获得业务状态机的第二动作状态；

第二接口调用模块，用于调用所述业务状态机的第二动作状态对应的第二业务操作接口，使业务端执行所述第二业务操作接口对应的操作。

在一种可能的实施例中，所述装置还包括：

事务状态机状态更新模块，用于根据所述业务端执行所述对应操作的结果更新事务状态机的状态，获得所述事务状态机的第三动作状态，所述事务状态机为呈现业务端的事务处理情况的状态机；

业务请求接收模块，用于接收业务端的业务请求，获取所述业务请求对应的上下文；

业务请求判断模块，用于根据所述上下文和所述第三动作状态判断所述业务请求是否为异常业务请求；如果是，拒绝根据所述业务请求进行操作；

业务请求处理模块，用于如果否，调用所述业务请求请求的业务操作接口，使所述业务端根据所述业务操作接口执行对应操作，更新所述事务状态机的第三动作状态。

在一种可能的实施例中，所述业务请求是通过幂等的事务接口从业务端发送到事务协调器的。

在一种可能的实施例中，所述业务请求判断模块，还包括：

业务请求分类单元，用于根据业务类型和事务类型将多个业务请求分为不同类型的业务请求，其中，所述业务类型用于表示生成所述业务请求的业务的类型，所述事务类型用于表示所述业务请求所请求的事务的类型；

请求队列划分模块，用于将各所述不同类型的业务请求排入对应的请求队列，其中，所述请求队列为根据所述业务请求的类型而划分的队列；

业务请求投递模块，用于将多个所述业务请求按照对应的所述请求队列投递到同一机房中，接收多个所述请求队列的业务请求。

在一种可能的实施例中，所述业务请求处理模块，还包括：

业务消息拆分单元，用于如果否，将所述业务请求根据所述业务请求包含内容分为多个第一业务消息；

业务消息处理单元，用于并发调用多个所述第一业务消息对应的业务操作接口。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图7示出了可以用来实施本公开的实施例的示例电子设备700的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图7所示，设备700包括计算单元701，其可以根据存储在只读存储器(ROM)702中的计算机程序或者从存储单元708加载到随机访问存储器(RAM)703中的计算机程序，来执行各种适当的动作和处理。在RAM 703中，还可存储设备700操作所需的各种程序和数据。计算单元701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

设备700中的多个部件连接至I/O接口705，包括：输入单元706，例如键盘、鼠标等；输出单元707，例如各种类型的显示器、扬声器等；存储单元708，例如磁盘、光盘等；以及通信单元709，例如网卡、调制解调器、无线通信收发机等。通信单元709允许设备700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元701的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元701执行上文所描述的各个方法和处理，例如分布式事务处理方法。例如，在一些实施例中，分布式事务处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元708。在一些实施例中，计算机程序的部分或者全部可以经由ROM 702和/或通信单元709而被载入和/或安装到设备700上。当计算机程序加载到RAM 703并由计算单元701执行时，可以执行上文描述的分布式事务处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行分布式事务处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (15)

1.一种分布式事务处理方法，包括：

获取业务状态机的当前动作状态，作为第一动作状态，所述业务状态机为呈现业务处理情况的状态机；

调用所述业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行所述第一业务操作接口对应的操作。

2.根据权利要求1所述的方法，还包括：

获取业务端的业务的各预设执行步骤的执行结果；

根据业务的所述执行结果，更新所述业务状态机的当前动作状态，获得业务状态机的第二动作状态；

调用所述业务状态机的第二动作状态对应的第二业务操作接口，使业务端执行所述第二业务操作接口对应的操作。

3.根据权利要求1或2所述的方法，还包括：

根据所述业务端执行所述对应操作的结果更新事务状态机的状态，获得所述事务状态机的第三动作状态，所述事务状态机为呈现业务端的事务处理情况的状态机；

接收业务端的业务请求，获取所述业务请求对应的上下文；

根据所述上下文和所述第三动作状态判断所述业务请求是否为异常业务请求；

如果是，拒绝根据所述业务请求进行操作；

如果否，调用所述业务请求请求的业务操作接口，使所述业务端根据所述业务操作接口执行对应操作，更新所述事务状态机的第三动作状态。

4.根据权利要求3所述的方法，其中，所述业务请求是通过幂等的事务接口从业务端发送到事务协调器的。

5.根据权利要求3或4所述的方法，其中，在所述根据所述上下文和所述第三动作状态判断所述业务请求是否为异常业务请求之前，还包括：

根据业务类型和事务类型将多个业务请求分为不同类型的业务请求，其中，所述业务类型用于表示生成所述业务请求的业务的类型，所述事务类型用于表示所述业务请求所请求的事务的类型；

将各所述不同类型的业务请求排入对应的请求队列，其中，所述请求队列为根据所述业务请求的类型而划分的队列；

将多个所述业务请求按照对应的所述请求队列投递到同一机房中，接收多个所述请求队列的业务请求。

6.根据权利要求3-5所述的方法，其中，所述如果否，调用所述业务请求请求的业务操作接口，包括：

如果否，将所述业务请求根据所述业务请求包含内容分为多个第一业务消息；

并发调用多个所述第一业务消息对应的业务操作接口。

7.一种分布式事务处理装置，包括：

业务状态机状态获取模块，用于获取业务状态机的当前动作状态，作为第一动作状态，所述业务状态机为呈现业务处理情况的状态机；

第一接口调用模块，用于调用所述业务状态机的第一动作状态对应的第一业务操作接口，使业务端执行所述第一业务操作接口对应的操作。

8.根据权利要求7所述的装置，还包括：

执行结果获取模块，用于获取业务端的业务的各预设执行步骤的执行结果；

业务状态机状态更新模块，用于根据业务的所述执行结果，更新所述业务状态机的当前动作状态，获得业务状态机的第二动作状态；

第二接口调用模块，用于调用所述业务状态机的第二动作状态对应的第二业务操作接口，使业务端执行所述第二业务操作接口对应的操作。

9.根据权利要求7或8所述的装置，还包括：

事务状态机状态更新模块，用于根据所述业务端执行所述对应操作的结果更新事务状态机的状态，获得所述事务状态机的第三动作状态，所述事务状态机为呈现业务端的事务处理情况的状态机；

业务请求接收模块，用于接收业务端的业务请求，获取所述业务请求对应的上下文；

业务请求判断模块，用于根据所述上下文和所述第三动作状态判断所述业务请求是否为异常业务请求；如果是，拒绝根据所述业务请求进行操作；

业务请求处理模块，用于如果否，调用所述业务请求请求的业务操作接口，使所述业务端根据所述业务操作接口执行对应操作，更新所述事务状态机的第三动作状态。

10.根据权利要求9所述的装置，其中，所述业务请求是通过幂等的事务接口从业务端发送到事务协调器的。

11.根据权利要求9或10所述的装置，其中，所述业务请求判断模块，还包括：

业务请求分类单元，用于根据业务类型和事务类型将多个业务请求分为不同类型的业务请求，其中，所述业务类型用于表示生成所述业务请求的业务的类型，所述事务类型用于表示所述业务请求所请求的事务的类型；

请求队列划分模块，用于将各所述不同类型的业务请求排入对应的请求队列，其中，所述请求队列为根据所述业务请求的类型而划分的队列；

业务请求投递模块，用于将多个所述业务请求按照对应的所述请求队列投递到同一机房中，接收多个所述请求队列的业务请求。

12.根据权利要求9-11所述的装置，其中，所述业务请求处理模块，还包括：

业务消息拆分单元，用于如果否，将所述业务请求根据所述业务请求包含内容分为多个第一业务消息；

业务消息处理单元，用于并发调用多个所述第一业务消息对应的业务操作接口。

13.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-6中任一项所述的方法。

14.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-6中任一项所述的方法。

15.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-6中任一项所述的方法。

Images