CN113760566A - 一种分布式事务处理的方法、装置、系统和存储介质 - Google Patents

Abstract

本申请公开了一种分布式事务处理的方法、装置、系统和存储介质，包括：在接收到用户的业务请求时，第一业务系统将产生的业务数据进行保存，并将业务数据的状态设置为未完成的状态；第一业务系统发送由消息队列(MQ)消息体组成的业务消息，在接收到业务回执时，将业务数据的状态设置为已完成的状态。应用本申请方法实施例方案，由于将业务消息和业务回执利用MQ消息体的格式，采用异步方式传输，降低了第一业务系统和第二业务系统之间的耦合性；且，第一业务系统为业务数据设置了状态，并根据业务消息的执行情况变更其业务数据的状态，从而在不引入事务协调者的情况下，仍然可以保证分布式系统中数据的一致性，降低了系统的复杂性。

Description

一种分布式事务处理的方法、装置、系统和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种分布式事务处理的方法、一种分布式事务处理的装置、一种分布式事务处理的系统、一种计算机可读存储介质以及一种电子设备。

背景技术

随着业务系统复杂性的增加，单台计算机或服务器已经很难单独进行处理，需要由多台计算机或服务器协作处理。为了增强在多台机器上运行的系统的可扩展性、稳定性和执行效率，通常将多台机器采用分布式系统的结构来组织。

由于同一业务分布在不同的机器节点上实现，为了保证数据的一致性，就需要分布式系统采用某种机制进行分布式事务管理。现有技术可以采用两阶段提交(2PC，Two-phase Commit)方案和补偿事务(TCC，Try-Confirm-Cancel)方案来保证数据的一致性。不管是2PC方案，还是TCC方案，都需要引入事务协调者，由事务协调者确定各个阶段的同步工作，大大增加了系统的复杂性。

发明内容

针对上述现有技术，本申请提供一种分布式事务处理的方法，可以克服现有技术引入事务协调者导致的增加系统复杂性的问题，达到无需引入事务协调者就可以保证数据一致性的目的。

本申请方法实施例提出的一种分布式事务处理的方法，具体包括：

在接收到用户的业务请求时，第一业务系统将产生的业务数据进行保存，并将所述业务数据的状态设置为未完成的状态，所述业务数据为针对所述用户的业务请求所产生的数据；

所述第一业务系统发送由消息队列(MQ)消息体组成的业务消息，所述业务消息为针对所述用户的业务请求所产生的需要由第二业务系统执行的消息；

所述第一业务系统接收由MQ消息体组成的业务回执时，将所述业务数据的状态设置为已完成的状态，所述业务回执为所述第二业务系统执行完所述业务消息后反馈的消息，所述第一业务系统和所述第二业务系统构成分布式系统。

进一步地，

所述第一业务系统发送由MQ消息体组成的业务消息的步骤包括：所述第一业务系统将由所述MQ消息体组成的业务消息发送给中间件队列服务器，所述中间件队列服务器将所述MQ业务放置于消息队列中，由所述第二业务系统从所述消息队列中获取所述业务消息；

所述第一业务系统接收由MQ消息体组成的业务回执的步骤包括：所述第一业务系统从所述中间件队列服务器的消息队列中获取所述业务回执，所述业务回执为所述第二业务系统执行完所述业务消息后发送给所述中间件队列服务器的。

进一步地，

所述第一业务系统将产生的业务数据进行保存的步骤包括：

所述第一业务系统先将产生的业务数据保存在业务数据库中；

所述第一业务系统再将所述业务数据保存在中间件缓存服务器；

所述将业务数据的状态设置为已完成的状态的步骤之后，该方法进一步包括：所述第一业务系统删除所述中间件缓存服务器中的所述业务数据。

进一步地，

所述第一业务系统再将所述业务数据保存在中间件缓存服务器之后，该方法进一步包括：

根据设置的时间间隔查询所述中间件缓存服务器中的业务数据，并判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值；

如果超出预设的延迟时间阈值，则所述第一业务系统利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，将所述业务数据库中的业务数据设置为已完成的状态，且删除所述中间件缓存服务器中的所述业务数据；所述业务消息执行结果为失败时，将所述业务消息重新发送给所述中间件队列服务器。

针对上述现有技术，本申请提供一种分布式事务处理的装置，可以克服现有技术引入事务协调者导致的增加系统复杂性的问题，达到无需引入事务协调者就可以保证数据一致性的目的。

本申请实施例提出的一种分布式事务处理的装置，该装置包括：收发模块、存储操作模块和状态设置模块，其中：

所述收发模块，用于接收用户的业务请求；发送由消息队列(MQ)消息体组成的业务消息，所述业务消息为针对所述用户的业务请求所产生的需要由第二业务系统执行的消息；接收由MQ消息体组成的业务回执，所述业务回执为所述第二业务系统执行完所述业务消息后反馈的消息；

所述存储操作模块，用于将产生的业务数据进行保存，所述业务数据为针对所述用户的业务请求所产生的数据；

所述状态设置模块，用于将产生的业务数据进行保存时将所述业务数据的状态设置为未完成的状态；在接收由MQ消息体组成的业务回执时将所述业务数据的状态设置为已完成的状态。

进一步地，

所述收发模块发送由MQ消息体组成的业务消息时用于：将由所述MQ消息体组成的业务消息发送给中间件队列服务器，所述中间件队列服务器将所述MQ业务放置于消息队列中，由所述第二业务系统从所述消息队列中获取所述业务消息；

