基于消息队列的业务请求重传方法、装置及可读存储介质与流程

本发明涉及计算机网络应用技术，具体而言，涉及一种基于消息队列的业务请求重传方法、装置、设备及可读存储介质。

背景技术

在电商系统中，多个系统平台之间需要进行通信，当第一次通信失败后，可能需要间隔不同时间频率发起重试。例如台账反查业务。台账反查是指用户在网上商城平台充值手机话费时，用户选择对应面值并进行支付后，支付平台会将用户支付结果通知网上商城平台，之后网上商城平台再根据用户支付结果进行后续充值动作。而如果用户支付完成后，支付平台没有及时将用户支付结果通知网上商城平台，则网上商城平台会主动通过接口方式去支付平台进行用户支付结果的查询。

目前，网上商城平台是通过定时任务查询缓存，循环不同时间段支付未确认信息来进行台账反查的。但通过该种方法每次查询时都需要循环缓存，会大幅增加业务服务器的开销，即使当前时间段内没有需要反查的订单，定时任务也会被启动去扫描缓存。此外，待反查订单暂缓在jvm(javavirtualmachine，java虚拟机)缓存中，存在数据安全的问题。

在所述背景技术部分公开的上述信息仅用于加强对本发明的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本发明提供一种基于消息队列的业务请求重传方法、装置、设备及可读存储介质，能够实现不同频率的重发请求，且可以降低业务服务器的负载及提高消息安全性。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明的一方面，提供一种基于消息队列的业务请求重传方法，包括：发送业务消息队列中的业务请求；以及当在一预设的时间阈值内未收到所述业务请求的响应消息或者检测到所述业务请求发送失败时，根据预设的配置文件链，将所述业务请求放入多个重试消息队列中的第一重试消息队列中；其中，所述多个重试消息队列具有不同的消息过期时间；所述配置文件链用于确定所述业务请求在所述多个重试消息队列中的路由顺序。

根据本发明的一实施方式，上述方法还包括：当所述业务请求在所述第一重试消息队列中的消息过期时间到期时，将所述业务请求放入到重分发总消息队列中；根据所述业务请求的属性，将所述业务请求从所述重分发总消息队列中路由到所述业务消息队列中；以及重发所述业务消息队列中的所述业务请求。

根据本发明的一实施方式，在所述重发所述业务消息队列中的所述业务请求之后，上述方法还包括：当在所述时间阈值内未收到所述业务请求的响应消息或者检测到所述业务请求重发失败时，根据预设的配置文件链，将所述业务请求放入所述多个重试消息队列中的第二重试消息队列中；其中，所述第二重试消息队列的消息过期时间长于所述第一重试消息队列的消息过期时间。

根据本发明的一实施方式，所述多个重试消息队列均为死信队列。

根据本发明的一实施方式，上述方法还包括：将接收到的所述业务请求放入到接收总消息队列中；以及根据所述业务请求的属性，将所述业务请求从所述接收总消息队列中路由到所述业务消息队列中。

根据本发明的另一个方面，提供一种基于消息队列的业务请求重传装置，包括：业务请求发送模块，用于发送业务消息队列中的业务请求；以及业务请求处理模块，用于当在一预设的时间阈值内未收到所述业务请求的响应消息或者检测到所述业务请求发送失败时，根据预设的配置文件链，将所述业务请求放入多个重试消息队列中的第一重试消息队列中；其中，所述多个重试消息队列具有不同的消息过期时间；所述配置文件链用于确定所述业务请求在所述多个重试消息队列中的路由顺序。

根据本发明的一实施方式，上述装置还包括：业务请求重分发模块，用于当所述业务请求在所述第一重试消息队列中的消息过期时间到期时，将所述业务请求放入到重分发总消息队列中；业务请求路由模块，用于根据所述业务请求的属性，将所述业务请求从所述重分发总消息队列中路由到所述业务消息队列中；以及业务请求重发模块，用于重发所述业务消息队列中的所述业务请求。

根据本发明的一实施方式，所述业务请求处理模块还用于：在所述业务请求重发模块重发所述业务消息队列中的所述业务请求之后，当在所述时间阈值内未收到所述业务请求的响应消息或者检测到所述业务请求重发失败时，根据预设的配置文件链，将所述业务请求放入所述多个重试消息队列中的第二重试消息队列中；其中，所述第二重试消息队列的消息过期时间长于所述第一重试消息队列的消息过期时间。

根据本发明的一实施方式，所述多个重试消息队列均为死信队列。

