CN105824842A - 分布式事务处理方法及其系统 - Google Patents

Abstract

本发明涉及事务处理技术，公开了一种分布式事务处理方法及其系统。在本发明中，消息中间件向参与分布式事务的至少一个节点投递消息以使上述节点执行本地事务，若至少一个节点执行本地事务失败，则在执行失败的各节点执行本地事务成功之前，上述消息中间件至少一次重新向该节点投递消息以使该节点重新执行本地事务，从而达到数据的最终一致性。此外，定期检查各节点的状态，可以避免因网络阻塞或消息中间件发生异常等问题产生的停滞。

Description

分布式事务处理方法及其系统

技术领域

本发明涉及事务处理技术，特别涉及分布式事务处理方法及其系统。

背景技术

传统的分布式事务实现，具有需要数据库提供分布式事务的特性。基于两阶段提交的协议，当每个数据库实例操作成功，事务才算成功；如果有一个实例失败，那么所有实例的操作都要回滚。

因此，本发明的发明人发现，通过数据库来实现分布式事务，会带来可用性、可伸缩性和性能的下降。传统的基于数据库实现分布式事务，事务可用性会是参与这个事务的数据库实例的可用性的乘积，只要一个实例失败，那么事务操作就失败。另外，传统的分布式事务需要和多个数据库实例进行多次网络的交互来实现两阶段提交，请求的响应时间会增高，性能会下降。

发明内容

本发明的目的在于提供一种分布式事务处理方法及其系统，提高了分布式事务的可用性和可伸缩性。

为解决上述技术问题，本发明的实施方式公开了一种分布式事务处理方法，方法包括以下步骤：

消息中间件向参与分布式事务的至少一个节点投递消息，以使节点执行本地事务；

若消息中间件接收到至少一个节点返回的表示执行本地事务失败的消息，在执行失败的各节点执行本地事务成功之前，消息中间件向执行本地事务失败的各节点至少一次重新投递消息，以使执行本地事务失败的各节点重新执行本地事务。

本发明的实施方式还公开了一种分布式事务处理系统，系统包括：

投递模块，用于控制消息中间件向参与分布式事务的至少一个节点投递消息，以使节点执行本地事务；以及

重新投递模块，用于若消息中间件接收到至少一个节点返回的表示执行本地事务失败的消息，在执行失败的各节点执行本地事务成功之前，控制消息中间件向执行本地事务失败的各节点至少一次重新投递消息，以使执行本地事务失败的各节点重新执行本地事务。

本发明实施方式与现有技术相比，主要区别及其效果在于：

在本发明中，消息中间件向参与分布式事务的至少一个节点投递消息以使上述节点执行分布式事务，若至少一个节点执行本地事务失败，则在执行失败的各节点执行本地事务成功之前，上述消息中间件至少一次重新向该节点投递消息以使该节点重新执行本地事务，从而达到数据的最终一致性。

进一步地，在第一节点执行本地事务成功后，使各节点多次执行本地事务，直至所有节点的本地事务都执行成功，从而达到数据的最终一致性。

进一步地，定期检查各节点的状态，可以避免因网络阻塞或消息中间件发生异常等问题产生的停滞。

附图说明

图1是本发明第一实施方式中一种分布式事务处理方法的流程示意图；

图2是本发明第一实施方式中一种分布式事务处理方法的流程示意图；

图3至图5是本发明第一实施方式中一种分布式事务处理方法的模式示意图；

图6是本发明第一实施方式中一种分布式事务处理方法的流程示意图；

图7是本发明第二实施方式中一种分布式事务处理系统的结构示意图。

具体实施方式

在以下的叙述中，为了使读者更好地理解本申请而提出了许多技术细节。但是，本领域的普通技术人员可以理解，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请各权利要求所要求保护的技术方案。

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

本发明第一实施方式涉及一种分布式事务处理方法。图1是该分布式事务处理方法的流程示意图。如图1所示，该分布式事务处理方法包括以下步骤：

在步骤101中，消息中间件向参与分布式事务的至少一个节点投递消息，以使节点执行本地事务。可以理解，各节点可以是数据库或应用程序等。各节点执行的各本地事务分别为该分布式事务的一部分，并构成该分布式事务。