所述收发模块接收由MQ消息体组成的业务回执时用于：从所述中间件队列服务器的消息队列中获取所述业务回执，所述业务回执为所述第二业务系统执行完所述业务消息后发送给所述中间件队列服务器的。

进一步地，

所述存储操作模块将产生的业务数据进行保存时用于：先将产生的业务数据保存在业务数据库中，再将所述业务数据保存在中间件缓存服务器；

所述存储操作模块进一步用于：将业务数据的状态设置为已完成的状态之后，删除所述中间件缓存服务器中的所述业务数据。

该装置进一步包括：查询模块、第一判断模块和接口调用模块；

所述查询模块，用于根据设置的时间间隔查询所述中间件缓存服务器中的业务数据；

所述第一判断模块，用于判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值，如果超出预设的延迟时间阈值，则执行所述接口调用模块；

接口调用模块，利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，触发所述状态设置模块将所述业务数据库中的业务数据设置为已完成的状态；所述业务消息执行结果为失败时，触发所述收发模块将所述业务消息重新发送给所述中间件队列服务器；

所述收发模块进一步用于，所述业务消息执行结果为失败时，将所述业务消息重新发送给所述中间件队列服务器；

所述状态设置模块进一步用于，所述业务消息执行结果为成功时，将所述业务数据库中的业务数据设置为已完成的状态。

针对上述现有技术，本申请提供一种分布式事务处理的系统，可以克服现有技术引入事务协调者导致的增加系统复杂性的问题，达到无需引入事务协调者就可以保证数据一致性的目的。

本申请实施例提出的一种分布式事务处理的系统，该系统包括：第一业务系统和第二业务系统，所述第一业务系统和所述第二业务系统构成分布式系统；其中，

所述第一业务系统，用于在接收到用户的业务请求时，将产生的业务数据进行保存，并将所述业务数据的状态设置为未完成的状态，所述业务数据为针对所述用户的业务请求所产生的数据；发送由消息队列(MQ)消息体组成的业务消息；接收由MQ消息体组成的业务回执时，将所述业务数据的状态设置为已完成的状态；

所述第二业务系统，用于执行所述业务消息，并在执行完所述业务消息后反馈所述业务回执。

进一步地，

该系统进一步包括：中间件队列服务器；

所述中间件队列服务器，用于接收所述第一业务系统发送的由所述MQ消息体组成的业务消息，将所述MQ业务放置于消息队列中，提供给所述第二业务系统从所述消息队列中获取所述业务消息；还用于接收所述第二业务系统执行完所述业务消息后发送所述业务回执，将所述业务回执放置于消息队列中，提供给所述第一业务系统从所述消息队列中获取所述业务回执。

进一步地，

该系统进一步包括：业务数据库和中间件缓存服务器；

所述业务数据库，用于保存所述业务数据；

所述中间件缓存服务器，用于保存所述业务数据；

所述第一业务系统进一步用于，将产生的业务数据保存在业务数据库和中间件缓存服务器中；且，将业务数据的状态设置为已完成的状态之后，删除所述中间件缓存服务器中的所述业务数据。

进一步地，

所述第一业务系统进一步用于，根据设置的时间间隔查询所述中间件缓存服务器中的业务数据，并判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值；如果超出预设的延迟时间阈值，则利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，将所述业务数据库中的业务数据设置为已完成的状态，且删除所述中间件缓存服务器中的所述业务数据；所述业务消息执行结果为失败时，将所述业务消息重新发送给所述中间件队列服务器。

本申请实施例还提出一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时可实现上述任一项所述分布式事务处理的方法的步骤。

本申请实施例还提出一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述计算机指令时实现上述任一分布式事务处理的方法。

综上所述，本申请实施例将业务消息和业务回执利用MQ消息体的格式，采用异步方式传输，降低了第一业务系统和第二业务系统之间的耦合性；且，第一业务系统为业务数据设置了状态，并根据业务消息的执行情况变更其业务数据的状态，从而在不引入事务协调者的情况下，仍然可以保证分布式系统中数据的一致性，降低了系统的复杂性。

附图说明

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

图1是本申请方法实施例一的流程图。

图2是本申请方法实施例二的流程图。

图3是本申请方法实施例三的流程图。

图4是本申请装置实施例一和装置实施例二的内部结构示意图。

图5是本申请装置实施例三的内部结构示意图。

图6是本申请系统实施例一的结构示意图。

图7是本申请系统实施例二的结构示意图。

图8本申请实施例中的电子设备结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。

下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

针对现有技术需要引入协调者才能完成分布式系统的数据一致性，本申请实施例取消协调者，在分布式系统中采用异步方式传输业务消息，并为业务数据设置状态，根据业务消息的执行状况对业务数据的状态进行变更，在简化分布式系统复杂性的基础上，仍然能够保证分布式系统中业务数据的一致性。

在本申请实施例中，假设分布式系统至少包括第一业务系统和第二业务系统。这里所述第一业务系统和第二业务系统并非某个具体的业务系统，而是指将业务部署在不同机器上并采用分布式结构进行实施的系统。其中，第一业务系统和第二业务系统可以理解为实现整体业务不同功能的子系统，并非将分布式系统中的子系统的实际数量限制为两个，实际应用中可以由多个子系统构成分布式系统。另外，本申请实施例所述的“数据”指“业务数据”，业务数据一致性是指业务执行过程中各子系统中的业务数据保持协调一致的含义。

