CN111666162A - 分布式消息传输方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本发明公开了一种分布式消息传输方法、装置、计算机设备及存储介质，所述方法通过客户端发送业务消息至第一中间件，以保存至客户数据库并返回保存结果，若保存成功则客户端执行对应的目标业务并将执行结果发送至第一中间件，若执行成功则第一中间件更新业务消息的状态为已确认，并通过MQ向服务端发送业务消息，服务端接收业务消息后通过MQ向客户端返回业务确认消息；本发明增加了第一中间件处理消息的步骤，通过巧妙地将业务消息的执行和存储维护在同一个事务中处理，减少了向MQ发送业务消息失败的可能，减少了因业务消息传输故障导致事务中断的问题，不需进行人工干预，方便快捷，提高了业务消息传输的效率和消息数据的一致性。

Description

分布式消息传输方法、装置、计算机设备及存储介质

技术领域

本发明涉及计算机数据处理技术领域，尤其涉及一种分布式消息传输方法、装置、计算机设备及存储介质。

背景技术

随着近年来互联网行业的快速发展，微服务架构的应用越来越广泛。而在微服务架构中，业务系统为了支持扩展性，都遵从分布式架构，一个业务可能会拆分到不同的进程上，而不同的进程可能在不同的虚拟机或者物理机上运行，为了保持消息数据更新的一致性以让业务的正常进行，则在进程中引入了通信队列MQ。

MQ作为一种消息中间件，用于将发送端的消息转发给消费端，以实现发送端与消费端之间的通信。

目前，利用消息中间件MQ的消息传输方式可以包括：发送端成功将多个消息依次发送给MQ，以使MQ在接收到每个消息时将消息传入消息队列，然后按照消息队列依次将消息发送给消费端，以供消息消费端消费。在此过程中，处理消息的一致性仍旧不够好：若消息发送前发送端应用故障，消息为发出导致消息丢失；中间件故障或网络故障，传输中断导致消息丢失；消费端消费成功后的确认消息返回失败，导致发送端无法接收到消费成功消息。消息传输过程若出现故障，无法准确定位故障原因，需要进行人工干预，例如进行业务重试或回滚等操作来保障业务的正确性，操作复杂且费时费力。

发明内容

本发明提供一种布式消息传输方法、装置、计算机设备及存储介质，以解决现有技术中因业务消息传输故障导致业务中断甚至失败的问题。

一种分布式消息传输方法，所述分布式消息传输方法用于分布式消息传输系统中，所述分布式消息传输系统包括：客户端、服务端、消息中间件MQ和代理系统，所述代理系统包括第一中间件，所述方法包括：

所述客户端发送待确认的业务消息至所述第一中间件，所述业务消息为执行目标业务前所生成的记录消息；

所述第一中间件接收所述业务消息后，将所述业务消息保存至客户数据库并将保存结果返回至所述客户端；

若所述保存结果为保存成功，则所述客户端执行所述目标业务得到执行结果，并将所述执行结果发送至所述第一中间件；

若所述执行结果为执行成功，则所述第一中间件更新所述业务消息的状态为已确认，并向所述MQ发送所述业务消息；

所述MQ接收所述业务消息后，将所述业务消息转换为所述服务端能识别的业务消息后发送至所述服务端；

所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息。

进一步地，所述代理系统还包括第二中间件，所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息，包括：

所述服务端接收所述业务消息后，将所述业务消息发送至所述第二中间件；

所述第二中间件接收所述业务消息后，将所述业务消息存储至消费端数据库并向所述服务端返回存储结果；

若所述存储结果为存储成功，则所述服务端接收所述存储结果后向所述MQ发送所述业务确认消息；

所述MQ接收到所述业务确认消息后，将所述业务确认消息发送至所述客户端。

进一步地，所述将所述业务消息存储至消费端数据库并向所述服务端返回存储结果之后，所述方法还包括：

若所述存储结果为存储成功，则所述服务端接收所述存储结果后对所述业务消息进行业务逻辑处理，并将处理结果发送至所述第二中间件；

若所述处理结果为处理成功，则所述第二中间件更新所述业务消息的状态为已完成；

若所述业务处理结果为处理失败，则所述第二中间件不更新所述业务消息的状态，并按第三预设间隔查询所述业务消息的状态以对所述业务消息进行业务逻辑处理，直至将所述业务消息的状态更新为已完成。

进一步地，所述向所述服务端返回存储结果之后，所述方法还包括：

