分布式事务处理方法、装置及系统与流程

本发明涉及分布式系统领域，特别涉及一种分布式事务处理方法、装置及系统。

背景技术：

分布式事务(Distributed Transaction)是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式事务处理涉及到对多个数据库的操作，分布式事务处理的关键是保持各个数据库的数据一致性。

两阶段提交协议(Two-Phase Commit protocol，2PC)是一种常见的分布式事务处理方案。2PC方案的第1阶段可称为准备阶段或投票阶段，第2阶段可称为提交阶段。在第1阶段，事务管理器向本次业务请求涉及的各个业务服务器发送数据操作请求，各个业务服务器接收到数据操作请求之后访问相应的数据库并锁定占用数据库资源，完成向数据库提交相关的业务数据的准备工作，而后业务服务器将投票结果发送给事务管理器。投票结果分为同意和中止，同意用于指示能够成功向数据库提交业务数据，中止用于指示无法成功向数据库提交业务数据。需要说明的是，在第1阶段，业务服务器并没有真正提交业务数据至数据库，仅是做了提交业务数据的准备工作。在第2阶段，事务管理器在接收到各个业务服务器返回的投票结果之后，决定统一提交或者统一回滚。如果各个业务服务器返回的投票结果均为同意，则通知各个业务服务器统一提交数据，本次业务请求成功；如果存在业务服务器返回的投票结果为中止，则通知各个业务服务器统一回滚数据，本次业务请求失败。

2PC方案采用同步方式提交业务数据，事务管理器需要等待所有的业务服务器返回投票结果以后，才能最终决定是统一提交还是统一回滚。在实际的业务场景中，一个业务请求可能会涉及到多个业务服务器，不同的业务服务器在第1阶段的响应时间存在差异，采用2PC方案需要等到响应时间最长的业务服务器返回投票结果以后，才能执行下一步操作。在此期间，所有被调用的业务服务器所对应的数据库连接和数据库资源都处于锁定占用状态，响应时间短的业务服务器返回投票结果以后，还需要继续锁定占用上述连接和资源，以等待其它业务服务器完成响应，这种等待无疑是对资源的一种浪费。

现有技术中，另一种分布式事务处理方案为TCC(Try-Commit-Cancel，准备-提交-取消)方案。TCC方案分为如下3个阶段：在第1阶段(也即Try阶段)，事务管理器向本次业务请求涉及的各个业务服务器发送事务准备消息，业务服务器接收到事务准备消息之后做业务检查并将结果反馈给事务管理器；在第2阶段(也即Commit阶段)，事务管理器向本次业务请求涉及的各个业务服务器发送事务提交消息，业务服务器接收到事务提交消息之后提交业务数据并将结果返回给事务管理器；在第3阶段(也即Cancel阶段)，事务管理器根据各个业务服务器返回的提交结果，判断是否需要执行取消操作。具体来讲：如果所有业务服务器均返回提交成功，则不需要执行取消操作，本次业务请求成功；如果所有业务服务器均返回提交失败，则也不需要执行取消操作，本次业务请求失败；如果有部分业务服务器返回提交失败，则事务管理器向各个提交成功的业务服务器发送取消操作指示，业务服务器在接收到取消操作指示之后执行数据回滚操作，本次业务请求失败。

TCC方案在Commit阶段真正提交了业务数据并实时释放了资源，因此各个业务服务器不需要长期占用资源，解决了2PC方案的资源长期占用无法释放的问题。但是，TCC方案因为引入了取消处理逻辑，导致需要为软件系统中所有的业务操作配置取消处理逻辑。如果软件系统的需求多变，业务逻辑复杂，那么对应的取消处理逻辑也会复杂多变，导致取消处理逻辑的实现成本会很高，给软件系统带来较大的开发成本，甚至对系统的可靠性和稳定性都造成影响。

技术实现要素：

为了解决现有技术中存在的问题，本发明实施例提供了一种分布式事务处理方法、装置及系统。

一方面，本发明实施例提供了一种分布式事务处理方法，应用于分布式系统中，分布式系统包括多个业务节点，各个业务节点用于执行不同的事务。该方法包括：分布式系统中的一个业务节点接收请求方设备发送的业务请求，接收到业务请求的业务节点作为主业务节点；主业务节点确定除主业务节点之外，用于处理该业务请求的N个从业务节点，N为正整数；主业务节点根据业务请求和各个从业务节点用于执行的事务，调用N个从业务节点分别执行对应的事务；主业务节点获取各个从业务节点的执行结果；若存在执行失败的从业务节点，则主业务节点根据预设重试策略重新调用执行失败的从业务节点执行对应的事务。

本发明实施例提供的方案中，通过主业务节点在获取到各个从业务节点的执行结果之后，若存在执行失败的从业务节点，则主业务节点根据预设重试策略重新调用执行失败的从业务节点执行对应的事务；一方面，采用异步方式执行事务并提交业务数据，解决了2PC方案采用同步方式提交业务数据导致资源长期占用无法释放的问题，使得数据库资源能够被更为合理有效地利用；另一方面，当事务执行失败时，根据预设重试策略重新执行该事务，由于重新执行的处理逻辑与首次执行的处理逻辑均为正向逻辑，无需配置反向的取消处理逻辑，解决了TCC方案因需要实现大量取消处理逻辑，而导致软件系统的开发成本较高的问题，减少了软件系统的开发成本，也提高了业务请求的成功率。