图1是本申请方法实施例一的流程图。如图1所示，该方法包括：

步骤101：在接收到用户的业务请求时，第一业务系统将产生的业务数据进行保存，并将业务数据的状态设置为未完成的状态，所述业务数据为针对所述用户的业务请求所产生的数据。

这里所述的业务请求是指需要业务系统完成某个功能的请求，业务数据则是指针对业务请求所产生的数据。比如在互联网购物的分布式系统中，第一业务系统负责下单功能，第二业务系统负责减库存功能。在第一业务系统收到下单的业务请求时，会产生与订单相关的一系列数据，比如商品ID、订单号、创建人、创建时间等等，这些数据在本申请实施例中都可以被称为业务数据。

为了保证分布式系统中数据的一致性，本申请实施例为业务数据设置一个状态来记录处理的进展状况，并在本步骤中将其首先设置为“未完成”的状态。

步骤102：第一业务系统发送由消息队列(MQ)消息体组成的业务消息，所述业务消息为针对用户的业务请求所产生的需要由第二业务系统执行的消息。

第一业务系统采用异步方式向第二业务系统传输业务消息，以减少第一业务系统和第二业务系统之间的耦合性。为了实现该异步方式的传输，本申请实施例将业务消息用消息队列(MQ，Message Queue)的消息体格式表示。也就是说，第一业务系统发送的业务消息并不是直接发送给第二业务系统，而是放置于消息队列中，第二业务系统再从该消息队列中获取业务消息，即第一业务系统作为业务消息的生产者，而第二业务系统作为业务消息的消费者。

步骤103：第一业务系统接收由MQ消息体组成的业务回执时，将所述业务数据设置为已完成的状态，所述业务回执为所述第二业务系统执行完所述业务消息后反馈的消息，所述第一业务系统和所述第二业务系统构成分布式系统。

同样，第二业务系统向第一业务系统返回业务回执时，也采用异步方式，以减少双方的耦合性。本申请实施例将业务回执用MQ的消息体格式表示。也就是说，第二业务系统发送的业务回执并不是直接发送给第一业务系统，而是放置于消息队列中，第一业务系统再从该消息队列中获取业务回执，即第二业务系统作为业务回执的生产者，而第一业务系统作为业务回执的消费者。

按照上述步骤102和103的异步模式，第一业务系统和第二业务系统可以仅重点关注自身的业务执行情况，无需浪费时间在双方消息的收发上，从而降低系统之间的耦合性。另外，在收到业务回执时，第一业务系统可以认为第二业务系统已经针对业务数据进行了处理，因此第一业务系统将业务数据设置为已完成的状态，表示业务数据在分布式系统中已经同步，从而保持数据的一致性。

应用本申请方法实施例一的方案，由于将业务消息和业务回执利用MQ消息体的格式，采用异步方式传输，降低了第一业务系统和第二业务系统之间的耦合性；且，第一业务系统为业务数据设置了状态，并根据业务消息的执行情况变更其业务数据的状态，从而在不引入事务协调者的情况下，仍然可以保证分布式系统中数据的一致性，降低了系统的复杂性。

为了更好地说明本申请实施例方案，下面还提供另一种分布式事务处理的方法。

在本申请方法实施例二中，仍然假设第一业务系统和第二业务系统构成分布式系统，双方通过异步方式将MQ消息体组成的业务消息传输给对方。

本申请实施例假设中间件队列服务器是用于保存消息队列的服务器，第一业务系统和第二业务系统均将MQ消息体组成的业务消息发送给中间件队列服务器，再由对方从中间件队列服务器中获取。这里所述的中间件队列服务器是一种运行中间件软件的服务器，由于在本申请实施例中主要用于消息队列操作，因此称为中间件队列服务器。在实际应用中，中间件队列服务器可以为Kafaka服务器。

本申请实施例还假设中间件缓存服务器是用于缓存业务数据的服务器，第一业务系统将保存在业务数据库中的全部或部分业务数据缓存在中间件缓存服务器中。这里所述的中间件缓存服务器也是一种运行中间件软件的服务器，由于在本申请实施例中主要用于缓存，因此称为中间件缓存服务器。在实际应用中，中间件缓存服务器可以为Redis服务器。

图2是本申请方法实施例二的流程图。如图2所示，该方法包括：

步骤201：在接收到用户的业务请求时，第一业务系统将产生的业务数据保存在业务数据库中，并将业务数据的状态设置为未完成的状态，所述业务数据为针对所述用户的业务请求所产生的数据。

这里假设是在互联网购物的分布式系统中，第一业务系统负责下单功能，第二业务系统负责减库存功能。第一业务系统收到下单的业务请求时，订单产生的业务数据如表一所示：

表一

其中，业务数据包括“订单ID”、“商品ID”、“商品数量”、“备用字段”、“修改人”、“修改时间”、“创建人”和“创建时间”等数据项名称，其对应的数据项值如右列所示，且将其状态设置为“未完成”。本步骤会将表一所示的业务数据保存到业务数据库，该业务数据库通常可以为关系型数据库，比如MYSQL数据库。

步骤202：第一业务系统将业务数据保存在中间件缓存服务器，将业务数据的状态设置为未完成的状态。