消息中间件可以利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。消息中间件一般有两种模式，点对点模式和发布订阅模式。在点对点模式中，每个消息只有一个消费者，发送者和接收者没有时间依赖。在发布订阅模式中，每个消息可以有多个订阅者，客户端只有订阅后才能收到消息。

优选地，在本实施方式中使用消息中间件的发布订阅模式。可以理解，在某些特定情况下，也可以使用消息中间件的点对点模式。

此后进入步骤102，若消息中间件接收到至少一个节点返回的表示执行本地事务失败的消息，则进入步骤103，否则结束本流程。

在步骤103中，在执行失败的各节点执行本地事务成功之前，消息中间件向执行本地事务失败的各节点至少一次重新投递消息，以使执行本地事务失败的各节点重新执行本地事务。可以理解，各节点对于该消息中间件投递的重复的消息要做到幂等性。在本发明的一个优选例中，分布式事务不回滚，参与分布式事务的各节点不断尝试执行本地事务，直至执行成功。

在本实施方式的方法中，消息中间件向参与分布式事务的至少一个节点投递消息以使上述节点执行本地事务，若至少一个节点执行本地事务失败，则在该节点执行本地事务成功之前，上述消息中间件至少一次重新向该节点投递消息以使该节点重新执行本地事务，从而达到数据的最终一致性。

上述方法主要有以下几种模式：

1.作为发布者的节点是参与分布式事务的节点。

如图2和图3所示，在步骤101前，上述方法还包括以下步骤：

在步骤201中，消息中间件(B)从参与分布式事务的第一节点(A)接收表示准备提交事务的消息并存储。

此后进入步骤202，在第一节点执行本地事务成功后，消息中间件从第一节点接收表示已提交事务的消息，并将表示准备提交事务的消息修改为表示已提交事务的消息。

此后进入步骤101。

在第一节点(A)执行分布式事务成功后，使各节点(C、…D、E)可以多次执行本地事务，直至本地事务执行成功，从而达到数据的最终一致。

可以理解，第一节点A通常执行事务的第一步骤，例如第一节点A执行付款步骤，各节点C、…D、E分别执行付款成功后的商品管理、…物流、客户管理等步骤。当然，在本发明的其他实施方式中，第一节点A也可以执行事务的中间步骤。

此外，可以理解，在上述第一节点发送表示准备提交事务的消息失败或执行本地事务失败时，回滚分布式事务。即若第一节点A付款不成功，则不进行后续的操作，一旦第一节点A付款成功，则各节点C、…D、E不断执行事务，直至成功。

2.作为发布者的节点不是参与分布式事务的节点。

如图4所示，消息中间件在接收到表示已提交事务的消息后，向参与分布式事务的各节点投递消息(A、C、D、E)，以使各节点执行本地事务。例如，消息中间件接收到准备某个活动的消息后，向分别执行商品管理、客户管理、物流管理以及宣传管理的各节点投递消息，以使各节点执行相应操作。

若消息中间件接收到至少一个节点(例如C)返回的表示执行本地事务失败的消息，消息中间件向执行本地事务失败的各节点(例如C)至少一次重新投递消息，以使这些节点重新执行该本地事务。即确保各节点执行相应操作成功，以达到数据的最终一致。

3.作为订阅者的节点同时也是作为发布者的节点。

例如，如图5所示，在节点C执行本地事务成功后通过B向节点E投递消息，以使节点E执行本地事务。

可以理解，在各应用场景中可以将以上各模式组合后使用，但在某些特定应用场景中各模式也可以分别使用。

可选地，在步骤102后还包括以下步骤：

若消息中间件接收到所有节点返回的表示执行本地事务成功的消息，消息中间件删除表示已提交事务的消息。

此外，上述方法还可以包括以下步骤：

消息中间件以预设周期扫描表示准备提交事务的消息和表示已提交事务的消息；

消息中间件根据表示准备提交事务的消息向第一节点发送消息以检查第一节点是否已提交事务；

消息中间件根据表示已提交事务的消息向未返回本地事务执行成功确认的各节点投递消息，以使各节点执行本地事务。

定期检查各节点的状态，可以避免因网络阻塞或消息中间件发生异常等问题产生的停滞。