在一个可能的设计中，主业务节点根据预设重试策略重新调用执行失败的从业务节点执行对应的事务，包括：主业务节点根据执行失败的从业务节点在上一次执行失败时的错误类型，确定目标重试方法；主业务节点向执行失败的从业务节点发送调用请求，该调用请求中包括目标重试方法，该调用请求用于调用执行失败的从业务节点采用目标重试方法重新执行对应的事务；主业务节点接收执行失败的从业务节点发送的执行结果；若执行结果为执行失败，则主业务节点再次从上述根据执行失败的从业务节点在上一次执行失败时的错误类型，确定目标重试方法的步骤开始执行。

通过上述方式，主业务节点根据上一次执行失败时的错误类型选择合适的重试方法进行重试，有助于提升重试成功率。

在一个可能的设计中，主业务节点根据执行失败的从业务节点在上一次执行失败时的错误类型，确定目标重试方法，包括：主业务节点获取与执行失败的从业务节点在上一次执行失败时的错误类型相对应的重试方法集合，重试方法集合中包括至少一种重试方法；主业务节点根据重试方法集合中的每一种重试方法的优先级和最大重试次数，从可选择的重试方法中选取优先级最高的重试方法作为目标重试方法；其中，可选择的重试方法是指实际重试次数小于其最大重试次数的重试方法，实际重试次数是指因上一次执行失败时的错误类型而采用该重试方法重新执行事务的已执行次数。

本发明实施例提供的重试策略，通过为每一个错误类型和重试方法的组合配置相应的优先级和最大重试次数，以确保选取最优的重试方法重新执行事务，有助于提高重试的成功率和效率。

在一个可能的设计中，所述方法还包括：主业务节点统计每一个错误类型和重试方法的组合所对应的成功率；其中，目标组合是指目标错误类型和目标重试方法的组合，目标组合所对应的成功率是指因目标错误类型而采用目标重试方法重新执行事务的总次数中执行成功的次数与总次数的比值；主业务节点根据各个组合所对应的成功率，更新各种错误类型所对应的重试方法集合中的每一种重试方法的优先级。

在本发明实施例中，还通过统计每一个错误类型和重试方法的组合所对应的成功率，根据各个组合所对应的成功率，更新各种错误类型所对应的重试方法集合中的每一种重试方法的优先级，使得重试方法的优先级更为准确，为提高重试的成功率和效率提供可靠保障。

在一个可能的设计中，主业务节点根据各个组合所对应的成功率，更新各种错误类型所对应的重试方法集合中的每一种重试方法的优先级，包括：对于目标组合，主业务节点判断因目标错误类型而采用目标重试方法重新执行事务的总次数是否大于预设阈值；若总次数大于所述预设阈值，则主业务节点根据目标组合所对应的成功率，更新目标错误类型所对应的重试方法集合中的目标重试方法的优先级。

通过上述方式，确保选取有效的、具有参考价值的数据，保证优先级更新的准确性。

在一个可能的设计中，调用请求中还包括：根据业务请求和执行失败的从业务节点用于执行的事务所生成的事务消息，以及事务消息的标识。

通过上述方式，以使得从业务节点在接收到调用请求之后，检测是否存储有与标识相对应的执行结果，若已存储有与标识相对应的执行结果且执行结果为执行成功，则从业务节点向主业务节点发送与标识相对应的执行结果。本发明实施例还提供了重试幂等机制，针对从业务节点已成功执行事务，但因某些特殊原因导致主业务节点认为该事务执行失败，而再次调用从业务节点执行该事务的情况，从业务节点在接收到主业务节点发送的调用请求之后，首先判断该调用请求所请求执行的事务之前是否已成功执行，若已成功执行则不重复执行该事务，保证了每一次重试调用的幂等性，充分确保了系统的可靠性。

在一个可能的设计中，主业务节点根据业务请求和各个所述从业务节点用于执行的事务，调用N个从业务节点分别执行对应的事务之前，还包括：主业务节点根据业务请求，执行主业务节点对应的事务；若主业务节点执行成功，则主业务节点从上述根据业务请求和各个从业务节点用于执行的事务，调用N个从业务节点分别执行对应的事务的步骤开始执行。可选地，主业务节点根据业务请求，执行主业务节点对应的事务之后，还包括：若主业务节点执行失败，则主业务节点向请求方设备发送失败响应。

主业务节点在从请求方设备接收到业务请求之后，采用同步方式执行本端对应的事务并提交业务数据，而从业务节点采用异步方式各自执行对应的事务并提交业务数据，主业务节点根据其自身的事务执行结果即向请求方设备反馈业务响应，不需要等待其它从业务节点的事务执行结果，使得业务响应时间相对于2PC方案和TCC方案明显缩短。

在一个可能的设计中，主业务节点确定除主业务节点之外，用于处理业务请求的N个从业务节点之后，还包括：主业务节点在调用N个从业务节点分别执行对应的事务的过程中，根据业务请求执行主业务节点对应的事务。可选地，主业务节点根据业务请求执行主业务节点对应的事务之后，还包括：若主业务节点执行失败，则主业务节点根据预设重试策略重新执行主业务节点对应的事务。

当主业务节点和各个从业务节点均采用异步方式执行事务并提交数据时，主业务节点可在接收到请求方设备发送的业务请求之后即向请求方设备发送成功响应，能够进一步缩短业务响应时间。

另一方面，本发明实施例提供了一种分布式事务处理方法，应用于分布式系统中，分布式系统包括多个业务节点，各个业务节点用于执行不同的事务。该方法包括：分布式系统中的从业务节点接收主业务节点发送的调用请求；其中，主业务节点是指分布式系统中接收到请求方设备发送的业务请求的一个业务节点，从业务节点是所述主业务节点确定的用于处理该业务请求的多个业务节点中的一个；调用请求是主业务节点已调用从业务节点执行对应的事务，但判定从业务节点执行失败后根据预设重试策略再次发送的；从业务节点根据调用请求，执行从业务节点对应的事务；从业务节点向主业务节点发送执行结果。