这里的步骤201和步骤202是实现上述方法实施例一的步骤101的具体方式。在本申请方法实施例二中，第一业务系统不但将业务数据保存在业务数据库中，还同时保存在中间件缓存服务器(即：Redis)中。Redis数据库的读写性能非常高，比通常采用关系型数据库(比如MYSQL等)能够更快地完成操作。因此，本申请实施例设置了中间件缓存服务器，并将业务数据保存其中，以便于后续查询，提高查询速度。当然，如果实际应用中不考虑数据库查询的速度，这里也可以省略中间件缓存服务器。

实际应用中，可以将步骤201中的业务数据直接保存到中间件缓存服务器中，也可以保存业务数据的一部分。如果保存全部的业务数据，保存内容可参见表一所示，此处不再赘述。如果保存部分，可参见如下表二所示：

表二

这里，只需要保证业务数据库中的业务数据与中间件缓存服务器中的业务数据之间存在关联关系即可，不必要将业务数据库中的业务数据的全部内容保存到中间件缓存服务器，以便于进一步节约中间件缓存服务器的存储空间。当然，实际应用中，在中间件缓存服务器中保存哪些业务数据的内容可以由具体的业务来确定，并不作为限定本申请实施例保护范围的限定。

步骤203：第一业务系统将由MQ消息体组成的业务消息发送给中间件队列服务器，所述中间件队列服务器将MQ业务放置于消息队列中，由第二业务系统从消息队列中获取业务消息，所述业务消息为针对所述用户的业务请求所产生的需要由第二业务系统执行的消息。

本申请实施例设置了中间件队列服务器(即：Kafaka)，第一业务系统无需将业务消息直接发送给第二业务系统，仅发送给中间件队列服务器即可。中间件队列服务器可以将业务消息放置于消息队列中保存，由第二业务系统在适当的时机从该消息队列中获取业务消息，实现异步传输。

以上述互联网购物的分布式系统为例，本步骤的业务消息的格式如表三所示：

订单ID	创建时间	发送时间
			001	2020-11-01	08:00

表三

这里仅举例一种可行的MQ消息体构成的业务消息的格式，实际应用中由具体的业务来确定，并不作为限定本申请实施例保护范围的限定。

步骤204：第一业务系统从中间件队列服务器的消息队列中获取业务回执，所述业务回执为第二业务系统执行完业务消息后发送给中间件队列服务器的。

当第二业务系统执行完业务消息后，会将业务回执返回给第一业务系统。与上述步骤203相似，第二业务系统也无需将业务回执发送给第一业务系统，仅发送给中间件队列服务器即可。中间件队列服务器也可以将业务回执放置于消息队列中保存，由第一业务系统在适当的时机从该消息队列中获取业务回执。

实际应用中，中间件队列服务器中可以设置多个消息队列，第一业务系统产生的业务消息和第二业务系统产生的业务回执可以放置于不同的消息队列中，以便于对方获取。

以上述互联网购物的分布式系统为例，本步骤的业务回执的格式如表四所示：

订单ID	完成时间	发送时间
			001	2020-11-01	08:02

表四

这里仅举例一种可行的MQ消息体构成的业务回执的格式，实际应用中由具体的业务来确定，并不作为限定本申请实施例保护范围的限定。

步骤205：第一业务系统将业务数据的状态设置为已完成的状态。

本步骤实施后，业务数据库中的该业务数据为表五所示：

表五

步骤206：第一业务系统删除中间件缓存服务器中的所述业务数据。

此时，中间件缓存服务器中保存的表二所示的业务数据将被删除，后续将无需被关注。

在本申请方法实施例二中，第一业务系统收到了第二业务系统返回的业务回执，可确定第二业务系统已经处理完业务消息，在分布式系统中实现了业务数据的一致性。比如：在上述的互联网购物的分布式系统中，第一业务系统实现下单功能，第二业务系统实现减库存功能。其中，第一业务系统在接收到用户的下单请求时，产生了如表一所示的业务数据，将其保存在业务数据库；第一业务系统还将该业务数据的全部或部分(如表二)保存在中间件缓存数据库中；第一业务系统再将如表三所示的业务消息发送给中间件队列服务器；第二业务系统从中间件队列服务器获取业务消息，执行该业务消息，实现减库存。比如：商品ID为123456的商品的原库存量为100，订单001需要5件该商品，第二业务系统则需要将5件商品从原有库存中减去，使得现有库存量为95件。第二系统执行完业务消息之后，将如表四所示的业务回执发送给中间件队列服务器。第一业务系统收到业务回执，可以确定第二业务系统已经执行业务消息，实现了减库存操作，于是将业务数据的状态设置为表五中的“已完成”。在本例中，第一业务系统的订单001中需要商品ID为123456的商品5件，第二业务系统将原有的库存量从100变更为95件。因此，虽然第一业务系统和第二业务系统是两个彼此独立的系统，但在分布式系统的组织下，一方的操作可以在另一方得到相应的响应，保持数据一致性。相反，如果没有得到相应的响应，第一业务系统实现了订单操作，但第二业务系统并没有进行相应的减库存操作，即数据没有保持一致性，那么这将导致整个业务系统的混乱。