此外，可以理解，预设周期可以根据实际情况进行设置。

以下将分别通过分布式事务成功处理流程、失败处理流程和分布式系统异常处理流程来对上述方法进行进一步地详细描述。

如图6所示，分布式事务成功处理流程主要如下:

1、A作为发布者，发送half事务消息(即表示准备提交事务的消息)。

2、B消息中间件持久化half事务消息成功。

3、A发送half事务消息成功后，执行本地事务成功，发送提交命令。

4、B消息中间件收到提交消息后，更新half消息为已提交状态，向C订阅者投递消息。

5、C订阅者收到消息后，执行本地事务成功。

6、B收到C的成功消费ack(确认消息)后，删除消息。至此，A和C的分布式事务成功执行。

可以看到，A、B、C各自都具有相应的数据库DB。

分布式事务失败流程主要如下：

1、A发送half事务消息失败，那么分布式事务执行失败。如果发送成功，进入下一步。

2、A执行本地事务失败，发送事务消息回滚命令，B删除half消息，分布式事务执行失败。如果成功，进入下一步。

3、B向C投递消息，C执行本地事务失败，向B返回消费失败ack。B会不断进行重试投递，直至C执行本地事务成功。(也就是说一旦A执行本地事务成功了，那么分布式事务就无法回滚，C要保证多次重试，最终必然成功，达到数据的最终一致性)

分布式系统异常流程处理主要如下：

1、A向B发送事务提交或者回滚，可能因为网络问题，或者B宕机导致失败。这种情况下，B会定期扫描未提交的half消息，向A发送check(检查消息)，A要告诉B事务要提交或者回滚。

2、C向B返回消费ack，也有可能因为网络问题，或者B宕机导致失败。B会定期扫描已提交的消息，向C投递，C对于重复的消息要做到幂等性。

可以理解，上述方法可以应用于各种应用场景中，例如当库存为零时通知商品系统进货，或是当进行兑换礼品后进行扣积分的操作等等。

考虑到互联网应用需要高可用、低延迟，能够有高伸缩性的架构，来支持更高的并发、更大量的用户数。通过上述基于消息中间件提供分布式事务消息的方法，可以支持高性能、高可用的分布式事务场景。

可以理解，以上仅为本发明的一个优选实施例，可以根据需要对相应步骤和设置进行变化。

本发明的各方法实施方式均可以以软件、硬件、固件等方式实现。不管本发明是以软件、硬件、还是固件方式实现，指令代码都可以存储在任何类型的计算机可访问的存储器中(例如永久的或者可修改的，易失性的或者非易失性的，固态的或者非固态的，固定的或者可更换的介质等等)。同样，存储器可以例如是可编程阵列逻辑(ProgrammableArrayLogic，简称“PAL”)、随机存取存储器(RandomAccessMemory，简称“RAM”)、可编程只读存储器(ProgrammableReadOnlyMemory，简称“PROM”)、只读存储器(Read-OnlyMemory，简称“ROM”)、电可擦除可编程只读存储器(ElectricallyErasableProgrammableROM，简称“EEPROM”)、磁盘、光盘、数字通用光盘(DigitalVersatileDisc，简称“DVD”)等等。

本发明第二实施方式涉及一种分布式事务处理系统。图7是该分布式事务处理系统的结构示意图。如图7所示，该分布式事务处理系统包括：

投递模块，用于控制消息中间件向参与分布式事务的至少一个节点投递消息，以使节点执行本地事务。可以理解，各节点可以是数据库或应用程序等。

以及

重新投递模块，用于若消息中间件接收到至少一个节点返回的表示执行本地事务失败的消息，在执行失败的各节点执行本地事务成功之前，控制消息中间件向执行本地事务失败的各节点至少一次重新投递消息，以使执行本地事务失败的各节点重新执行本地事务。可以理解，各节点对于该消息中间件投递的重复的消息要做到幂等性。

优选地，在本实施方式中使用消息中间件的发布订阅模式。可以理解，在某些特定情况下，也可以使用消息中间件的点对点模式。