本发明实施例提供的方案中，通过主业务节点在判定从业务节点执行对应的事务失败后根据预设重试策略再次向从业务节点发送调用请求，从业务节点根据该调用请求，再次执行从业务节点对应的事务；一方面，采用异步方式执行事务并提交业务数据，解决了2PC方案采用同步方式提交业务数据导致资源长期占用无法释放的问题，使得数据库资源能够被更为合理有效地利用；另一方面，当事务执行失败时，根据预设重试策略重新执行该事务，由于重新执行的处理逻辑与首次执行的处理逻辑均为正向逻辑，无需配置反向的取消处理逻辑，解决了TCC方案因需要实现大量取消处理逻辑，而导致软件系统的开发成本较高的问题，减少了软件系统的开发成本，也提高了业务请求的成功率。

在一个可能的设计中，调用请求中包括目标重试方法，目标重试方法是根据从业务节点在上一次执行失败时的错误类型确定的。从业务节点根据调用请求，执行从业务节点对应的事务，包括：从业务节点根据调用请求，采用目标重试方法执行从业务节点对应的事务。

通过上述方式，主业务节点根据上一次执行失败时的错误类型选择合适的重试方法进行重试，有助于提升重试成功率。

在一个可能的设计中，调用请求中还包括：根据业务请求和从业务节点用于执行的事务所生成的事务消息，以及事务消息的标识。从业务节点根据调用请求，执行从业务节点对应的事务之前，还包括：从业务节点检测是否存储有与标识相对应的执行结果；若已存储有与标识相对应的执行结果且执行结果为执行成功，则从业务节点向主业务节点发送与标识相对应的执行结果。

本发明实施例还提供了重试幂等机制，针对从业务节点已成功执行事务，但因某些特殊原因导致主业务节点认为该事务执行失败，而再次调用从业务节点执行该事务的情况，从业务节点在接收到主业务节点发送的调用请求之后，首先判断该调用请求所请求执行的事务之前是否已成功执行，若已成功执行则不重复执行该事务，保证了每一次重试调用的幂等性，充分确保了系统的可靠性。

又一方面，本发明实施例提供一种分布式事务处理装置，该装置具有实现上述方法示例中主业务节点侧行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元。

在一个可能的设计中，主业务节点的结构中包括处理器、发射器和接收器，所述处理器被配置为支持主业务节点执行上述方法中相应的功能。所述发射器和接收器用于支持主业务节点与其它业务节点之间的通信。进一步的，主业务节点还可以包括存储器，所述存储器用于与处理器耦合，其保存主业务节点必要的程序指令和数据。

又一方面，本发明实施例提供一种分布式事务处理装置，该装置具有实现上述方法示例中从业务节点侧行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的单元。

在一个可能的设计中，从业务节点包括处理器、接收器和发射器，所述处理器被配置为支持从业务节点执行上述方法中相应的功能。所述接收器和发射器用于支持从业务节点与主业务节点之间的通信。进一步的，从业务节点还可以包括存储器，所述存储器用于与处理器耦合，其保存从业务节点必要的程序指令和数据。

又一方面，本发明实施例提供一种分布式事务处理系统，该分布式系统包括多个业务节点，各个业务节点用于执行不同的事务。每一个业务节点，包括：如上述方面所述的分布式业务处理装置。

再一方面，本发明实施例提供一种计算机存储介质，用于储存为上述用于主业务节点所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

再一方面，本发明实施例提供一种计算机存储介质，用于储存为上述用于从业务节点所用的计算机软件指令，其包含用于执行上述方面所设计的程序。

相较于现有技术，本发明实施例的方案中，提供了一种新的分布式事务处理方案，也即TCR(Try-Commit-Redo，准备-提交-重试)方案。一方面，采用异步方式执行事务并提交业务数据，解决了2PC方案采用同步方式提交业务数据导致资源长期占用无法释放的问题，使得数据库资源能够被更为合理有效地利用；另一方面，当事务执行失败时，根据预设重试策略重新执行该事务，由于重新执行的处理逻辑与首次执行的处理逻辑均为正向逻辑，无需配置反向的取消处理逻辑，解决了TCC方案因需要实现大量取消处理逻辑，而导致软件系统的开发成本较高的问题，减少了软件系统的开发成本，也提高了业务请求的成功率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本发明实施例提供的一种可能的应用场景的示意图；

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

图2B是图2A所示实施例涉及的步骤208的流程图；

图2C示出了错误类型与重试方法之间的对应关系的示意图；

图3A是本发明一个实施例提供的分布式事务处理装置的框图；

图3B是本发明另一实施例提供的分布式事务处理装置的框图；

图3C是本发明另一实施例提供的分布式事务处理装置的框图；

图3D是本发明另一实施例提供的分布式事务处理装置的框图；

图4A是本发明另一实施例提供的分布式事务处理装置的框图；

图4B是本发明另一实施例提供的分布式事务处理装置的框图；

图5是本发明一个实施例提供的业务节点的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

本发明实施例描述的网络架构以及业务场景是为了更加清楚地说明本发明实施例的技术方案，并不构成对本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。

图1示出了本发明实施例提供的一种可能的应用场景的示意图。该应用场景可以是分布式系统，该应用场景包括：多个业务节点。