本申请方法实施例二示出的是网络没有延迟，业务消息得到及时处理情况下的方法流程。也就是说，第一业务系统是获得了业务回执，根据业务回执来确定分布式系统实现了数据一致性，并将业务数据的状态变更为已完成。但实际应用中，可能由于网络延迟第一业务系统未获取第二业务系统返回的业务回执，或者其他原因造成第二业务系统不能及时处理业务消息而未返回业务回执。这种情况下，由于第一业务系统未获取业务回执，因此无法确定分布式系统是否实现了数据一致性。针对该情况，本申请还提供了方法实施例三。

在本申请方法实施例三中，不但设置了中间件队列服务器和中间件缓存服务器，第一业务系统还设置了查询中间件缓存服务器的间隔时间t1以及延迟时间阈值T。与上述方法实施例一和方法实施例二相同，在本申请方法实施例三中，如果第一业务系统接收到业务回执，也可以确定分布式系统实现了数据一致性，具体方法参见方法实施例一和方法实施例二，此处不再赘述。

本申请方法实施例三还提出未获取业务回执时确定数据一致性的方法，下面仅对此部分进行详细描述。图3是本申请方法实施例三的流程图。如图3所示，假设第一业务系统将业务数据已经保存于中间件缓存服务器中，该方法包括：

步骤301：第一业务系统根据设置的时间间隔查询所述中间件缓存服务器中的业务数据。

如上所述，当业务数据保存在业务数据库和中间件缓存服务器中后，第一业务系统为业务数据设置了状态，并将其初始状态设置为“未完成”，表示该业务数据在分布式系统内部还未实现一致性。

步骤302：判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值，如果超出预设的延迟时间阈值，则执行步骤303；否则，返回本步骤继续执行。

实际应用中，可以在将业务数据保存到中间件缓存服务器时，为该业务数据设置时间戳t0，以记录保存业务数据时的时间。那么，当第一业务系统查询业务数据时，就可以根据查询时的时间t2和时间戳t0计算出业务数据为未完成的状态的时长(t2-t0)。将时长(t2-t0)与延迟时间阈值T进行比较，可以确定是否超出延迟时间阈值T。如果超出延迟时间阈值T，说明情况发生异常，第一业务系统可以采用以下步骤303～步骤306的方法主动确定业务数据一致性问题。如果未超出延迟时间阈值T，说明当前还不能判断是否发生异常，需要继续等待业务回执。

步骤303：第一业务系统利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果。

实际应用中，可以在第一业务系统和第二业务系统之间设置远程过程调用(RPC，Remote Procedure Call)接口，通过该接口可以查询第二业务系统针对业务消息的执行结果。

步骤304：判断业务消息执行结果是否为成功，如果为成功，则执行步骤305；否则，执行步骤306。

步骤305：将所述业务数据库中的业务数据设置为已完成的状态，且删除所述中间件缓存服务器中的所述业务数据。

如果通过RPC接口查询到第二业务系统已经成功执行业务消息，那么可能是由于网络延迟等原因导致第一业务系统未接收到业务回执。此时，第一业务系统可以主动确定分布式系统已经实现业务数据一致性，将业务数据的状态变更为已完成，删除中间件缓存服务器中的该业务数据，后续不再关注该业务数据。

步骤306：将所述业务消息重新发送给所述中间件队列服务器，并返回步骤301。

相反，如果通过RPC接口查询到第二业务系统未成功执行业务消息，那么可能是由于网络延迟或丢包等原因导致第二业务系统未收到业务消息。此时，第一业务系统需要将业务消息重新通过中间件队列服务器发送给第二业务系统。相应的，也需要重新为该业务数据设置时间戳t0，并根据设置的时间间隔重新查询中间件缓存服务器中的业务数据。

在本申请实施例三中，一方面，如果第一业务系统正常接收到第二业务系统返回的业务回执，可以确定分布式系统实现了业务数据的一致性；另一方面，如果第一业务系统未正常接收第二业务系统的业务回执，在调用RPC接口获知第二业务系统已经成功执行业务消息时，也可以确定分布式系统实现了业务数据的一致性。上述两种方式都可以确定分布式系统实现了业务数据的一致性，因而可以将业务数据库中的该业务数据的状态变更为已完成，同时删除中间件缓存服务器中的该业务数据。

本申请还提供一种分布式事务处理的装置，该装置作为第一业务系统，和第二业务系统构成分布式系统。图4是本申请装置实施例一的内部结构示意图。如图4所示，该装置至少包括：收发模块401、存储操作模块402和状态设置模块403。其中：

收发模块401，用于接收用户的业务请求；发送由消息队列(MQ)消息体组成的业务消息，所述业务消息为针对所述用户的业务请求所产生的需要由第二业务系统执行的消息；接收由MQ消息体组成的业务回执，所述业务回执为所述第二业务系统执行完所述业务消息后反馈的消息。

存储操作模块402，用于将产生的业务数据进行保存，所述业务数据为针对所述用户的业务请求所产生的数据。

状态设置模块403，用于将产生的业务数据进行保存时将所述业务数据的状态设置为未完成的状态；在接收由MQ消息体组成的业务回执时将所述业务数据的状态设置为已完成的状态。

也就是说，当该装置的收发模块401接收到用户的业务请求时，存储操作模块402将产生的业务数据进行保存；存储操作模块402将产生的业务数据进行保存；同时，收发模块401发送由MQ消息体组成的业务消息；当该装置的收发模块401接收到由MQ消息体组成的业务回执时，状态设置模块403将所述业务数据的状态设置为已完成的状态。