若所述存储结果为存储失败，则所述服务端接收所述存储结果后，按第二预设间隔向所述第二中间件发送所述业务消息以使所述第二中间件成功存储所述业务消息。

进一步地，所述向所述MQ发送所述业务消息之后，所述方法还包括：

若业务消息发送失败，则所述第一中间件向所述客户端发送回滚请求；

所述客户端根据所述回滚请求进行所述业务消息的事务回滚以使所述MQ接收所述业务消息。

进一步地，所述将所述执行结果发送至所述第一中间件之后，所述方法还包括：

若所述执行结果为执行失败，则所述第一中间件接收所述执行结果后删除所述业务消息。

进一步地，所述将所述业务消息保存至客户数据库并将保存结果返回至所述客户端之后，所述方法还包括：

若所述保存结果为保存失败，则所述客户端接收所述保存结果后，按第一预设间隔向所述第一中间件发送所述业务消息，以使所述第一中间件成功保存所述业务消息。

一种分布式消息传输装置，所述分布式消息传输装置用于分布式消息传输系统中，所述分布式消息传输系统包括：客户端、服务端、消息中间件MQ和代理系统，所述代理系统包括第一中间件，所述装置包括：

发送模块，用于所述客户端发送待确认的业务消息至所述第一中间件，所述业务消息为执行目标业务前所生成的记录消息；

保存模块，用于所述第一中间件接收所述业务消息后，将所述业务消息保存至客户数据库并将保存结果返回至所述客户端；

执行模块，用于若所述保存结果为保存成功，则所述客户端执行所述目标业务得到执行结果，并将所述执行结果发送至所述第一中间件；

更新模块，用于若所述执行结果为执行成功，则所述第一中间件更新所述业务消息的状态为已确认，并向所述MQ发送所述业务消息；

转换模块，用于所述MQ接收所述业务消息后，将所述业务消息转换为所述服务端能识别的业务消息后发送至所述服务端；

返回模块，用于所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息。

一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述分布式消息传输方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述分布式消息传输方法的步骤。

上述分布式消息传输方法、装置、计算机设备及存储介质，所述方法通过客户端发送业务消息至第一中间件，第一中间件将业务消息保存至客户数据库并返回保存结果，若保存结果为保存成功，则客户端执行对应的目标业务并将执行结果发送至第一中间件，若执行结果为执行成功，则第一中间件更新业务消息的状态为已确认，并通过MQ向服务端发送业务消息，服务端接收业务消息后，通过MQ向客户端返回业务确认消息；本发明为减少消息传输过程中出现故障导致业务处理失败的情况，在客户端将业务消息发送给消息中间件MQ之前，增加了第一中间件处理消息的步骤，通过将客户端发送的业务消息进行本地存储和处理后再发送至MQ，巧妙地将业务消息的执行和存储维护在同一个事务中处理，减少了向MQ发送业务消息失败的可能，减少了因业务消息传输故障导致事务中断的问题，也不需进行人工干预，方便快捷，提高了业务消息传输的效率和业务消息数据的一致性。

附图说明

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

图1是本发明一实施例中分布式消息传输系统的应用示意图；

图2是本发明一实施例中分布式消息传输方法的一流程示意图；

图3是本发明一实施例中分布式消息传输方法的另一流程示意图；

图4是本发明一实施例中步骤S60的一实现流程示意图；

图5是本发明一实施例中分布式消息传输装置的一结构示意图；

图6是本发明一实施例中计算机设备的一结构示意图。

具体实施方式

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

本发明实施例提供的分布式消息传输方法，可应用在如图1的分布式消息传输系统中，所述分布式消息传输系统包括客户端、服务端、消息中间件MQ和代理系统，代理系统包括第一中间件，其中，客户端、服务端、消息中间件MQ和代理系统通过网络进行通信，以实现本发明所提供的一种分布式消息传输方法。

其中，客户端、服务端、消息中间件MQ和代理系统均可以用独立的服务器或者是多个服务器组成的服务器集群来实现。其中，本发明中的代理系统是使用epcis-mq封装的系统。

在一实施例中，如图2所示，提供一种分布式消息传输方法，客户端作为的发送方，服务端作为分布式消息传输的接收方，包括如下步骤：

S10：客户端发送待确认的业务消息至第一中间件，业务消息为执行目标业务前所生成的记录消息。

客户端发送待确认的业务消息至第一中间件，其中，业务消息为执行目标业务前所生成的记录消息。