在本发明实施例中，主业务节点可以是分布式系统中的任一个业务节点。示意性地，如图1所示，主业务节点以标号110表示。在分布式系统中，接收到请求方设备发送的业务请求的业务节点，即作为主业务节点。分布式系统中除主业务节点110之外的其它业务节点以标号120表示。业务节点可以是一台服务器，也可以是由多台服务器组成的服务器集群，或者是一台服务器中的一个独立的计算处理单元。各个业务节点之间通过网络建立通信连接。

分布式系统中的各个业务节点用于执行不同的事务。例如，以分布式系统实现成为CRM(Customer Relationship Management，客户关系管理)系统为例，CRM系统用于为电信运营商提供客户关系管理服务，具体包括开户、停开机、改产品、销户等服务。按照微服务架构方法，CRM系统分为订单管理、客户管理、资源管理、产品管理、合作伙伴管理、系统管理等多个子服务，每个子服务的数据都保存在不同的数据库实例上。在微服务部署时，一次业务请求可能会同时涉及多个子服务的调用和数据修改。

可选地，每一个业务节点包括：业务受理器、事务管理器和事务处理器。其中，业务受理器用于接收请求方设备发送的业务请求，确定除本端之外用于处理该业务请求的其它业务节点，根据该业务请求和各个其它业务节点用于执行的事务，生成每个其它业务节点各自对应的事务消息，并将生成的事务消息存储至事务管理器中。事务管理器用于对事务消息进行管理。在一个示例中，事务管理器包括：事务消息队列、失败重试队列和历史消息队列。事务消息队列用于保存从业务受理器接收到的事务消息。失败重试队列用于保存执行结果为失败的事务消息。历史消息队列用于保存执行结果为成功的事务消息。事务处理器用于根据业务请求执行本端对应的事务，例如执行数据修改等操作。

当业务节点作为主业务节点时，业务受理器具备下述装置示例中接收单元和确定单元的功能；事务管理器具备下述装置示例中调用单元、获取单元和重新调用单元的功能，可选地，事务管理器还具备下述装置示例中统计单元和更新单元的功能；事务处理器具备下述装置示例中同步执行单元和发送单元的功能，或者，事务处理器具备下述装置示例中异步执行单元和重新执行单元的功能。当业务节点作为从业务节点时，事务处理器具备下述装置示例中接收单元、处理单元和发送单元的功能，可选地，事务处理器还具备下述装置示例中检测单元的功能。

在现有技术中，TCC方案虽然能够解决2PC方案所存在的资源长期占用无法释放的问题，但TCC方案因为引入了取消处理逻辑，仍然存在上文介绍的一些问题。基于此，本发明实施例提供一种分布式事务处理方法，和基于这个方法的装置及系统。本发明实施例提供的技术方案，核心思想是提供一种新的分布式事务处理方案，也即TCR方案，以解决现有技术存在的问题。TCR方案分为如下3个阶段：在第1阶段(也即Try阶段)，事务管理器向本次业务请求涉及的各个业务服务器发送事务准备消息，业务服务器接收到事务准备消息之后做业务检查并将结果反馈给事务管理器；在第2阶段(也即Commit阶段)，事务管理器向本次业务请求涉及的各个业务服务器发送事务提交消息，业务服务器接收到事务提交消息之后提交业务数据并将结果返回给事务管理器；在第3阶段(也即Redo阶段)，事务管理器根据各个业务服务器返回的提交结果，判断是否需要执行重试操作。具体来讲：如果所有业务服务器均返回提交成功，则不需要执行重试操作，本次业务请求成功；如果存在业务服务器返回提交失败，则事务管理器向各个提交失败的业务服务器发送重试指示，业务服务器在接收到重试指示之后重新执行对应的事务。

另外，在本发明实施例中，同步方式是指执行一项操作之前，需要等待上一项操作执行完成；异步方式是指执行一项操作之前，无需等待上一项操作执行完成。

下面将基于上面所述的本发明实施例涉及的共性方面，对本发明实施例进一步详细说明。

图2A是本发明一个实施例提供的分布式事务处理方法的流程图。该方法可应用于图1所示的应用场景中。该方法可以包括如下步骤。

步骤201，分布式系统中的一个业务节点接收请求方设备发送的业务请求，接收到该业务请求的业务节点作为主业务节点。

分布式系统包括多个业务节点，各个业务节点用于执行不同的事务。在本发明实施例中，对分布式系统所提供的服务不作限定。例如，分布式系统可用于为电信运营商提供客户关系管理服务。该分布式系统中可包括：用于提供订单管理子服务的业务节点、用于提供客户管理子服务的业务节点、用于提供资源管理子服务的业务节点、用于提供产品管理子服务的业务节点、用于提供合作伙伴管理子服务的业务节点、用于提供系统管理子服务的业务节点，等等。每个业务节点有各自对应的数据库实例，不同业务节点的数据保存在不同的数据库实例上。

业务请求用于请求分布式系统所提供的一项或多项子服务。在本发明实施例中，仅针对请求多项子服务的情况所涉及的事务处理流程进行介绍说明。在本发明实施例中，主业务节点是指分布式系统中接收到请求方设备发送的业务请求的一个业务节点。例如，假设用于提供订单管理子服务的业务节点接收到请求方设备发送的订单创建请求，则该业务节点即为主业务节点。

步骤202，主业务节点根据业务请求，执行主业务节点对应的事务。

在本发明实施例中，主业务节点对应的事务采用同步方式执行。若主业务节点执行成功，则主业务节点向请求方设备发送成功响应，并执行下述步骤204。若主业务节点执行失败，则主业务节点向请求方设备发送失败响应。

以主业务节点为上述用于提供订单管理子服务的业务节点为例，主业务节点根据订单创建请求创建订单；若订单创建成功，则主业务节点向请求方设备发送成功响应，并执行下述步骤204；若订单创建失败，则主业务节点向请求方设备发送失败响应。