根据本发明的一实施方式，上述装置还包括：业务请求接收模块，用于将接收到的所述业务请求放入到接收总消息队列中；其中，所述业务请求路由模块还用于根据所述业务请求的属性，将所述业务请求从所述接收总消息队列中路由到所述业务消息队列中。

根据本发明的再一个方面，提供一种计算机可读存储介质，其上存储有计算机可执行指令，所述可执行指令被处理器执行时实现如上述任意一种方法。

根据本发明的再一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行如上述任意一种基于消息队列的业务请求重传方法的步骤。

根据本发明实施方式的基于消息队列的业务请求重传方法，利用设置具有不同的消息过期时间的重试消息队列，可实现不同频率的重发请求，且将业务请求放到消息队列中，可以降低业务服务器的负载及提高消息安全性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。

附图说明

通过参照附图详细描述其示例实施例，本发明的上述和其它目标、特征及优点将变得更加显而易见。

图1是根据一示例性实施方式示出的本发明方法的应用场景。

图2是根据一示例性实施方式示出的一种基于消息队列的业务请求重传方法的流程图。

图3是根据一示例性实施方式示出的应用于本发明方法的系统的架构图。

图4是根据一示例性实施方式示出的另一种基于消息队列的业务请求重传方法的流程图。

图5是根据一示例示出的业务请求的路由示意图。

图6是根据一示例示出的业务请求流向示意图。

图7是根据一示例性实施方式示出的一种基于消息队列的业务请求重传装置的框图。

图8是根据一示例性实施方式示出的一种电子设备的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现或者操作以避免喧宾夺主而使得本发明的各方面变得模糊。

消息队列(messagequeue，mq)是一种存放消息的队列，其以同步或异步方式为分布式应用提供了松耦合方法。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。

图1是根据一示例性实施方式示出的本发明方法的应用场景。如图1所示，在该场景中，包括：至少一台业务请求服务器11、至少一台消息队列服务器12及至少一台业务处理服务器13。其中，业务请求服务器11借助于消息队列服务器12中的消息队列，向业务处理服务器13发送或重发业务请求，以请求业务处理服务器13对该业务请求进行处理。以台账反查业务为例，业务请求服务器11例如可以为网上商城平台服务器，业务处理服务器13例如可以为支付平台服务器。

图2是根据一示例性实施方式示出的一种基于消息队列的业务请求重传方法的流程图。结合图1和图2所示，方法10包括：

在步骤s102中，发送业务消息队列中的业务请求。

例如，业务消息队列位于图1中的消息队列服务器12中，业务消息队列中可承载有相同类型的业务请求消息。当业务请求服务器11需要对业务消息队列中的业务请求进行处理时，向业务处理服务器13发送业务请求。

在步骤s104中，当在一预设的时间阈值内未收到业务请求的响应消息或者检测到该业务请求发送失败时，根据预设的配置文件链，将业务请求放入多个重试消息队列中的第一重试消息队列中。

其中，多个重试消息队列分别具有不同的消息过期时间。

例如，业务请求服务器11向业务处理服务器13发送业务请求后，在一预设的时间阈值内未收到业务处理服务器13返回的响应消息时，业务请求服务器根据预设的配置文件链，将该业务请求放入到消息队列服务器12的多个重试消息队列中的第一重试消息队列中。在实际应用中，该时间阈值的长度可以根据实际需求来设定，本发明不以此为限。此外在实际应用中，例如可以通过启动定时器的方式实现对该时间阈值的监控。如在发送业务消息队列中的业务请求后，启动一定时器，其长度为该时间阈值，如果定时器到期后仍然未收到该响应消息时，则根据预设的配置文件链，将业务请求放入多个重试消息队列中的第一重试消息队列中。

或者，由于异常原因检测到该业务请求的发送失败时，也同样执行根据预设的配置文件链，将业务请求放入多个重试消息队列中的第一重试消息队列中的操作。

配置文件链用于规定业务请求在多个重试消息队列中的路由顺序。例如，当首次发送失败后，将业务请求放置到第一重试消息队列中；当重发失败后，将业务请求放置到第二重试消息队列中；当再次重发失败后，将业务请求放置到第三重试消息队列中等。配置文件链中例如通过各重试消息队列的路由标识(routingid)来定义该路由顺序。

根据本发明实施方式的基于消息队列的业务请求重传方法，利用设置具有不同的消息过期时间的重试消息队列，可实现不同频率的重发请求，且将业务请求放到消息队列中，可以降低业务服务器的负载及提高消息安全性。

应清楚地理解，本发明描述了如何形成和使用特定示例，但本发明的原理不限于这些示例的任何细节。相反，基于本发明公开的内容的教导，这些原理能够应用于许多其它实施方式。