在本实施方式的系统中，投递模块控制消息中间件向参与分布式事务的至少一个节点投递消息以使上述节点执行本地事务，若至少一个节点执行本地事务失败，则重新投递模块在该节点执行本地事务成功之前，控制上述消息中间件至少一次重新向该节点投递消息以使该节点重新执行本地事务，从而达到数据的最终一致。

上述系统可以操作于以下几种模式：

1.作为发布者的节点是参与分布式事务的节点。

上述系统还包括：

存储模块，用于控制消息中间件从参与分布式事务的第一节点接收表示准备提交事务的消息并存储。以及

修改模块，用于在第一节点执行本地事务成功后，控制消息中间件从第一节点接收表示已提交事务的消息，并将存储模块存储的表示准备提交事务的消息修改为表示已提交事务的消息。

上述投递模块在修改模块将表示准备提交事务的消息修改为表示已提交事务的消息后，控制消息中间件向参与分布式事务的至少一个节点投递消息。

在第一节点执行本地事务成功后，使各节点可以多次执行本地事务，直至本地事务执行成功，从而达到数据的最终一致。

可以理解，第一节点通常执行事务的第一步骤，例如第一节点执行付款步骤，各节点分别执行付款成功后的商品管理、…物流、客户管理等步骤。当然，在本发明的其他实施方式中，第一节点也可以执行事务的中间步骤。

此外，可以理解，上述系统还包括回滚模块，用于在第一节点发送表示准备提交事务的消息失败或执行本地事务失败时，回滚分布式事务。即若第一节点付款不成功，则不进行后续的操作，一旦第一节点付款成功，则各节点不断执行事务，直至成功。

2.作为发布者的节点不是参与分布式事务的节点。

如图4所示，投递模块控制消息中间件在接收到表示已提交事务的消息后，向参与分布式事务的各节点投递消息(A、C、D、E)，以使各节点执行本地事务。例如，消息中间件接收到准备某个活动的消息后，投递模块控制该消息中间件向分别执行商品管理、客户管理、物流管理以及宣传管理的各节点投递消息，以使各节点执行相应操作。

重新投递模块在消息中间件接收到至少一个节点(例如C)返回的表示执行本地事务失败的消息时，控制消息中间件向执行本地事务失败的各节点(例如C)至少一次重新投递消息，以使这些节点重新执行该本地事务。即确保各节点执行相应操作成功，以完成活动准务。

3.作为订阅者的节点同时也是作为发布者的节点。

例如,如图5所示，在节点C执行本地事务成功后通过B向节点E投递消息，以使节点E执行本地事务。

上述各模式可以应用于各种应用场景中，例如当库存为零时通知商品系统进货，或是当进行兑换礼品后进行扣积分的操作等等。

可以理解，在各应用场景中可以将以上各模式组合后使用，但在某些特定应用场景中各模式也可以分别使用。

可选地，上述系统还包括删除模块，用于若消息中间件接收到所有节点返回的表示执行本地事务成功的消息，控制消息中间件删除修改模块修改的表示已提交事务的消息。

此外，上述系统还可以包括：

扫描模块，用于控制消息中间件以预设周期扫描表示准备提交事务的消息和表示已提交事务的消息；

检查模块，用于控制消息中间件根据扫描模块扫描的表示准备提交事务的消息向第一节点发送消息以检查第一节点是否已提交事务；以及

执行模块，用于控制消息中间件根据扫描模块扫描的表示已提交事务的消息向未返回本地事务执行成功确认的各节点投递消息，以使各节点执行本地事务。

定期检查各节点的状态，可以避免因网络阻塞或消息中间件发生异常等问题产生的停滞。

此外，可以理解，预设周期可以根据实际情况进行设置。

第一实施方式是与本实施方式相对应的方法实施方式，本实施方式可与第一实施方式互相配合实施。第一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一实施方式中。

需要说明的是，本发明各设备实施方式中提到的各模块都是逻辑模块，在物理上，一个逻辑模块可以是一个物理模块，也可以是一个物理模块的一部分，还可以以多个物理模块的组合实现，这些逻辑模块本身的物理实现方式并不是最重要的，这些逻辑模块所实现的功能的组合才是解决本发明所提出的技术问题的关键。此外，为了突出本发明的创新部分，本发明上述各设备实施方式并没有将与解决本发明所提出的技术问题关系不太密切的模块引入，这并不表明上述设备实施方式并不存在其它的模块。