应用本申请装置实施例一的方案，由于将业务消息和业务回执利用MQ消息体的格式，采用异步方式传输，降低了作为第一业务系统的装置和第二业务系统之间的耦合性；且，在本申请实施例的装置中为业务数据设置了状态，并根据业务消息的执行情况变更其业务数据的状态，从而在不引入事务协调者的情况下，仍然可以保证分布式系统中业务数据的一致性，从而降低了系统的复杂性。

在本申请另一装置实施例二中，其内部结构示意图仍然如图4所示。其中，收发模块401发送由MQ消息体组成的业务消息时用于：将由所述MQ消息体组成的业务消息发送给中间件队列服务器，所述中间件队列服务器将所述MQ业务放置于消息队列中，由所述第二业务系统从所述消息队列中获取所述业务消息。

收发模块401接收由MQ消息体组成的业务回执时用于：从所述中间件队列服务器的消息队列中获取所述业务回执，所述业务回执为所述第二业务系统执行完所述业务消息后发送给所述中间件队列服务器的。

存储操作模块402将产生的业务数据进行保存时用于：先将产生的业务数据保存在业务数据库中，再将所述业务数据保存在中间件缓存服务器。存储操作模块402进一步用于：将业务数据的状态设置为已完成的状态之后，删除所述中间件缓存服务器中的所述业务数据。

图5是本申请装置实施例三的内部结构示意图。如图5所示，该装置包括：收发模块401、存储操作模块402和状态设置模块403，还包括查询模块404、第一判断模块405和接口调用模块406。其中，收发模块401、存储操作模块402和状态设置模块403与装置实施例一和装置实施例二相同，此处不再赘述。

查询模块404，用于根据设置的时间间隔查询所述中间件缓存服务器中的业务数据。

第一判断模块405，用于判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值，如果超出预设的延迟时间阈值，则触发所述接口调用模块406。

接口调用模块406，利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，触发所述状态设置模块403将所述业务数据库中的业务数据设置为已完成的状态；所述业务消息执行结果为失败时，触发所述收发模块401将所述业务消息重新发送给所述中间件队列服务器。

同时，收发模块401进一步用于，所述业务消息执行结果为失败时，将所述业务消息重新发送给所述中间件队列服务器。状态设置模块403进一步用于，所述业务消息执行结果为成功时，将所述业务数据库中的业务数据设置为已完成的状态。

也就是说，将业务数据已经保存于中间件缓存服务器之后，查询模块404根据设置的时间间隔查询所述中间件缓存服务器中的业务数据；第一判断模块405判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值，如果超出预设的延迟时间阈值，则触发所述接口调用模块406；接口调用模块406利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，触发所述状态设置模块403将所述业务数据库中的业务数据设置为已完成的状态；所述业务消息执行结果为失败时，触发所述收发模块401将所述业务消息重新发送给所述中间件队列服务器。

应用本申请实施例方案，一方面，如果第一业务系统正常接收到第二业务系统返回的业务回执，可以确定分布式系统实现了业务数据的一致性。如果未正常接收第二业务系统的业务回执，在调用RPC接口获知第二业务系统已经成功执行业务消息时，也可以确定分布式系统实现了业务数据的一致性。上述两种方式都可以确定分布式系统实现了业务数据的一致性，因而可以将业务数据库中的该业务数据的状态变更为已完成，同时删除中间件缓存服务器中的该业务数据。

本申请实施例还提供一种分布式事务处理的系统。图6是本申请系统实施例一的结构示意图。如图6所示，该系统包括：第一业务系统601和第二业务系统602，第一业务系统601和第二业务系统602构成分布式系统，其中：

第一业务系统601，用于在接收到用户的业务请求时，将产生的业务数据进行保存，并将所述业务数据的状态设置为未完成的状态，所述业务数据为针对所述用户的业务请求所产生的数据；发送由消息队列(MQ)消息体组成的业务消息；接收由MQ消息体组成的业务回执时，将所述业务数据的状态设置为已完成的状态；

第二业务系统602，用于执行所述业务消息，并在执行完所述业务消息后反馈所述业务回执。

应用本申请系统实施例一的方案，由于将业务消息和业务回执利用MQ消息体的格式，采用异步方式传输，降低了第一业务系统601和第二业务系统602之间的耦合性；且，第一业务系统601为业务数据设置了状态，并根据业务消息的执行情况变更其业务数据的状态，从而在不引入事务协调者的情况下，仍然可以保证分布式系统中业务数据的一致性，降低了系统的复杂性。

图7是本申请系统实施例二的结构示意图。如图6所示，该系统包括第一业务系统601、第二业务系统602，还进一步包括：中间件队列服务器603、业务数据库604和中间件缓存服务器605。其中：第一业务系统601和第二业务系统602与上述实施例相同，另外：

中间件队列服务器603，用于接收所述第一业务系统601发送的由所述MQ消息体组成的业务消息，将所述MQ业务放置于消息队列中，提供给所述第二业务系统602从所述消息队列中获取所述业务消息；还用于接收所述第二业务系统602执行完所述业务消息后发送所述业务回执，将所述业务回执放置于消息队列中，提供给所述第一业务系统601从所述消息队列中获取所述业务回执。

业务数据库604，用于保存所述业务数据。

中间件缓存服务器605，用于保存所述业务数据。