通过上述方式，能够使得主业务节点采用同步方式执行事务并提交数据，尽可能地保证数据一致性。

步骤203，主业务节点确定除主业务节点之外，用于处理该业务请求的N个从业务节点，N为正整数。

主业务节点根据业务请求和各个从业务节点用于执行的事务，确定除其自身之外用于处理该业务请求的N个其它业务节点，该N个其它业务节点称为N个从业务节点。

仍然以主业务节点为上述用于提供订单管理子服务的业务节点为例，主业务节点确定除其自身之外，用于提供客户管理子服务的业务节点和用于提供资源管理子服务的业务节点也用于处理该业务请求。其中，用于提供客户管理子服务的业务节点用于在订单创建成功之后修改用户信息，用于提供资源管理子服务的业务节点用于在订单创建成功之后存储用户与订单之间的对应关系。

另外，在本实施例中，对上述步骤202和步骤203的执行顺序不作限定。步骤202可以在步骤203之前执行，也可在步骤203之后执行，或者与步骤203同时执行。

步骤204，主业务节点根据业务请求和各个从业务节点用于执行的事务，调用N个从业务节点分别执行对应的事务。

在一个示例中，主业务节点包括业务受理器、事务管理器和事务处理器。业务受理器根据业务请求和各个从业务节点用于执行的事务，生成每个从业务节点各自对应的事务消息，并将生成的事务消息存储至事务管理器的事务消息队列中。事务管理器从事务消息队列中依次读取事务消息，生成携带有事务消息的调用请求，并将生成的调用请求发送给对应的从业务节点。

例如，主业务节点的业务受理器生成第一事务消息和第二事务消息；其中，第一事务消息用于指示上述用于提供客户管理子服务的业务节点在订单创建成功之后修改用户信息；第二事务消息用于指示上述用于提供资源管理子服务的业务节点在订单创建成功之后存储用户与订单之间的对应关系。主业务节点的业务受理器将第一事务消息和第二事务消息存储至事务管理器的事务消息队列中。事务管理器从事务消息队列中读取第一事务消息，生成携带有第一事务消息的第一调用请求，并将第一调用请求发送给上述用于提供客户管理子服务的业务节点；事务管理器从事务消息队列中读取第二事务消息，生成携带有第二事务消息的第二调用请求，并将第二调用请求发送给上述用于提供资源管理子服务的业务节点。

步骤205，从业务节点根据调用请求，执行从业务节点对应的事务。

对于每一个从业务节点，从业务节点接收到调用请求之后，根据调用请求中携带的事务消息，执行从业务节点对应的事务。

步骤206，从业务节点向主业务节点发送执行结果。

相应地，主业务节点获取各个从业务节点的执行结果。其中，执行结果为执行成功的指示信息或执行失败的指示信息。

在一个示例中，主业务节点的事务管理器获取到任一从业务节点的执行结果之后，若执行结果为执行成功，则主业务节点将相应的事务消息添加至历史消息队列中；如执行结果为执行失败，则主业务节点将相应的事务消息添加至失败重试队列中，后续从失败执行队列中依次读取事务消息以进行重试。

步骤207，主业务节点检测是否存在执行失败的从业务节点。

主业务节点根据各个从业务节点反馈的执行结果，检测是否存在执行失败的从业务节点。

步骤208，若存在执行失败的从业务节点，则主业务节点根据预设重试策略重新调用执行失败的从业务节点执行对应的事务。

在本发明实施例中，采用TCR方案，对于执行失败的从业务节点，主业务节点根据预设重试策略进行失败重试。预设重试策略是指预先设定的失败重试的方案。

在一个示例中，如图2B所示，本步骤包括如下几个子步骤：

步骤208a，主业务节点根据执行失败的从业务节点在上一次执行失败时的错误类型，确定目标重试方法；

在本发明实施例中，预先设定错误类型与重试方法之间的对应关系。其中，错误类型是指导致业务节点执行事务失败的错误所属的类型。示例性地，错误类型包括但不限于：网络连接错误、超时错误、服务不存在错误、业务错误等。在实际应用中，可根据实际需求预先设定多种不同的错误类型，本发明实施例对此不作限定。重试方法是指业务节点重新执行对应的事务时所采用的方法。示例性地，重试方法包括但不限于：寻找心跳响应时间最小的处理节点重新执行对应的事务、轮询集群中心跳健康的处理节点重新执行对应的事务、发送告警通过人工接入方式实现重新执行对应的事务，等等。其中，处理节点是指业务节点用于处理对应的事务的最小处理单元，在通常情况下，一个业务节点包括多个处理节点，每一个处理节点均可用于执行该业务节点所用于执行的事务。在实际应用中，可根据实际需求预先设定多种不同的重试方法，本发明实施例对此不作限定。每一种错误类型可对应于一种或多种重试方法。示例性地，如图2C所示，其示出了错误类型与重试方法之间的对应关系的示意图。

在一个示例中，步骤208a包括如下几个子步骤：

1、主业务节点获取与执行失败的从业务节点在上一次执行失败时的错误类型相对应的重试方法集合，该重试方法集合中包括至少一种重试方法；

2、主业务节点根据重试方法集合中的每一种重试方法的优先级和最大重试次数，从可选择的重试方法中选取优先级最高的重试方法作为目标重试方法；