例如，客户端要向服务端支付100元，在对客户端账户进行扣款100元前，客户端向第一中间件发送一条待确认的业务信息：服务端请收款100元。

本实施例中，业务消息为服务端请收款100元仅仅为示例性说明，在其他实施例中，业务消息还可以是其他，在此不再赘述。

S20：第一中间件接收业务消息后，将业务消息保存至客户数据库并将保存结果返回至客户端。

在第一中间件在接收到客户端发送的业务信息之后，将业务信息持久化到代理系统中的客户数据库中，在客户数据库以客户业务表的形式保存，并将业务信息的保存结果返回至客户端。

例如，第一中间件把“服务端请收款100元”这条消息保存到客户数据库中的客户业务表，并在客户业务表中将这条业务消息的状态标为“待确认”，向客户端返回保存结果。

例如，该客户业务表的结构可以以下表1举例说明：

表1

ID	业务信息	状态
			1	服务端请收款50元	已确认
2	服务端请收款100元	待确认
			3	服务端请收款300元	待确认

本实施例中，客户业务表的结构以及内容仅为示例性说明，在其他实施例中，客户业务表的结构以及内容还可以是其他，在此不再赘述。

在一实施例中，在第一中间件在接收到客户端发送的业务信息之后，步骤S20中，即将业务消息保存至客户数据库并将保存结果返回至客户端之后，所述方法还包括：

S21：若保存结果为保存失败，则客户端接收保存结果后，按第一预设间隔向第一中间件发送业务消息，以使第一中间件成功保存业务消息。

在第一中间件接收业务消息之后，将业务消息保存至客户数据库的时候，若保存结果为保存失败，则客户端接收保存结果后，按第一预设间隔向第一中间件发送业务消息，以使第一中间件成功保存业务消息至客户端数据库。

例如，第一预设间隔为10秒，若保存结果为保存成功，客户端收到保存失败的结果后，每隔10秒向第一中间件发送业务消息，直到第一中间件成功保存业务消息。

若保存结果为保存成功，则保存结果返回至客户端并告诉客户端该业务消息已经保存成功，可以执行目标业务扣款100元了。

本实施例中，第一预设间隔为10秒仅为示例性说明，在其他实施例中，第一预设间隔为10秒还可以是其他，在此不再赘述。

该步骤确保业务消息能成功保存到本地的客户端数据库中，为后续客户端执行业务提供了可靠基础，提高了数据传输的可靠性。

S30：若保存结果为保存成功，则客户端执行目标业务得到执行结果，并将执行结果发送至向第一中间件。

在第一中间件接收业务消息之后，将业务消息保存至客户数据库的时候，若保存结果为保存成功，则客户端执行目标业务得到执行结果，并将执行结果发送至向第一中间件。

例如，业务消息为服务端请收款100元，业务消息对应的目标任务为从客户端账户中扣除100元，若保存结果为保存成功，客户端收到保存成功的结果后，就开始执行目标业务，即从客户端账户中扣除100元，在执行完成后获得执行结果：执行成功或执行失败，此时，第一中间件将会把客户业务表中该业务消息的状态由“待确认”改为“已确认”，并将执行结果发送给第一中间件。

在一实施例中，将执行结果发送至第一中间件之后，步骤S30中，即客户端执行目标业务得到执行结果，并将执行结果发送至向第一中间件，所述方法还包括：

S31：若执行结果为执行失败，则第一中间件接收执行结果后删除业务消息。

若客户端执行该业务消息对应的目标业务的执行结果为执行失败，则第一中间件在接收客户端发送的执行结果之后，将客户业务表中该业务消息直接删除掉该业务消息，或者，将客户业务表中该业务消息的状态更新为“失败”状态。

该步骤将执行失败的业务消息直接删除或者将业务消息状态改为失败，能避免后续客户端重复执行该业务，或者将执行失败的业务消息误发出去，保证了数据传输的一致性。

S40：若执行结果为执行成功，则第一中间件更新业务消息的状态为已确认，并向MQ发送业务消息。

将执行结果发送至第一中间件之后，若客户端执行该业务消息对应的目标业务的执行结果为执行成功，则第一中间件在接收客户端发送的执行结果之后，将客户业务表中该业务消息的状态更新为已确认，并向MQ发送业务消息。

