CN116126481B - 分布式长事务的处理方法及装置 - Google Patents

Abstract

本发明实施例涉及一种分布式长事务的处理方法及装置，所述方法包括：加载待处理长事务的规则文件；根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径；根据所述节点、执行条件和执行路径对长事务进行处理；当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；当节点响应超时时，通过该节点对应的补偿节点执行空补偿。本发明实施例的技术方案节点可以定义为一个服务或多个服务，也可以通过定义对应的子规则，实现嵌套事务的执行；提供了空补偿允许机制，提高了事务执行的健壮性；提供了防悬挂机制，解决了补偿服务比原服务先执行的技术问题。

Description

分布式长事务的处理方法及装置

技术领域

本发明实施例涉及数据库事务处理技术领域，尤其涉及一种分布式长事务的处理方法及装置。

背景技术

随着近些年来互联网和云计算的快速发展和普及，分布式架构的变化也日新月异。自从分布式架构逐渐向着性能、高可用、高伸缩方向发展，以及微服务技术的广泛应用，在微服务架构下分布式事务场景大量出现，如电商、社交、教育领域等。这些业务其中有一个共同的核心模块——交易模块。这部分通常是由数据库的事务来实现数据的一致性的，但是因分布式系统的规模不断扩大，同一个事务流程可能跨过多个微服务或是数据库，其事务的稳定性受到多个因素的影响：网络的稳定性、数据的一致性、微服务的稳定性，这些因素都会造成事务的失败。而事务如果失败，需要将之前成功的部分进行回滚，如果回滚失败的话，会造成数据不一致的问题，这在交易模块里是不能允许出现的问题。所以，分布式事务就是为了解决在大规模业务的分布式系统中事务的应用问题的解决方案。

目前，常用的分布式事务有三种解决方案，主要是AT模式，XA模式和TCC模式。这三种解决方案中，分别存在例如无法支持所有数据库，适用范围受限以及不支持长事务处理等缺点。

发明内容

基于现有技术的上述情况，本发明实施例的目的在于提供一种分布式长事务的处理方法及装置，具有较高的数据库兼容性并且提高了长事务处理的效率和准确性。

为达到上述目的，根据本发明的第一个方面，提供了一种分布式长事务的处理方法，包括：

加载待处理长事务的规则文件，所述规则文件包括长事务处理涉及的节点、执行条件和执行路径，所述执行路径为包含若干节点和节点对应的执行条件的有向图；

根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径，针对每个节点设置一个对应的补偿节点；

根据所述节点、执行条件和执行路径对长事务进行处理；

当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；所述反向执行包括按照反向顺序执行当前执行状态异常节点的反向顺序执行，所述回滚包括正常执行失败后进行的对等反向操作；

当节点响应超时时，通过该节点对应的补偿节点执行空补偿。

进一步的，所述方法还包括：

如果所涉及的节点包括子节点，则递归加载与该子节点对应的子规则文件。

进一步的，所述空补偿包括记录该响应超时的节点对应业务的唯一标识。

进一步的，所述反向执行已成功节点对应的补偿节点对事务进行回滚，还包括：

如果回滚又触发了回滚，或者在执行补偿节点时，对应节点的执行结果到达，则触发防悬挂机制；所述补偿节点是由对应节点的执行超时触发。

进一步的，所述防悬挂机制包括：

检查当前业务主键是否在空补偿记录的业务主键中存在；若存在，则拒绝服务的执行，所述服务为当前执行的节点中的业务。

进一步的，各所述节点和补偿节点的多次执行为幂等操作。

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

文件加载模块，用于加载待处理长事务的规则文件，所述规则文件包括长事务处理涉及的节点、执行条件和执行路径，所述执行路径为包含若干节点和节点对应的执行条件的有向图；

补偿节点设置模块，用于根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径，针对每个节点设置一个对应的补偿节点；

长事务处理模块，用于根据所述节点、执行条件和执行路径对长事务进行处理；