其中，可选择的重试方法是指实际重试次数小于其最大重试次数的重试方法，实际重试次数是指因上一次执行失败时的错误类型而采用重试方法重新执行事务的已执行次数。在本发明实施例中，对于每一个错误类型和重试方法的组合(记为一条配置项)，设置对应的权重和最大重试次数；其中，权重用于指示该条配置项的优先级，最大重试次数用于指示该条配置项重新派发的最大次数。示例性地，以错误类型为网络连接错误为例，上述相关参数可如下表-1所示：

表-1

如果执行失败的从业务节点在上一次执行失败时的错误类型为网络连接错误，则主业务节点优先选择的重试方法为轮询集群中心跳健康的处理节点重新执行对应的事务，如果该重试方法的实际重试次数超过了最大重试次数，则不再使用该重试方法，选择另一优先级较低的重试方法，也即发送告警通过人工接入方式实现重新执行对应的事务。由于每次重新执行对应的事务之后，导致执行失败的错误类型都有可能发生变化，在选取重试方法时，以上一次执行失败时的错误类型(也即最后一次执行失败时的错误类型)为准。

步骤208b，主业务节点向执行失败的从业务节点发送调用请求，该调用请求中包括目标重试方法，该调用请求用于调用执行失败的从业务节点采用目标重试方法重新执行对应的事务；

相应地，执行失败的从业务节点在接收到该调用请求之后，采用目标重试方法重新执行对应的事务，并将执行结果发送给主业务节点。

步骤208c，主业务节点接收执行失败的从业务节点发送的执行结果；

步骤208d，主业务节点判断执行结果是否为执行成功。若是，则结束流程；若否，则再次从上述步骤208a开始执行。

在本发明实施例中，通过采用上文介绍的重试策略，为每一个错误类型和重试方法的组合配置相应的优先级和最大重试次数，以确保选取最优的重试方法重新执行事务，有助于提高重试的成功率和效率。

可选地，调用请求中还包括：根据业务请求和执行失败的从业务节点用于执行的事务所生成的事务消息，以及该事务消息的标识。其中，事务消息由业务受理器在接收到业务请求之后生成。事务消息的标识用于唯一标识事务消息，不同的事务消息其标识也不同。事务消息的标识可以由业务受理器为分配，也可由事务管理器分配。

在一个示例中，从业务节点根据调用请求执行从业务节点对应的事务之前，还包括：从业务节点检测是否存储有与调用请求中携带的事务消息的标识相对应的执行结果；若已存储有与该标识相对应的执行结果且执行结果为执行成功，则从业务节点向主业务节点发送与标识相对应的执行结果；若未存储有与该标识相对应的执行结果，或者已存储有与该标识相对应的执行结果且执行结果为执行失败，则从业务节点根据调用请求执行从业务节点对应的事务。

在本发明实施例中，提供了重试幂等机制，针对从业务节点已成功执行事务，但因某些特殊原因导致主业务节点认为该事务执行失败，而再次调用从业务节点执行该事务的情况，从业务节点在接收到主业务节点发送的调用请求之后，首先判断该调用请求所请求执行的事务之前是否已成功执行，若已成功执行则不重复执行该事务，保证了每一次重试调用的幂等性，充分确保了系统的可靠性。例如，从业务节点已成功执行事务，但因网络连接问题，从业务节点并未成功向主业务节点发送用于指示执行成功的执行结果，在这种情况下，主业务节点会判定从业务节点执行失败，后续会重新调用该从业务节点执行对应的事务。如果从业务节点接收到主业务节点再次发来的调用请求之后，再执行一次对应的事务，则会导致已成功执行的事务被重复执行，会产生数据被重复修改等问题。从业务节点在根据调用请求执行完成对应的事务之后，将执行结果和事务消息的标识对应存储，在接收到主业务节点发来的调用请求之后，根据调用请求中携带的事务消息的标识判断是否有必要执行该调用请求所请求执行的事务，能够使得已成功执行的事务不重复执行。

可选地，本实施例提供的方法还包括如下步骤：

1、主业务节点统计每一个错误类型和重试方法的组合所对应的成功率；

其中，目标组合是指目标错误类型和目标重试方法的组合，目标组合所对应的成功率是指因目标错误类型而采用目标重试方法重新执行事务的总次数中执行成功的次数与总次数的比值；

2、主业务节点根据各个组合所对应的成功率，更新各种错误类型所对应的重试方法集合中的每一种重试方法的优先级。

系统经过一段时间的运行之后，会存在大量的历史重试记录。通过指定对象对历史重试记录进行统计，计算出每一个错误类型和重试方法的组合所对应的成功率，并根据该成功率更新该组合对应的优先级，例如将该成功率作为该组合对应的权重。通过上述方式，能够使得重试方法的优先级更为准确，为提高重试的成功率和效率提供可靠保障。

在一个示例中，对于目标组合，主业务节点判断因目标错误类型而采用目标重试方法重新执行事务的总次数是否大于预设阈值；若上述总次数大于预设阈值，则主业务节点根据目标组合所对应的成功率，更新目标错误类型所对应的重试方法集合中的目标重试方法的优先级；若上述总次数小于或等于预设阈值，则主业务节点不执行上述更新操作，保持目标重试方法的优先级不变。通过上述方式，确保选取有效的、具有参考价值的数据，保证优先级更新的准确性。

另外，在本发明实施例中，仅以主业务节点进行上述统计和更新为例，在实际应用中，分布式系统中的任意一个业务节点均可具备上述统计和更新的功能，或者也可通过系统中的一个特定功能实体以实现上述统计和更新的功能。