例如，执行从客户端账户中扣除100元，若执行结果为执行成功，即在客户端成功扣款100元，则第一中间件将业务消息“服务端请收款100元”的状态更新为已确认，并向真正的消息中间件MQ发送业务消息“服务端请收款100元”。

在一实施例中，图3所示，步骤S40之后，即向MQ发送业务消息之后，所述方法还具体包括以下步骤：

S41:若业务消息发送失败，则第一中间件向客户端发送回滚请求。

在第一中间件更新业务消息的状态为已确认，并向MQ发送业务消息之后，若第一中间件向消息中间件MQ发送业务消息失败，则第一中间件向客户端发送回滚请求，使得客户端回滚本地事物以重新执行之前的步骤。

S42:客户端根据回滚请求进行业务消息的事务回滚以使MQ接收业务消息。

在第一中间件向客户端发送回滚请求之后，客户端根据第一中间件发送的回滚请求进行业务消息的事务回滚，以消除之前客户端和第一中间件的操作痕迹，重新执行业务消息发送失败之前的步骤。其中，在进行事物回滚的过程中，若重新执行后仍旧发送失败，再度循环，以使MQ接收业务消息。

由于步骤S10-S40的操作都是在客户数据库中进行，所以步骤S10-S40的操作属于本地事务，若向MQ发送业务消息失败，可以进行本地事务回滚。

本实施例中，在第一中间件更新业务消息的状态为已确认，并向MQ发送业务消息之后，若业务消息发送失败，则第一中间件向客户端发送回滚请求，客户端根据回滚请求进行业务消息的事务回滚以使MQ接收业务消息，直接在故障发生时进行事务回滚，省时省力，减少了业务消息传输过程中出现故障而无法准确定位故障原因的可能，也不需要进行人工干预，保障了业务消息的正确性。

S50：MQ接收业务消息后，将业务消息转换为服务端能识别的业务消息后发送至服务端。

MQ接收到第一中间件发送的业务消息后，将业务消息进行转换，以使转换后的业务消息能被服务端识别，在将业务消息转换为服务端能识别的业务消息后，MQ将转换后的业务消息保存并发送至服务端。

S60：服务端接收业务消息后，通过MQ向客户端返回业务确认消息。

服务端在接收到MQ发送的业务消息之后，对接收到的业务消息进行确认，在确认业务消息已完成后，向MQ发送业务确认消息，以使MQ将接收到的业务确认消息返回至客户端。

例如，服务端接收到MQ发送的业务消息“服务端请收款100元”后，服务端查询自身账户，以确认是否收到客户端的100元付款，若确认已收款100元，则向MQ发送业务确认消息“已收到客户端付款100元”，以使MQ将接收到“已收到客户端付款100元”返回至客户端。

在常规业务处理逻辑中，客户端向服务端支付100元(业务消息)，在支付过程中，客户端需要先扣除100元，然后通过消息中间件发送支付消息给服务端，服务端接收支付消息，并相应地在服务端账户中增加100元。在此过程中，由于客户端与服务端对支付业务的处理在不同的数据库中，属于不同的数据库事务，支付过程容易发生意外，例如，客户端扣款后发现需支付消息发送失败，导致服务端未收到支付消息并收款。

本发明中，对客户端和服务端进行epcis-mq封装获得的代理系统，配置简单仅需要引用epcis-mq包和配置mq地址；封装的代理系统使用简单，通过简单的注解就可以实现业务消息的发送和对应业务的执行，在发送或执行时出现问题还可以进行重试、停止或者回滚等；还可实现对不同业务的顺序进行控制(延时处理或分组处理)，做到对开发人员屏蔽消息组件复杂的处理细节，以简单的api方式提供给开发人员使用，降低使用门槛，减少出错概率。

本实施例中，通过客户端发送业务消息至第一中间件，第一中间件将业务消息保存至客户数据库并返回保存结果，若保存结果为保存成功，则客户端执行对应的目标业务并将执行结果发送至第一中间件，若执行结果为执行成功，则第一中间件更新业务消息的状态为已确认，并通过MQ向服务端发送业务消息，服务端接收业务消息后，通过MQ向客户端返回业务确认消息；本发明为减少消息传输过程中出现故障导致业务处理失败的情况，在客户端将业务消息发送给消息中间件MQ之前，增加了第一中间件处理消息的步骤，通过将客户端发送的业务消息进行本地存储和处理后再发送至MQ，巧妙地将业务消息的执行和存储维护在同一个事务中处理，减少了向MQ发送业务消息失败的可能，减少了因业务消息传输故障导致事务中断的问题，也不需进行人工干预，方便快捷，提高了业务消息传输的效率和业务消息数据的一致性。