异常状态处理模块，用于当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；所述反向执行包括按照反向顺序执行当前执行状态异常节点的反向顺序执行，所述回滚包括正常执行失败后进行的对等反向操作；

空补偿模块，用于当节点响应超时时，通过该节点对应的补偿节点执行空补偿。

进一步的，所述文件加载模块，还用于如果所涉及的节点包括子节点，则递归加载与该子节点对应的子规则文件。

进一步的，所述空补偿包括记录该响应超时的节点对应业务的唯一标识。

进一步的，所述异常状态处理模块反向执行已成功节点对应的补偿节点对事务进行回滚，还包括：

如果回滚又触发了回滚，或者在执行补偿节点时，对应节点的执行结果到达，则触发防悬挂机制；所述补偿节点是由对应节点的执行超时触发。

综上所述，本发明实施例提供了一种分布式长事务的处理方法及装置，所述方法包括：加载待处理长事务的规则文件，所述规则文件包括长事务处理涉及的节点、执行条件和执行路径，所述执行路径为包含若干节点和节点对应的执行条件的有向图；根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径，针对每个节点设置一个对应的补偿节点；根据所述节点、执行条件和执行路径对长事务进行处理；当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；所述反向执行包括按照反向顺序执行当前执行状态异常节点的反向顺序执行，所述回滚包括正常执行失败后进行的对等反向操作；当节点响应超时时，通过该节点对应的补偿节点执行空补偿。本发明实施例的技术方案，相对于现有技术具有如下有益的技术效果：

(1)能够在一阶段进行本地事务提交，无锁高性能，且无需如TCC模式要求必须实现三个接口，只要提供对应的补偿服务即可。

(2)本发明实施例的技术方案中，节点可以定义为一个服务或多个服务，也可以通过定义对应的子规则，实现嵌套事务的执行。

(3)本发明实施例的技术方案中提供了空补偿允许机制，即没有找到要补偿的业务唯一标识时返回补偿成功并将原业务唯一标识记录下来，解决了服务超时或者丢包的问题，提高了事务执行的健壮性。

(4)本发明实施例的技术方案中提供了防悬挂机制，解决了补偿服务比原服务先执行的技术问题。

附图说明

图1是本发明一个实施例提供的分布式长事务的处理方法的实现原理示意图；

图2是本发明一个实施例提供的分布式长事务的处理方法的流程图；

图3是本发明一个实施例提供的分布式长事务的处理过程中加载后的规则流程示意图；

图4是本发明一个实施例提供的电子设备的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了，下面结合具体实施方式并参照附图，对本发明进一步详细说明。应该理解，这些描述只是示例性的，而并非要限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。

需要说明的是，除非另外定义，本发明一个或多个实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本发明一个或多个实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。

数据库事务是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。事务由事务开始与事务结束之间执行的全部数据库操作组成。