在另一实施例中，第一业务系统601进一步用于，将产生的业务数据保存在业务数据库604和中间件缓存服务器605中；且，将业务数据的状态设置为已完成的状态之后，删除所述中间件缓存服务器605中的所述业务数据。

在另一实施例中，第一业务系统601还进一步用于，根据设置的时间间隔查询所述中间件缓存服务器605中的业务数据，并判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值；如果超出预设的延迟时间阈值，则利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，将所述业务数据库604中的业务数据设置为已完成的状态，且删除所述中间件缓存服务器605中的业务数据；所述业务消息执行结果为失败时，将业务消息重新发送给所述中间件队列服务器603。

应用本申请实施例方案，如果第一业务系统正常接收到第二业务系统返回的业务回执，可以确定分布式系统实现了业务数据的一致性；另一方面，如果第一业务系统未正常接收第二业务系统的业务回执，在调用RPC接口获知第二业务系统已经成功执行业务消息时，也可以确定分布式系统实现了业务数据的一致性。上述两种方式都可以确定分布式系统实现了业务数据的一致性，因而可以将业务数据库中的该业务数据的状态变更为已完成，同时删除中间件缓存服务器中的该业务数据。因此，在本申请实施例方案中，无需引入事务协调者，就可以保证分布式系统中数据的一致性，降低了系统的复杂性。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储指令，所述指令在由处理器执行时可执行如上所述分布式事务处理的方法中的步骤。实际应用中，所述的计算机可读介质可以是上述实施例各设备/装置/系统所包含的，也可以是单独存在，而未装配入该设备/装置/系统中。其中，在计算机可读存储介质中存储指令，其存储的指令在由处理器执行时可执行如上仓储订单的实现方法中的步骤。

根据本申请公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件，或者上述的任意合适的组合，但不用于限制本申请保护的范围。在本申请公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

如图8所示，本发明实施例还提供一种电子设备。如图8所示，其示出了本发明实施例所涉及的电子设备的结构示意图，具体来讲：

该电子设备可以包括一个或一个以上处理核心的处理器1001、一个或一个以上计算机可读存储介质的存储器1002以及存储在存储器上并可在处理器上运行的计算机程序。在执行所述存储器1002的程序时，可以实现上述分布式事务处理的方法。

具体的，实际应用中，该电子设备还可以包括电源803、输入输出单元804等部件。本领域技术人员可以理解，图8中示出的电子设备的结构并不构成对该电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器801是该电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器802内的软件程序和/或模块，以及调用存储在存储器802内的数据，执行服务器的各种功能和处理数据，从而对该电子设备进行整体监控。

存储器802可用于存储软件程序以及模块，即上述计算机可读存储介质。处理器801通过运行存储在存储器1002的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器802可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据服务器的使用所创建的数据等。此外，存储器802可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器802还可以包括存储器控制器，以提供处理器801对存储器802的访问。

该电子设备还包括给各个部件供电的电源803，可以通过电源管理系统与处理器801逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源803还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该电子设备还可包括输入输出单元804，该输入单元输出804可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。该输入单元输出804还可以用于显示由用户输入的信息或提供给用户的信息以及各种图像用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。

本申请附图中的流程图和框图，示出了按照本申请公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或者代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应该注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同附图中所标准的顺序发生。例如，两个连接地表示的方框实际上可以基本并行地执行，它们有时也可以按照相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或者流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本申请中。特别地，在不脱离本申请精神和教导的情况下，本申请的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，所有这些组合和/或结合均落入本申请公开的范围。

本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思路，并不用于限制本申请。对于本领域的技术人员来说，可以依据本发明的思路、精神和原则，在具体实施方式及应用范围上进行改变，其所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (14)

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

在接收到用户的业务请求时，第一业务系统将产生的业务数据进行保存，并将所述业务数据的状态设置为未完成的状态，所述业务数据为针对所述用户的业务请求所产生的数据；

所述第一业务系统发送由消息队列(MQ)消息体组成的业务消息，所述业务消息为针对所述用户的业务请求所产生的需要由第二业务系统执行的消息；

所述第一业务系统接收由MQ消息体组成的业务回执时，将所述业务数据的状态设置为已完成的状态，所述业务回执为所述第二业务系统执行完所述业务消息后反馈的消息，所述第一业务系统和所述第二业务系统构成分布式系统。

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

所述第一业务系统发送由MQ消息体组成的业务消息的步骤包括：所述第一业务系统将由所述MQ消息体组成的业务消息发送给中间件队列服务器，所述中间件队列服务器将所述MQ业务放置于消息队列中，由所述第二业务系统从所述消息队列中获取所述业务消息；

所述第一业务系统接收由MQ消息体组成的业务回执的步骤包括：所述第一业务系统从所述中间件队列服务器的消息队列中获取所述业务回执，所述业务回执为所述第二业务系统执行完所述业务消息后发送给所述中间件队列服务器的。

3.根据权利要求2所述的方法，其特征在于，所述第一业务系统将产生的业务数据进行保存的步骤包括：

所述第一业务系统先将产生的业务数据保存在业务数据库中；

所述第一业务系统再将所述业务数据保存在中间件缓存服务器；

所述将业务数据的状态设置为已完成的状态的步骤之后，该方法进一步包括：所述第一业务系统删除所述中间件缓存服务器中的所述业务数据。

4.根据权利要求3所述的方法，其特征在于，所述第一业务系统再将所述业务数据保存在中间件缓存服务器之后，该方法进一步包括：