在一实施例中，如图4所示，所述代理系统还包括第二中间件，步骤S60中，即服务端接收业务消息后，通过MQ向客户端返回业务确认消息，具体包括如下步骤：

S61：服务端接收业务消息后，将业务消息发送至第二中间件。

服务端接收到MQ发送的业务消息后，将接收到的业务消息发送给代理系统的第二中间件。

S62：第二中间件接收业务消息后，将业务消息存储至消费端数据库并向服务端返回存储结果。

第二中间件接收业务消息后，将业务消息存储至代理系统中的消费端数据库，将业务消息在消费端数据库以消费业务表的形式保存，并将业务信息的存储结果返回至并向服务端。

例如，在接收业务消息之后，第二中间件把“服务端请收款100元”这条消息保存到消费端数据库中的消费业务表，在消费业务表中将“服务端请收款100元”这条业务消息的状态标为“未消费”，并向消费端返回存储结果。

例如，该消费业务表的结构可以以下表2举例说明：

表2

ID	业务信息	状态
			1	服务端请收款50元	已完成
2	服务端请收款100元	未消费
			3	服务端请收款300元	未消费

本实施例中，该消费业务表的结构以及内容仅为示例性说明，在其他实施例中，该消费业务表的结构以及内容还可以是其他，在此不再赘述。

在一实施例中，步骤S62中，即将业务消息存储至消费端数据库并向服务端返回存储结果之后，该方法还包括：

S621：若存储结果为存储失败，则服务端接收存储结果后，按第二预设间隔向第二中间件发送业务消息以使第二中间件成功存储业务消息。

第二中间件将业务消息存储至消费端数据库并向服务端返回存储结果之后，若第二中间件存储业务消息的存储结果为存储失败，则服务端接收存储结果后，MQ定时推送业务消息到消费端，然后消费端按第二预设间隔向第二中间件发送业务消息以使第二中间件成功存储业务消息。

例如，第二预设间隔为10秒，若存储结果为存储成功，服务端收到存储失败的结果后，MQ定时推送业务消息到消费端，服务端每隔10秒向第二中间件发送业务消息，直到第二中间件成功存储业务消息。

本实施例中，第二预设间隔为10秒仅为示例性说明，在其他实施例中，第二预设间隔还可以是其他，在此不再赘述。

该步骤确保业务消息能成功保存到本地的消费端数据库中，为后续对业务消息的处理提供了可靠基础，提高了数据传输的可靠性。

S63：若存储结果为存储成功，则服务端接收存储结果后向MQ发送业务确认消息。

第二中间件将业务消息存储至消费端数据库并向服务端返回存储结果之后，若存储结果为存储成功，则服务端接收存储结果后向MQ发送业务确认消息，表示服务端已收到该业务信息。

例如，第二中间件将业务消息存储至消费端数据库并向服务端返回存储结果之后，若第二中间件的成功存储业务消息“服务端请收款100元”，则服务端接收存储结果后向MQ发送业务确认消息，告诉MQ已经收到了业务消息“服务端请收款100元”。

S64：MQ接收到业务确认消息后，将业务确认消息发送至客户端。

在服务端接收存储结果后向MQ发送业务确认消息之后，MQ接收到业务确认消息后，会将业务确认消息发送至客户端，以使客户端获知服务端已收到业务消息，从而不再重复向服务端发送该业务消息，确保业务消息传输的一致性。

例如，MQ接收到服务端发送的业务确认消息后，将收到的业务确认消息发送给客户端，告诉客户端：服务端收到了业务消息“服务端请收款100元”，客户端获知服务端已收到业务消息“服务端请收款100元”之后，则不再向服务端发送业务消息“服务端请收款100元”，表示该业务成功完成。

本实施例中，服务端接收业务消息后，将业务消息发送至第二中间件，第二中间件接收业务消息后，将业务消息存储至消费端数据库并向服务端返回存储结果，若存储结果为存储成功，则服务端接收存储结果后向MQ发送业务确认消息，MQ接收到业务确认消息后，将业务确认消息发送至客户端；本发明在服务端接收业务消息之后，通过将业务消息发送至第二中间件进行本地存储和处理后再返回业务确认信息给MQ，巧妙地将业务消息的业务处理和存储维护在同一个事务中，减少了向MQ返回业务确认消息失败的可能，减少了因业务消息传输故障导致服务端与客户端数据不一致的问题，也不需进行人工干预，方便快捷，提高了业务消息传输的效率。