综上所述，本实施例提供的方法，通过主业务节点在判定从业务节点执行对应的事务失败后根据预设重试策略再次向从业务节点发送调用请求，从业务节点根据该调用请求，再次执行从业务节点对应的事务；一方面，采用异步方式执行事务并提交业务数据，解决了2PC方案采用同步方式提交业务数据导致资源长期占用无法释放的问题，使得数据库资源能够被更为合理有效地利用；另一方面，当事务执行失败时，根据预设重试策略重新执行该事务，由于重新执行的处理逻辑与首次执行的处理逻辑均为正向逻辑，无需配置反向的取消处理逻辑，解决了TCC方案因需要实现大量取消处理逻辑，而导致软件系统的开发成本较高的问题，减少了软件系统的开发成本，也提高了业务请求的成功率。

另外，主业务节点在从请求方设备接收到业务请求之后，采用同步方式执行本端对应的事务并提交业务数据，而从业务节点采用异步方式各自执行对应的事务并提交业务数据，主业务节点根据其自身的事务执行结果即向请求方设备反馈业务响应，不需要等待其它从业务节点的事务执行结果，使得业务响应时间相对于2PC方案和TCC方案明显缩短。

另外，本发明实施例提供的重试策略，通过为每一个错误类型和重试方法的组合配置相应的优先级和最大重试次数，以确保选取最优的重试方法重新执行事务，有助于提高重试的成功率和效率。

另外，在本发明实施例中，还通过统计每一个错误类型和重试方法的组合所对应的成功率，根据各个组合所对应的成功率，更新各种错误类型所对应的重试方法集合中的每一种重试方法的优先级，使得重试方法的优先级更为准确，为提高重试的成功率和效率提供可靠保障。

另外，本发明实施例还提供了重试幂等机制，针对从业务节点已成功执行事务，但因某些特殊原因导致主业务节点认为该事务执行失败，而再次调用从业务节点执行该事务的情况，从业务节点在接收到主业务节点发送的调用请求之后，首先判断该调用请求所请求执行的事务之前是否已成功执行，若已成功执行则不重复执行该事务，保证了每一次重试调用的幂等性，充分确保了系统的可靠性。

需要说明的一点是，在上述图2A所示实施例中，主业务节点采用同步方式执行事务并提交数据，各个从业务节点采用异步方式执行事务并提交数据。在一个可选实施例中，主业务节点和各个从业务节点均可采用异步方式执行事务并提交数据。主业务节点在调用N个从业务节点分别执行对应的事务的过程中，根据业务请求执行主业务节点对应的事务。在一个示例中，主业务节点的业务受理器在接收到业务请求之后，还根据业务请求和主业务节点用于执行的事务，生成主业务节点对应的事务消息，并将生成的事务消息存储至事务管理器的事务消息队列中。通过上述方式，实现主业务节点和各个从业务节点均采用异步方式执行事务并提交数据。

另外，主业务节点根据业务请求执行主业务节点对应的事务之后，还包括：若主业务节点执行失败，则主业务节点根据预设重试策略重新执行主业务节点对应的事务。其中，主业务节点进行失败重试的过程与上文介绍的从业务节点进行失败重试的过程相同，参见上文介绍和说明，此处不再赘述。

可选地，当主业务节点和各个从业务节点均采用异步方式执行事务并提交数据时，主业务节点可在接收到请求方设备发送的业务请求之后即向请求方设备发送成功响应，能够进一步缩短业务响应时间。

下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。

图3A是本发明一个实施例提供的分布式事务处理装置的框图。该装置是位于分布式系统中的一个业务节点。该装置具有实现上述方法示例中主业务节点侧的功能，所述装置可以通过硬件实现，也可通过硬件执行相应的软件实现。该装置可以包括：接收单元310、确定单元320、调用单元330、获取单元340和重新调用单元350。

接收单元310，用于接收请求方设备发送的业务请求，接收到所述业务请求的所述装置为主业务节点。

确定单元320，用于确定除所述主业务节点之外，用于处理所述业务请求的N个从业务节点，所述N为正整数。

调用单元330，用于根据所述业务请求和各个所述从业务节点用于执行的事务，调用所述N个从业务节点分别执行对应的事务。

获取单元340，用于获取各个所述从业务节点的执行结果。

重新调用单元350，用于当存在执行失败的从业务节点时，根据所述预设重试策略重新调用所述执行失败的从业务节点执行对应的事务。

综上所述，本实施例提供的装置，通过主业务节点在获取到各个从业务节点的执行结果之后，若存在执行失败的从业务节点，则主业务节点根据预设重试策略重新调用执行失败的从业务节点执行对应的事务；一方面，采用异步方式执行事务并提交业务数据，解决了2PC方案采用同步方式提交业务数据导致资源长期占用无法释放的问题，使得数据库资源能够被更为合理有效地利用；另一方面，当事务执行失败时，根据预设重试策略重新执行该事务，由于重新执行的处理逻辑与首次执行的处理逻辑均为正向逻辑，无需配置反向的取消处理逻辑，解决了TCC方案因需要实现大量取消处理逻辑，而导致软件系统的开发成本较高的问题，减少了软件系统的开发成本，也提高了业务请求的成功率。

其中，接收单元310的具体功能可参见上述方法示例中步骤201的相关内容；确定单元320的具体功能可参见上述方法示例中步骤203的相关内容；调用单元330的具体功能可参见上述方法示例中步骤204的相关内容；获取单元340的具体功能可参见上述方法示例中步骤206的相关内容；重新调用单元350的具体功能可参见上述方法示例中步骤208的相关内容。

可选地，如图3B所示，所述装置还包括：统计单元360和更新单元370。

统计单元360，用于统计每一个错误类型和重试方法的组合所对应的成功率；其中，目标组合是指目标错误类型和目标重试方法的组合，所述目标组合所对应的成功率是指因所述目标错误类型而采用所述目标重试方法重新执行事务的总次数中执行成功的次数与所述总次数的比值。