根据设置的时间间隔查询所述中间件缓存服务器中的业务数据，并判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值；

如果超出预设的延迟时间阈值，则所述第一业务系统利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，将所述业务数据库中的业务数据设置为已完成的状态，且删除所述中间件缓存服务器中的所述业务数据；所述业务消息执行结果为失败时，将所述业务消息重新发送给所述中间件队列服务器。

5.一种分布式事务处理的装置，其特征在于，该装置包括：收发模块、存储操作模块和状态设置模块，其中：

所述收发模块，用于接收用户的业务请求；发送由消息队列(MQ)消息体组成的业务消息，所述业务消息为针对所述用户的业务请求所产生的需要由第二业务系统执行的消息；接收由MQ消息体组成的业务回执，所述业务回执为所述第二业务系统执行完所述业务消息后反馈的消息；

所述存储操作模块，用于将产生的业务数据进行保存，所述业务数据为针对所述用户的业务请求所产生的数据；

所述状态设置模块，用于将产生的业务数据进行保存时将所述业务数据的状态设置为未完成的状态；在接收由MQ消息体组成的业务回执时将所述业务数据的状态设置为已完成的状态。

6.根据权利要求5所述的装置，其特征在于，

所述收发模块发送由MQ消息体组成的业务消息时用于：将由所述MQ消息体组成的业务消息发送给中间件队列服务器，所述中间件队列服务器将所述MQ业务放置于消息队列中，由所述第二业务系统从所述消息队列中获取所述业务消息；

所述收发模块接收由MQ消息体组成的业务回执时用于：从所述中间件队列服务器的消息队列中获取所述业务回执，所述业务回执为所述第二业务系统执行完所述业务消息后发送给所述中间件队列服务器的。

7.根据权利要求6所述的装置，其特征在于，

所述存储操作模块将产生的业务数据进行保存时用于：先将产生的业务数据保存在业务数据库中，再将所述业务数据保存在中间件缓存服务器；

所述存储操作模块进一步用于：将业务数据的状态设置为已完成的状态之后，删除所述中间件缓存服务器中的所述业务数据。

8.根据权利要求7所述的装置，其特征在于，该装置进一步包括：查询模块、第一判断模块和接口调用模块；

所述查询模块，用于根据设置的时间间隔查询所述中间件缓存服务器中的业务数据；

所述第一判断模块，用于判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值，如果超出预设的延迟时间阈值，则执行所述接口调用模块；

接口调用模块，利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，触发所述状态设置模块将所述业务数据库中的业务数据设置为已完成的状态；所述业务消息执行结果为失败时，触发所述收发模块将所述业务消息重新发送给所述中间件队列服务器；

所述收发模块进一步用于，所述业务消息执行结果为失败时，将所述业务消息重新发送给所述中间件队列服务器；

所述状态设置模块进一步用于，所述业务消息执行结果为成功时，将所述业务数据库中的业务数据设置为已完成的状态。

9.一种分布式事务处理的系统，其特征在于，该系统包括：第一业务系统和第二业务系统，所述第一业务系统和所述第二业务系统构成分布式系统；其中，

所述第一业务系统，用于在接收到用户的业务请求时，将产生的业务数据进行保存，并将所述业务数据的状态设置为未完成的状态，所述业务数据为针对所述用户的业务请求所产生的数据；发送由消息队列(MQ)消息体组成的业务消息；接收由MQ消息体组成的业务回执时，将所述业务数据的状态设置为已完成的状态；

所述第二业务系统，用于执行所述业务消息，并在执行完所述业务消息后反馈所述业务回执。

10.根据权利要求9所述的系统，其特征在于，该系统进一步包括：中间件队列服务器；

所述中间件队列服务器，用于接收所述第一业务系统发送的由所述MQ消息体组成的业务消息，将所述MQ业务放置于消息队列中，提供给所述第二业务系统从所述消息队列中获取所述业务消息；还用于接收所述第二业务系统执行完所述业务消息后发送所述业务回执，将所述业务回执放置于消息队列中，提供给所述第一业务系统从所述消息队列中获取所述业务回执。

11.根据权利要求9所述的系统，其特征在于，该系统进一步包括：业务数据库和中间件缓存服务器；

所述业务数据库，用于保存所述业务数据；

所述中间件缓存服务器，用于保存所述业务数据；

所述第一业务系统进一步用于，将产生的业务数据保存在业务数据库和中间件缓存服务器中；且，将业务数据的状态设置为已完成的状态之后，删除所述中间件缓存服务器中的所述业务数据。

12.根据权利要求11所述的系统，其特征在于，

所述第一业务系统进一步用于，根据设置的时间间隔查询所述中间件缓存服务器中的业务数据，并判断所述业务数据为未完成的状态的时长是否超出预设的延迟时间阈值；如果超出预设的延迟时间阈值，则利用远程过程调用(RPC)接口调用所述第二业务系统，获取所述业务消息执行结果；所述业务消息执行结果为成功时，将所述业务数据库中的业务数据设置为已完成的状态，且删除所述中间件缓存服务器中的所述业务数据；所述业务消息执行结果为失败时，将所述业务消息重新发送给所述中间件队列服务器。

13.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被处理器执行时可实现权利要求1～4任一项所述分布式事务处理的方法的步骤。

14.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，

所述处理器执行所述计算机指令时实现上述权利要求1～4任一项分布式事务处理的方法。

Images