目前，常用的分布式事务有三种解决方案，主要是AT模式，XA模式和TCC模式。其中AT模式是两阶段提交的一种模式，它的一阶段进行业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。二阶段进行提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。但是它的缺点也比较令人头疼，那就是AT模式并未支持所有的SQL，它的原理是在应用层解析SQL，然后根据不同的SQL生成BeforeImage和AfterImage，一方面不同的SQL可能需要采用不同的逻辑来生成这些Image，另一方面不同的数据库语法不同，因此不常见的SQL，AT可能不支持。XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口。本地的数据库如mysql在XA中扮演的是RM角色XA一共分为两个阶段。第一阶段(prepare)：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。第二阶段(commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。它的优点是适配好，目前主流的数据库基本都支持XA事务，包括mysql、oracle、sqlserver、postgre。但是如果数据库模型里有事务不支持XA事务的话，则无法通过XA事务进行业分布式事务支持，XA事务虽适配度好，但是它的使用范围比较受限，只能使用支持XA事务的数据库。TCC则是分为以下3个阶段：

尝试(Try)阶段：尝试执行，完成所有业务检查(一致性),预留必须业务资源(准隔离性)。

确认(Confirm)阶段：如果所有分支的Try都成功了，则走到Confirm阶段。Confirm真正执行业务，不做任何业务检查，只使用Try阶段预留的业务资源。

取消(Cancel)阶段：如果所有分支的Try有一个失败了，则走到Cancel阶段。Cancel释放Try阶段预留的业务资源。从设计上，TCC可以满足处理一致性要求高、需要较多灵活性的短事务。但TCC的事务编排放在了应用端上，事务的分支总数和分支的顺序这些信息不会在推送给dtm服务器后，再去调用实际的事务分支。当应用出现crash或退出，编排信息丢失，那么整个全局事务，就没有办法前进重试，只能够进行回滚。如果全局事务持续时间很长，例如一分钟以上，那么当应用进行正常的发布升级时，也会导致全局事务回滚，影响业务。因此TCC会更适合短事务。

这3种模式总的来看，都各有各的独到之处，也有着各自的适用范围。整体上看TCC模式从适用性和性能上来讲，TCC都是比较优秀的，但是对业务的侵入性很强，而且这种模式并不能很好地被复用，会导致开发量激增。还要考虑到网络波动等原因。为保证请求一定送达所以都会有重试机制，并且考虑到接口的幂等性。XA模式使用范围比较受限，只能使用支持XA事务的数据库。而同等业务条件下，AT的性能不如XA，并且AT不支持一些不常见的SQL，一旦碰上不支持的SQL，无论是问题原因还是解决办法都非常难以处理。

本发明实施例的技术方案提供了一种分布式长事务的处理方法及装置，其目的是解决业务流程长、业务流程多的分布式事务，或参与者包含其他非自维护或遗留系统服务，无法提供TCC模式要求的三个接口。解决TCC、XA、AT模式在长事务上的短板，同时解决这三种模式使用范围相对受限的使用范围。下面结合附图对本发明的技术方案进行详细说明。本发明实施例的技术方案基于规则引擎来实现，其实现原理参照图1。在本发明实施例中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。因其实现是基于规则引擎，所以其本身还支持嵌套事务，这也是目前分布式事务模型中无法支持的。本发明的实施例，提供了一种分布式长事务的处理方法，图2中示出了该方法的流程图，所述方法包括如下步骤：

S202、加载待处理长事务的规则文件，所述规则文件包括长事务处理涉及的节点、执行条件和执行路径。本发明实施例的技术方案执行前，还可以包括预先定义规则文件的步骤，规则的组成包括条件和动作，根据条件决定流程走向。一个节点必须定义一个对应的补偿节点。该步骤本质上是针对不同的服务进行定义和编排，可以根据实际情况选择不同的编排工具。本发明实施例的技术方案中，节点是作为长事务中的最细粒度操作。执行条件是指节点向下执行中选择节点的依据，执行路径则为包含若干节点和其节点执行条件的有向图。补偿节点是其对应节点操作的反向执行。节点和补偿节点是一一对应的。如果节点没必要增加补偿节点，则用一个空节点作为补偿节点即可(空补偿节点即空有节点意义，但是没有实际执行任何动作)。规则文件与长事务一一对应，如果包含子节点，则还具有与子节点一一对应的子规则。

可以通过规则引擎加载规则文件，渲染节点和执行条件及路径，如果节点定义是子规则，则进行递归加载。加载后的规则流程见图3。节点可以配置对应的子规则，以达到嵌套事务的实现方式。

S204、根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径，针对每个节点设置一个对应的补偿节点。

S206、根据所述节点、执行条件和执行路径对长事务进行处理。

S208、当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；所述反向执行包括按照反向顺序执行当前执行状态异常节点的反向顺序执行，所述回滚包括正常执行失败后进行的对等反向操作，“已成功节点”是指该异常节点前已经执行完成的所有节点。该步骤中，规则引擎加载规则完毕后进入运行状态，当服务节点执行出现状态异常时，规则引擎进行走入对应的预定义补偿流程，反向的执行已经成功的节点对应的补偿节点会对事务进回滚。是否进行补偿，使用者也可以通过配置规则的执行动作，来决定出现异常时，是否进行补偿。

如图2所示，反向执行定义是的正常节点的反向操作，是按照反向顺序执行当前执行异常节点的反向顺序执行。以下以支付环节为例进行说明，支付环节就是一个长事务处理流程。其中支付环节可以拆分为：创建用户支付订单、银行扣款、商户查询银行扣款结果、扣款确认成功；回滚环节即和支付环节对等的反向操作，可以拆分为：取消用户支付订单(对应创建用户支付订单)、取消银行扣款(对应银行扣款)、空补偿节点1(询银行扣款结果)、空补偿节点2(扣款确认成功)。如果在节点“扣款确认成功”步骤执行失败，则进行回滚操作，首先找到节点“扣款确认成功”对应的补偿节点“空补偿节点2”，按照“空补偿节点2”->“空补偿节点1”->“取消银行扣款”->“取消用户支付订单”执行顺序进行执行。

该步骤中，反向执行已成功节点对应的补偿节点对事务进行回滚，还可以包括：如果回滚又触发了回滚，或者在执行补偿节点时，对应节点的执行结果到达，则触发防悬挂机制；所述补偿节点是由对应节点的执行超时触发。如果回滚时又触发了回滚，抑或拥挤的服务正好踩点到达，此时服务节点触发防悬挂机制。此时服务节点检查当前业务主键是否已经在空补偿记录下来的业务主键中存在，如果存在则要拒绝服务的执行。针对回滚又触发了回滚的情况，以上述的支付长事务流程举例，其中补偿节点中的“取消银行扣款”节点，实际上应该是一个子节点，其有自己的内部执行规则如果在子节点执行规则也执行失败，则满足条件“回滚又触发了回滚”。针对在执行补偿节点时，对应节点的执行结果到达的情况，仍然以上文中涉及的支付长事务流程举例，如在节点“商户查询银行扣款结果”执行超时，触发了对应的补偿节点，但在执行补偿节点时，查询结果刚好到达。其中，防悬挂机制包括：检查当前业务主键是否在空补偿记录的业务主键中存在；若存在，则拒绝服务的执行，所述服务为当前执行的节点中的业务。该步骤中，所拒绝的服务特指当前执行的节点中业务，当前业务主键特指该执行节点中记录的唯一标识。以支付流程举例，当前执行到银行扣款节点，则业务特指为银行扣款，银行支付流水单号则是当前的业务主键。

S210、当节点响应超时时，通过该节点对应的补偿节点执行空补偿。其中，所述空补偿包括记录该响应超时的节点对应业务的唯一标识。

如果全过程没触发异常和失败，则进行事务提交，至此该长事务执行完成。

根据某些可选的实施例，所述方法还包括：如果所涉及的节点包括子节点，则递归加载与该子节点对应的子规则文件。

本发明实施例提供的技术方案中，各所述节点和补偿节点的多次执行为幂等操作。幂等的含义是指：该操作无论做多少次，其结果是一致的。比如针对一个订单进行重复付款，实际只有第一次付款成功进行了扣款，其他的操作只返回付款成功，但是没有进行对应的扣款。在本发明实施例中，“做幂等”的范围是节点和补偿节点，如果因为网络原因导致正常节点执行多次，其结果能保证和一次正确操作保持一致。

本发明实施例提供的技术方案中，因节点可以并行执行多个服务，在此种条件下，数据写入异常，且回滚失败时，则无法进行补偿，因为该数据块已经丢失。此种情况，流程节点的编排一定要符合现实逻辑。有些现实场景可以允许让业务节点最终成功，在回滚不了的情况下可以继续重试完成后面的流程，所以配置的规则除了提供“回滚”能力还需要提供“向前”恢复上下文继续执行的能力，让业务最终执行成功，达到最终一致性的目的。以下以退款流程为例进行说明：如果将退款作为一个长事务流程，其包含的执行的正常节点流程为：“发起退款”->“生成退款单”->“预扣退款商户的退款金额”->“通知相应银行进行转账操作”->“退款单修改状态，由退款中变为成功”。如果在“退款单修改状态，由退款中变为成功”步骤中执行失败触发回滚，在此时银行已经将金额转给申请退款的用户，但是此时用户已经将该笔金额进行了消费，导致回滚流程中“通知相应银行进行转账操作”节点对应的回滚节点“扣除用户退款金额”动作失败，则发生了对应的经济损失。该部分就属于流程节点的编排不符合现实逻辑。现实逻辑是打款动作先执行到实际业务平台的代理账户，此处退款金额先进入用户的虚拟钱包中，等流程完成后在进行转账动作。如果在转账给用户动作中失败，可以进行对应的重试或手动提现，没有资金损失发生。

本发明的实施例，还提供了一种分布式长事务的处理装置，该装置包括：

文件加载模块，用于加载待处理长事务的规则文件，所述规则文件包括长事务处理涉及的节点、执行条件和执行路径，所述执行路径为包含若干节点和节点对应的执行条件的有向图；

补偿节点设置模块，用于根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径，针对每个节点设置一个对应的补偿节点；

长事务处理模块，用于根据所述节点、执行条件和执行路径对长事务进行处理；

异常状态处理模块，用于当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；所述反向执行包括按照反向顺序执行当前执行状态异常节点的反向顺序执行，所述回滚包括正常执行失败后进行的对等反向操作；

空补偿模块，用于当节点响应超时时，通过该节点对应的补偿节点执行空补偿。

本发明上述实施例提供的分布式长事务装置中各个模块实现其功能的具体过程与本发明上述实施例提供的分布式长事务方法的各步骤相同，因此，此处将省略其重复描述。

本发明的实施例，还提供了一种电子设备，图4所示为本发明一实施例提供的电子设备的结构示意图。如图4所示，该电子设备包括：一个或多个处理器401和存储器402；以及存储在存储器402中的计算机程序指令，计算机程序指令在被处理器401运行时使得处理器401执行如上述任一实施例的分布式长事务方法。处理器401可以是中央处理单元(CPU)或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备中的其他组件以执行期望的功能。

存储器402可以包括一个或多个计算机程序产品，计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器401可以运行程序指令，以实现上文的本发明的各个实施例的分布式长事务方法中的步骤以及/或者其他期望的功能。

在一些实施例中，电子设备还可以包括：输入装置403和输出装置404，这些组件通过总线系统和/或其他形式的连接机构(图4中未示出)互连。例如，在该电子设备是单机设备时，该输入装置403可以是通信网络连接器，用于从外部的可移动设备接收所采集的输入信号。此外，该输入设备403还可以包括例如键盘、鼠标、麦克风等。该输出装置404可以向外部输出各种信息，例如可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等。

除了上述方法和设备以外，本发明的实施例还可以是计算机程序产品，包括计算机程序指令，计算机程序指令在被处理器运行时使得处理器执行如上述任一实施例的分布式长事务方法中的步骤。

计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本发明实施例操作的程序代码，程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本发明的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，计算机程序指令在被处理器运行时使得处理器执行本发明的各个实施例的分布式长事务方法中的步骤。

计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

应当理解的是，本发明实施例中的处理器可以为中央处理单元(CentralProcessing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

综上所述，本发明实施例涉及一种分布式长事务的处理方法及装置，所述方法包括：加载待处理长事务的规则文件，所述规则文件包括长事务处理涉及的节点、执行条件和执行路径，所述执行路径为包含若干节点和节点对应的执行条件的有向图；根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径，针对每个节点设置一个对应的补偿节点；根据所述节点、执行条件和执行路径对长事务进行处理；当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；所述反向执行包括按照反向顺序执行当前执行状态异常节点的反向顺序执行，所述回滚包括正常执行失败后进行的对等反向操作；当节点响应超时时，通过该节点对应的补偿节点执行空补偿。本发明实施例的技术方案具有如下有益的技术效果：

(1)能够在一阶段进行本地事务提交，无锁高性能，且无需如TCC模式要求必须实现三个接口，只要提供对应的补偿服务即可。

(2)本发明实施例的技术方案中，节点可以定义为一个服务或多个服务，也可以通过定义对应的子规则，实现嵌套事务的执行。

(3)本发明实施例的技术方案中提供了空补偿允许机制，即没有找到要补偿的业务唯一标识时返回补偿成功并将原业务唯一标识记录下来，解决了服务超时或者丢包的问题，提高了事务执行的健壮性。

(4)本发明实施例的技术方案中提供了防悬挂机制，解决了补偿服务比原服务先执行的技术问题。

应当理解的是，以上任何实施例的讨论仅为示例性的，并非旨在暗示本发明的范围(包括权利要求)被限于这些例子；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。此外，本发明所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。

Claims (10)

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

加载待处理长事务的规则文件，所述规则文件包括长事务处理涉及的节点、执行条件和执行路径，所述节点是作为长事务中的最细粒度操作，所述执行条件是指节点向下执行中选择节点的依据，所述执行路径为包含若干节点和节点对应的执行条件的有向图；

根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径，针对每个节点设置一个对应的补偿节点；

根据所述节点、执行条件和执行路径对长事务进行处理；

当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；所述反向执行包括按照反向顺序执行当前执行状态异常节点的反向顺序执行，所述回滚包括正常执行失败后进行的对等反向操作；

当节点响应超时时，通过该节点对应的补偿节点执行空补偿。

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

如果所涉及的节点包括子节点，则递归加载与该子节点对应的子规则文件。

3.根据权利要求1所述的方法，其特征在于，所述空补偿包括记录该响应超时的节点对应业务的唯一标识。

4.根据权利要求1-3中任意一项所述的方法，其特征在于，所述反向执行已成功节点对应的补偿节点对事务进行回滚，还包括：

如果回滚又触发了回滚，或者在执行补偿节点时，对应节点的执行结果到达，则触发防悬挂机制；所述补偿节点是由对应节点的执行超时触发。

5.根据权利要求4所述的方法，其特征在于，所述防悬挂机制包括：

检查当前业务主键是否在空补偿记录的业务主键中存在；若存在，则拒绝服务的执行，所述服务为当前执行的节点中的业务。

6.根据权利要求5所述的方法，其特征在于，各所述节点和补偿节点的多次执行为幂等操作。

7.一种分布式长事务的处理装置，其特征在于，包括：

文件加载模块，用于加载待处理长事务的规则文件，所述规则文件包括长事务处理涉及的节点、执行条件和执行路径，所述节点是作为长事务中的最细粒度操作，所述执行条件是指节点向下执行中选择节点的依据，所述执行路径为包含若干节点和节点对应的执行条件的有向图；

补偿节点设置模块，用于根据所加载的规则文件渲染长事务处理涉及的节点、执行条件和路径，针对每个节点设置一个对应的补偿节点；

长事务处理模块，用于根据所述节点、执行条件和执行路径对长事务进行处理；

异常状态处理模块，用于当节点执行状态异常时，反向执行已成功节点对应的补偿节点对事务进行回滚；所述反向执行包括按照反向顺序执行当前执行状态异常节点的反向顺序执行，所述回滚包括正常执行失败后进行的对等反向操作；

空补偿模块，用于当节点响应超时时，通过该节点对应的补偿节点执行空补偿。

8.根据权利要求7所述的装置，其特征在于，所述文件加载模块，还用于如果所涉及的节点包括子节点，则递归加载与该子节点对应的子规则文件。

9.根据权利要求7所述的装置，其特征在于，所述空补偿包括记录该响应超时的节点对应业务的唯一标识。

10.根据权利要求7-9中任意一项所述的装置，其特征在于，所述异常状态处理模块反向执行已成功节点对应的补偿节点对事务进行回滚，还包括：

如果回滚又触发了回滚，或者在执行补偿节点时，对应节点的执行结果到达，则触发防悬挂机制；所述补偿节点是由对应节点的执行超时触发。