需要说明的是，在本专利的权利要求和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (10)

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

消息中间件向参与分布式事务的至少一个节点投递消息，以使所述节点执行本地事务；

若所述消息中间件接收到至少一个节点返回的表示执行本地事务失败的消息，在执行失败的各节点执行本地事务成功之前，所述消息中间件向执行本地事务失败的各节点至少一次重新投递消息，以使执行本地事务失败的各节点重新执行本地事务。

2.根据权利要求1所述的分布式事务处理方法，其特征在于，所述“消息中间件向参与分布式事务的至少一个节点投递消息，以使所述节点执行本地事务”的步骤前，还包括以下步骤：

所述消息中间件从参与分布式事务的第一节点接收表示准备提交事务的消息并存储；

在所述第一节点执行本地事务成功后，所述消息中间件从所述第一节点接收表示已提交事务的消息，并将表示准备提交事务的消息修改为表示已提交事务的消息。

3.根据权利要求2所述的分布式事务处理方法，其特征在于，所述“消息中间件向参与分布式事务的至少一个节点投递消息，以使所述节点执行本地事务”的步骤后还包括以下步骤：

若所述消息中间件接收到所有所述节点返回的表示执行本地事务成功的消息，所述消息中间件删除表示已提交事务的消息。

4.根据权利要求3所述的分布式事务处理方法，其特征在于，所述方法还包括以下步骤：

所述消息中间件以预设周期扫描表示准备提交事务的消息和表示已提交事务的消息；

所述消息中间件根据表示准备提交事务的消息向所述第一节点发送消息以检查所述第一节点是否已提交事务；

所述消息中间件根据表示已提交事务的消息向未返回本地事务执行成功确认的各节点投递消息，以使各节点执行本地事务。

5.根据权利要求2至4中任一项所述的分布式事务处理方法，其特征在于，在所述第一节点发送表示准备提交事务的消息失败或执行本地事务失败时，回滚所述分布式事务。

6.一种分布式事务处理系统，其特征在于，所述系统包括：

投递模块，用于控制消息中间件向参与分布式事务的至少一个节点投递消息，以使所述节点执行本地事务；以及

重新投递模块，用于若所述消息中间件接收到至少一个节点返回的表示执行本地事务失败的消息，在执行失败的各节点执行本地事务成功之前，控制所述消息中间件向执行本地事务失败的各节点至少一次重新投递消息，以使执行本地事务失败的各节点重新执行本地事务。

7.根据权利要求6所述的分布式事务处理系统，其特征在于，所述系统还包括：

存储模块，用于控制所述消息中间件从参与分布式事务的第一节点接收表示准备提交事务的消息并存储；以及

修改模块，用于在所述第一节点执行本地事务成功后，控制所述消息中间件从所述第一节点接收表示已提交事务的消息，并将所述存储模块存储的表示准备提交事务的消息修改为表示已提交事务的消息；

所述投递模块在所述修改模块将表示准备提交事务的消息修改为表示已提交事务的消息后，控制消息中间件向参与分布式事务的至少一个节点投递消息。

8.根据权利要求7所述的分布式事务处理系统，其特征在于，所述系统还包括删除模块，用于若所述消息中间件接收到所有所述节点返回的表示执行本地事务成功的消息，控制所述消息中间件删除所述修改模块修改的表示已提交事务的消息。

9.根据权利要求8所述的分布式事务处理系统，其特征在于，所述系统还包括：

扫描模块，用于控制所述消息中间件以预设周期扫描表示准备提交事务的消息和表示已提交事务的消息；

检查模块，用于控制所述消息中间件根据所述扫描模块扫描的表示准备提交事务的消息向所述第一节点发送消息以检查所述第一节点是否已提交事务；以及

执行模块，用于控制所述消息中间件根据所述扫描模块扫描的表示已提交事务的消息向未返回本地事务执行成功确认的各节点投递消息，以使各节点执行本地事务。

10.根据权利要求7至9中任一项所述的分布式事务处理系统，其特征在于，所述系统还包括回滚模块，用于在所述第一节点发送表示准备提交事务的消息失败或执行本地事务失败时，回滚所述分布式事务。