在一实施例中，将业务消息存储至消费端数据库并向服务端返回存储结果之后，所述方法还包括：

S631：若存储结果为存储成功，服务端接收存储结果后对业务消息进行业务逻辑处理，并将处理结果发送至第二中间件；

第二中间件向服务端返回存储结果后，若存储结果为存储成功，服务端接收存储结果后向MQ发送业务确认消息的同时，服务端接收到业务消息存储成功的结果后，按照服务端业务处理逻辑对该业务消息进行业务操作(，并将处理结果发送给第二中间件。

对该业务消息进行的业务操作包括增加、删除、查询等，处理结果包括处理成功、处理失败两种结果。

例如，服务端接收到第二中间件存储业务消息成功的结果后，由于该条业务消息为“服务端请收款100元”，则服务端需要查询是否入账，若已入账，则在自身的账户余额增加100元，并将处理结果发送给第二中间件。

S632：若处理结果为处理成功，则第二中间件更新业务消息的状态为已完成。

在服务端接收存储结果后对业务消息进行业务逻辑处理，并将处理结果发送至第二中间件之后，若服务端对业务消息进行业务逻辑处理的处理结果为处理成功，则第二中间件更新业务消息的状态为已完成。

例如，在接收搭配服务端发送的处理结果后，若处理结果为处理成功，则第二中间件将消费业务表“服务端请收款100元”这条消息的状态改成“已完成”。

S633：若业务处理结果为处理失败，则第二中间件不更新业务消息的状态，并按第三预设间隔查询业务消息的状态以对业务消息进行业务逻辑处理，直至将业务消息的状态更新为已完成。

在服务端接收存储结果后对业务消息进行业务逻辑处理，并将处理结果发送至第二中间件之后，若服务端对业务消息进行业务逻辑处理的处理结果为处理失败，表示业务逻辑处理的过程出现问题，则第二中间件不更新服务端数据库消费业务表中该业务消息的状态，并按第三预设间隔定时查询消费业务表中未完成的业务消息，并对未完成业务消息进行业务逻辑处理，直至将业务消息的状态更新为已完成。

例如，第三预设间隔为8秒，该条业务消息为“服务端请收款100元”，则服务端需要查询是否入账，若已入账，则在自身的账户余额增加100元，但处理结果为在自身的账户余额增加100元失败，表示业务逻辑处理的过程出现问题，则第二中间件不更新服务端数据库消费业务表中该业务消息的状态，消费业务表中该业务消息的状态仍旧为未完成，第二中间件每隔8秒定时查询消费业务表中未完成的业务消息，并对该未完成的业务消息“服务端请收款100元”进行业务逻辑处理，直至将业务消息“服务端请收款100元”的状态更新为已完成。

本实施例中，第三预设间隔为8秒仅为示例性说明，在其他实施例中，第三预设间隔还可以是其他，在此不再赘述。

其中，因为通过第二中间件将业务消息存储和本地数据库中，业务消息的存储和业务逻辑处理属于本地事务，可以将对处理步骤进行回滚，即相当于这个消息没被处理过，需要重新进行业务逻辑处理直到处理成功，并将消费业务表中该业务消息的状态更新为“已完成”。这时，整个付款操作都有已经完成了，例如，客户端成功扣款100元，服务端成功收款100元。

本实施例中，第二中间件向服务端返回存储结果后，若存储结果为存储成功，服务端接收存储结果后向MQ发送业务确认消息的同时，还对业务消息进行业务逻辑处理，将处理结果发送至第二中间件以更改服务端数据库中该业务消息的状态，并在业务逻辑处理失败时定时查询未完成的业务消息以重新进行业务逻辑处理直至成功，保证了服务端对业务消息对应业务的成功处理，减少了因服务端消息数据不能回滚导致的与客户端消息数据不一致的情况。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

在一实施例中，提供一种分布式消息传输装置，该分布式消息传输装置与上述实施例中分布式消息传输方法一一对应。该分布式消息传输装置用于分布式消息传输系统中，所述分布式消息传输系统包括：客户端、服务端、消息中间件MQ和代理系统，所述代理系统包括第一中间件，如图5所示，该分布式消息传输装置包括发送模块501、保存模块502、执行模块503、更新模块504、转换模块505和返回模块506。各功能模块详细说明如下：

发送模块501，用于所述客户端发送待确认的业务消息至所述第一中间件，所述业务消息为执行目标业务前所生成的记录消息；

保存模块502，用于所述第一中间件接收所述业务消息后，将所述业务消息保存至客户数据库并将保存结果返回至所述客户端；

执行模块503，用于若所述保存结果为保存成功，则所述客户端执行所述目标业务得到执行结果，并将所述执行结果发送至所述第一中间件；

更新模块504，用于若所述执行结果为执行成功，则所述第一中间件更新所述业务消息的状态为已确认，并向所述MQ发送所述业务消息；

转换模块505，用于所述MQ接收所述业务消息后，将所述业务消息转换为所述服务端能识别的业务消息后发送至所述服务端；

返回模块506，用于所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息。

其中，所述代理系统还包括第二中间件，所述返回模块506具体用于：

所述服务端接收所述业务消息后，将所述业务消息发送至所述第二中间件；

所述第二中间件接收所述业务消息后，将所述业务消息存储至消费端数据库并向所述服务端返回存储结果；

若所述存储结果为存储成功，则所述服务端接收所述存储结果后向所述MQ发送所述业务确认消息；

所述MQ接收到所述业务确认消息后，将所述业务确认消息发送至所述客户端。

其中，所述返回模块506具体还用于：

若所述存储结果为存储成功，则所述服务端接收所述存储结果后对所述业务消息进行业务逻辑处理，并将处理结果发送至所述第二中间件；

若所述处理结果为处理成功，则所述第二中间件更新所述业务消息的状态为已完成；

若所述业务处理结果为处理失败，则所述第二中间件不更新所述业务消息的状态，并按第三预设间隔查询所述业务消息的状态以对所述业务消息进行业务逻辑处理，直至将所述业务消息的状态更新为已完成。

其中，所述返回模块506具体还用于：

若所述存储结果为存储失败，则所述服务端接收所述存储结果后，按第二预设间隔向所述第二中间件发送所述业务消息以使所述第二中间件成功存储所述业务消息。

其中，所述更新模块504具体还用于：

若业务消息发送失败，则所述第一中间件向所述客户端发送回滚请求；

所述客户端根据所述回滚请求进行所述业务消息的事务回滚以使所述MQ接收所述业务消息。

其中，所述执行模块503具体还用于：

若所述执行结果为执行失败，则所述第一中间件接收所述执行结果后删除所述业务消息。

其中，所述保存模块502具体还用于：

若所述保存结果为保存失败，则所述客户端接收所述保存结果后，按第一预设间隔向所述第一中间件发送所述业务消息，以使所述第一中间件成功保存所述业务消息。

关于分布式消息传输装置的具体限定可以参见上文中对于分布式消息传输方法的限定，在此不再赘述。上述分布式消息传输装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部服务器通过网络连接通信。该计算机程序被处理器执行时以实现一种分布式消息传输方法。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

所述客户端发送待确认的业务消息至所述第一中间件，所述业务消息为执行目标业务前所生成的记录消息；

所述第一中间件接收所述业务消息后，将所述业务消息保存至客户数据库并将保存结果返回至所述客户端；

若所述保存结果为保存成功，则所述客户端执行所述目标业务得到执行结果，并将所述执行结果发送至所述第一中间件；

若所述执行结果为执行成功，则所述第一中间件更新所述业务消息的状态为已确认，并向所述MQ发送所述业务消息；

所述MQ接收所述业务消息后，将所述业务消息转换为所述服务端能识别的业务消息后发送至所述服务端；

所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

所述客户端发送待确认的业务消息至所述第一中间件，所述业务消息为执行目标业务前所生成的记录消息；

所述第一中间件接收所述业务消息后，将所述业务消息保存至客户数据库并将保存结果返回至所述客户端；

若所述保存结果为保存成功，则所述客户端执行所述目标业务得到执行结果，并将所述执行结果发送至所述第一中间件；

若所述执行结果为执行成功，则所述第一中间件更新所述业务消息的状态为已确认，并向所述MQ发送所述业务消息；

所述MQ接收所述业务消息后，将所述业务消息转换为所述服务端能识别的业务消息后发送至所述服务端；

所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims (10)

1.一种分布式消息传输方法，其特征在于，所述分布式消息传输方法用于分布式消息传输系统中，所述分布式消息传输系统包括：客户端、服务端、消息中间件MQ和代理系统，所述代理系统包括第一中间件，所述方法包括：

所述客户端发送待确认的业务消息至所述第一中间件，所述业务消息为执行目标业务前所生成的记录消息；

所述第一中间件接收所述业务消息后，将所述业务消息保存至客户数据库并将保存结果返回至所述客户端；

若所述保存结果为保存成功，则所述客户端执行所述目标业务得到执行结果，并将所述执行结果发送至所述第一中间件；

若所述执行结果为执行成功，则所述第一中间件更新所述业务消息的状态为已确认，并向所述MQ发送所述业务消息；

所述MQ接收所述业务消息后，将所述业务消息转换为所述服务端能识别的业务消息后发送至所述服务端；

所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息。

2.如权利要求1所述的分布式消息传输方法，其特征在于，所述代理系统还包括第二中间件，所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息，包括：

所述服务端接收所述业务消息后，将所述业务消息发送至所述第二中间件；

所述第二中间件接收所述业务消息后，将所述业务消息存储至消费端数据库并向所述服务端返回存储结果；

若所述存储结果为存储成功，则所述服务端接收所述存储结果后向所述MQ发送所述业务确认消息；

所述MQ接收到所述业务确认消息后，将所述业务确认消息发送至所述客户端。

3.如权利要求2所述的分布式消息传输方法，其特征在于，所述将所述业务消息存储至消费端数据库并向所述服务端返回存储结果之后，所述方法还包括：

若所述存储结果为存储成功，则所述服务端接收所述存储结果后对所述业务消息进行业务逻辑处理，并将处理结果发送至所述第二中间件；

若所述处理结果为处理成功，则所述第二中间件更新所述业务消息的状态为已完成；

若所述业务处理结果为处理失败，则所述第二中间件不更新所述业务消息的状态，并按第三预设间隔查询所述业务消息的状态以对所述业务消息进行业务逻辑处理，直至将所述业务消息的状态更新为已完成。

4.如权利要求2所述的分布式消息传输方法，其特征在于，所述向所述服务端返回存储结果之后，所述方法还包括：

若所述存储结果为存储失败，则所述服务端接收所述存储结果后，按第二预设间隔向所述第二中间件发送所述业务消息以使所述第二中间件成功存储所述业务消息。

5.如权利要求4所述的分布式消息传输方法，其特征在于，所述向所述MQ发送所述业务消息之后，所述方法还包括：

若业务消息发送失败，则所述第一中间件向所述客户端发送回滚请求；

所述客户端根据所述回滚请求进行所述业务消息的事务回滚以使所述MQ接收所述业务消息。

6.如权利要求5所述的分布式消息传输方法，其特征在于，所述将所述执行结果发送至所述第一中间件之后，所述方法还包括：

若所述执行结果为执行失败，则所述第一中间件接收所述执行结果后删除所述业务消息。

7.如权利要求1-6任一项所述的分布式消息传输方法，其特征在于，所述将所述业务消息保存至客户数据库并将保存结果返回至所述客户端之后，所述方法还包括：

若所述保存结果为保存失败，则所述客户端接收所述保存结果后，按第一预设间隔向所述第一中间件发送所述业务消息，以使所述第一中间件成功保存所述业务消息。

8.一种分布式消息传输装置，其特征在于，所述分布式消息传输装置用于分布式消息传输系统中，所述分布式消息传输系统包括：客户端、服务端、消息中间件MQ和代理系统，所述代理系统包括第一中间件，所述装置包括：

发送模块，用于所述客户端发送待确认的业务消息至所述第一中间件，所述业务消息为执行目标业务前所生成的记录消息；

保存模块，用于所述第一中间件接收所述业务消息后，将所述业务消息保存至客户数据库并将保存结果返回至所述客户端；

执行模块，用于若所述保存结果为保存成功，则所述客户端执行所述目标业务得到执行结果，并将所述执行结果发送至所述第一中间件；

更新模块，用于若所述执行结果为执行成功，则所述第一中间件更新所述业务消息的状态为已确认，并向所述MQ发送所述业务消息；

转换模块，用于所述MQ接收所述业务消息后，将所述业务消息转换为所述服务端能识别的业务消息后发送至所述服务端；

返回模块，用于所述服务端接收业务消息后，通过所述MQ向所述客户端返回业务确认消息。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述分布式消息传输方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述分布式消息传输方法的步骤。

Images