图3是根据一示例性实施方式示出的应用于本发明方法的系统的架构图。如图3所示，该业务架构可由两部分组成，即消息队列服务层和业务请求服务层。其中，如图1中的消息队列服务器12服务于消息队列服务层，业务请求服务器11服务于业务请求服务层。图3中的第一、三、五层为消息队列服务层，第二、四、六层为业务请求服务层。

图4是根据一示例性实施方式示出的另一种基于消息队列的业务请求重传方法的流程图。结合图1、图3和图4所示，方法20包括：

在步骤s202中，将接收到的业务请求放入到接收总消息队列中。

接收总消息队列位于消息队列服务器12中。以台账反查业务为例，对于支付完成后没有接收到支付成功响应消息的业务请求，可设置该业务请求的属性后，将该业务请求放入到接收总消息队列中。业务请求的属性例如包括：话费充值订单、流量充值订单等。该属性可以路由标识(routingkey)来表示。

在步骤s204中，根据业务请求的属性，将业务请求从接收总消息队列路由到相应的业务消息队列中。

例如，通过业务请求服务器11中的“mq监听路由”单元根据业务请求的路由标识，将业务请求放入到相应的消息队列中。例如，可以将属性为话费充值的业务请求放入到业务消息队列一中，将属性为流量充值的业务请求放入到业务消息队列二中等。

在步骤s206中，发送业务消息队列中的业务请求。

例如，如图3中第四层所示，业务请求服务器11中可以分别设置多个“mq业务处理”单元，以分别处理各业务消息队列中的业务请求。mq业务处理单元向业务处理服务器13发送其对应的业务消息队列中的业务请求。

在步骤s208中，当在一预设的时间阈值内未收到业务请求的响应消息或者检测到该业务请求发送失败时，判断是否可以从配置文件链中获得对应的重试队列，如果是，则进入步骤s210；否则，进入步骤s216。

在实际应用中，该时间阈值的长度可以根据实际需求来设定，本发明不以此为限。此外在实际应用中，例如可以通过启动定时器的方式实现对该时间阈值的监控。如在发送业务消息队列中的业务请求后，启动一定时器，其长度为该时间阈值，如定时器到期后仍然未收到该响应消息时，判断是否可以从配置文件链中获得对应的重试队列。

或者，由于异常原因检测到该业务请求的发送失败时，也同样执行判断是否可以从配置文件链中获得对应的重试队列的操作。

多个重试消息队列分别具有不同的消息过期时间，当其中的业务请求的时间到期时，准备重传该重试消息队列中的业务请求。

配置文件链用于规定业务请求在多个重试消息队列中的路由顺序。

在步骤s210中，根据预设的配置文件链，将业务请求放入多个重试消息队列中相应的重试消息队列中。

以重传三次，且重传间隔分别为10秒、20秒及30秒为例，"retry.timeout10s"、"retry.timeout20s"及"retry.timeout30s"分别用于表示消息过期时间为10秒、20秒及30秒的重试消息队列的路由标识，则配置文件例如可以配置为{"default":"retry.timeout10s"\,"retry.timeout10s":"retry.timeout20s"\,"retry.timeout20s":"retry.timeout30s"}。

当重传第一次时，根据配置文件链，可以将业务请求放入路由标识为"retry.timeout10s"的第一重试消息队列中。

当重传第二次时，根据配置文件链，可以将业务请求放入路由标识为"retry.timeout20s"的第二重试消息队列中。

当重传第三次时，根据配置文件链，可以将业务请求放入路由标识为"retry.timeout30s"的第三重试消息队列中。

死信队列(deadmessage)是消息队列中的一种，与普通消息队列的不同之处在于，死信队列中的消息具有消息过期时间(timetolive，ttl)，当其中的消息到达该到期时间时，消息队列会处理该时间到期的消息。在一些实施例中，上述重试消息队列为死信队列，利用死信队列的机制实现业务请求到期重传的功能。

在步骤s212中，当业务请求在重试消息队列中的消息过期时间到期时，将业务请求放入到重分发总消息队列中。

如图3中的第五层，消息队列服务器12还包括重分发总消息队列，用于承载在重试消息队列中消息过期时间到期的业务请求。

在步骤s214中，根据业务请求的属性，将业务请求从重分发总消息队列中重新路由到业务消息队列中，并再次进入步骤s206。

例如，如图3中第六层，由业务请求服务器11中的“mq业务重分发单元”根据业务请求的属性，将业务请求从重分发总消息队列中路由到业务消息队列中。同步骤s204，例如可以将属性为话费充值的业务请求放入到业务消息队列一中，将属性为流量充值的业务请求放入到业务消息队列二中等。