更新单元370，用于根据各个所述组合所对应的成功率，更新各种错误类型所对应的重试方法集合中的每一种重试方法的优先级。

统计单元360和更新单元370的具体功能可参见上述方法示例中的相关内容。

在基于图3A所示实施例提供的另一可选实施例中，如图3C所示，所述装置还包括：同步执行单元312。

同步执行单元312，用于根据所述业务请求，执行所述主业务节点对应的事务。同步执行单元312的具体功能可参见上述方法示例中步骤402的相关内容。

所述调用单元330，还用于当所述主业务节点执行成功时，则执行所述根据所述业务请求和各个所述从业务节点用于执行的事务，调用所述N个从业务节点分别执行对应的事务的步骤。

可选地，所述装置还包括：发送单元314。

发送单元314，用于当所述主业务节点执行失败时，向所述请求方设备发送失败响应。

在基于图3A所示实施例提供的另一可选实施例中，如图3D所示，所述装置还包括：异步执行单元332。

异步执行单元332，用于在调用所述N个从业务节点分别执行对应的事务的过程中，根据所述业务请求执行所述主业务节点对应的事务。

可选地，所述装置还包括：重新执行单元334。

重新执行单元334，用于当所述主业务节点执行失败时，根据所述预设重试策略重新执行所述主业务节点对应的事务。

图4A是本发明另一实施例提供的分布式事务处理装置的框图。该装置是位于分布式系统中的一个业务节点。该装置具有实现上述方法示例中从业务节点侧的功能，所述装置可以通过硬件实现，也可通过硬件执行相应的软件实现。该装置可以包括：接收单元410、处理单元420和发送单元430。

接收单元410，用于接收主业务节点发送的调用请求。其中，所述主业务节点是指所述分布式系统中接收到请求方设备发送的业务请求的一个业务节点，所述装置是所述主业务节点确定的用于处理所述业务请求的多个从业务节点中的一个。所述调用请求是所述主业务节点已调用所述从业务节点执行对应的事务，但判定所述从业务节点执行失败后根据预设重试策略再次发送的。

处理单元420，用于根据所述调用请求，执行所述装置对应的事务。

发送单元430，用于向所述主业务节点发送执行结果。

综上所述，本实施例提供的装置，通过主业务节点在判定从业务节点执行对应的事务失败后根据预设重试策略再次向从业务节点发送调用请求，从业务节点根据该调用请求，再次执行从业务节点对应的事务；一方面，采用异步方式执行事务并提交业务数据，解决了2PC方案采用同步方式提交业务数据导致资源长期占用无法释放的问题，使得数据库资源能够被更为合理有效地利用；另一方面，当事务执行失败时，根据预设重试策略重新执行该事务，由于重新执行的处理逻辑与首次执行的处理逻辑均为正向逻辑，无需配置反向的取消处理逻辑，解决了TCC方案因需要实现大量取消处理逻辑，而导致软件系统的开发成本较高的问题，减少了软件系统的开发成本，也提高了业务请求的成功率。

在基于图4A所示实施例提供的一个可选实施例中，所述调用请求中包括目标重试方法，所述目标重试方法是根据所述装置在上一次执行失败时的错误类型确定的。

所述处理单元420，具体用于：根据所述调用请求，采用所述目标重试方法执行所述装置对应的事务。

在基于图4A所示实施例提供的另一可选实施例中，所述调用请求中还包括：根据所述业务请求和所述装置用于执行的事务所生成的事务消息，以及所述事务消息的标识。

如图4B所示，所述装置还包括：检测单元440。

检测单元440，用于检测是否存储有与所述标识相对应的执行结果。

所述发送单元430，还用于当已存储有与所述标识相对应的执行结果且所述执行结果为执行成功时，向所述主业务节点发送与所述标识相对应的执行结果。

有关各个单元的具体功能可参见上述方法示例中的相关内容，本实施例对此不作赘述。

本发明一示例性实施例还提供了一种分布式事务处理系统，该分布式系统包括：如图3A所示实施例或基于图3A所示实施例提供的任一可选实施例所提供的分布式事务处理装置，以及，如图4A所示实施例或基于图4A所示实施例提供的任一可选实施例所提供的分布式事务处理装置。

需要说明的是，上述实施例提供的装置在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

上述主要从业务节点的角度对本发明实施例提供的方案进行了介绍。可以理解的是，业务节点为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。结合本发明中所公开的实施例描述的各示例的模块及算法步骤，本发明实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同的方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的技术方案的范围。

图5是根据一示例性实施例示出的一种业务节点的结构示意图。例如，该业务节点可以是服务器，用于实现上述方法示例的功能。业务节点500可以包括：发射器/接收器501和处理器502。

发射器/接收器501用于支持业务节点500与外部设备之间收发信息。处理器502用于实现业务节点500的各项功能，比如上文介绍的业务受理器、事务管理器和事务处理器的各项功能。所述处理器502还用于执行上述图2、图3和图4A所示实施例中的各个步骤，或者本发明所描述的技术方案的其它步骤。

进一步地，业务节点500还可以包括存储器503，存储器503用于存储业务节点500的程序代码和数据。

此外，业务节点500还可以包括总线504。所述存储器503和所述发射器/接收器501通过总线504与所述处理器502相连。

可以理解的是，图5仅仅示出了业务节点500的简化设计。在实际应用中，业务节点500可以包含任意数量的发射器，接收器，处理器，存储器等，而所有可以实现本发明实施例的设备都在本发明实施例的保护范围之内。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。