在步骤s216中，打印日志后，删除该业务请求。

图5是根据一示例示出的业务请求的路由示意图。其中，创建exchange和重试消息队列及重分发总消息队列实例如下：

exchange(my_exchange)

第一重试消息队列(my_retry_10s)

第二重试消息队列(my_retry_20s)

第三重试消息队列(my_retry_30s)

重分发总消息队列(my_handler)

图6是根据一示例示出的业务请求流向示意图。从图5及图6中可以看到，业务请求从接收总消息队列中，根据属性被路由到相应的业务消息队列中进行处理，如果处理失败，则根据配置文件链，路由到相应的重试消息队列中，如首次处理失败，放入第一重试消息队列中；第一次重试失败，放入第二重试消息队列中；第二次重试识别，放入第三重试消息队列中等。

根据本发明的基于消息队列的业务请求重传方法，在具体实现时，可以使用线程循环扫描的方式，从而可提升系统性能的可靠性及降低代码开发的复杂度。

本领域技术人员可以理解实现上述实施方式的全部或部分步骤被实现为由cpu执行的计算机程序。在该计算机程序被cpu执行时，执行本发明提供的上述方法所限定的上述功能。所述的程序可以存储于一种计算机可读存储介质中，该存储介质可以是只读存储器，磁盘或光盘等。

此外，需要注意的是，上述附图仅是根据本发明示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

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

图7是根据一示例性实施方式示出的一种基于消息队列的业务请求重传装置的框图。如图7所示，装置30包括：业务请求发送模块302及业务请求处理模块304。

其中，业务请求发送模块302用于发送业务消息队列中的业务请求。

业务请求处理模块304用于当在一预设的时间阈值内未收到业务请求的响应消息或者检测到所述业务请求发送失败时，根据预设的配置文件链，将业务请求放入多个重试消息队列中的第一重试消息队列中。其中，多个重试消息队列具有不同的消息过期时间；所述配置文件链用于确定所述业务请求在所述多个重试消息队列中的路由顺序。

在一些实施例中，装置30还包括：业务请求重分发模块306、业务请求路由模块308及业务请求重发模块310。其中，业务请求重分发模块306用于当业务请求在第一重试消息队列中的消息过期时间到期时，将业务请求放入到重分发总消息队列中。业务请求路由模块308用于根据业务请求的属性，将业务请求从重分发总消息队列中路由到业务消息队列中。业务请求重发模块310用于重发业务消息队列中的业务请求。

在一些实施例中，业务请求处理模块304还用于当在所述时间阈值内未收到业务请求的响应消息或者检测到所述业务请求重发失败时，根据预设的配置文件链，将业务请求放入多个重试消息队列中的第二重试消息队列中。其中，第二重试消息队列的消息过期时间长于第一重试消息队列的消息过期时间。

在一些实施例中，多个重试消息队列均为死信队列。

在一些实施例中，装置30还包括：业务请求接收模块312，用于将接收到的业务请求放入到接收总消息队列中。业务请求路由模块308还用于根据业务请求的属性，将业务请求从接收总消息队列中路由到业务消息队列中。

根据本发明实施方式的基于消息队列的业务请求重传方法，利用设置具有不同的消息过期时间的重试消息队列，可实现不同频率的重发请求，且将业务请求放到消息队列中，可以降低业务服务器的负载及提高消息安全性。

需要注意的是，上述附图中所示的框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图8是根据一示例性实施方式示出的一种电子设备的结构示意图。需要说明的是，图8示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图8所示，电子设备800包括中央处理单元(cpu)801，其可以根据存储在只读存储器(rom)802中的程序或者从存储部分808加载到随机访问存储器(ram)803中的程序而执行各种适当的动作和处理。在ram803中，还存储有系统800操作所需的各种程序和数据。cpu801、rom802以及ram803通过总线804彼此相连。输入/输出(i/o)接口805也连接至总线804。

以下部件连接至i/o接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至i/o接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行上述流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(cpu)801执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读存储介质，该计算机可读存储介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

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

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括发送单元、获取单元、确定单元和第一处理单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，发送单元还可以被描述为“向所连接的服务端发送图片获取请求的单元”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：

发送业务消息队列中的业务请求；以及

当在一预设的时间阈值内未收到所述业务请求的响应消息或者检测到所述业务请求发送失败时，根据预设的配置文件链，将所述业务请求放入多个重试消息队列中的第一重试消息队列中；

其中，所述多个重试消息队列具有不同的消息过期时间；所述配置文件链用于确定所述业务请求在所述多个重试消息队列中的路由顺序。

以上具体地示出和描述了本发明的示例性实施方式。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。