CN116155849A - 一种消息投递方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明提供一种消息投递方法、装置、电子设备及存储介质，涉及通信技术领域，用于实现消息体的高可用投递。该方法包括：在通过消息投递器将消息队列中的消息体投递至业务***发生失败之后，判断消息体的投递次数是否达到最大投递次数；若消息体的投递次数未达到最大投递次数，将消息体添加到多个死信队列中与消息体的投递次数对应的目标死信队列，并将消息体从消息队列中删除；其中，多个死信队列中每个死信队列对应的延时时长与该死信队列对应的投递次数存在正相关关系；在消息体在目标死信队列中的存续时长达到目标死信队列对应的延时时长之后，将消息体从目标死信队列中删除，并将消息体重新添加至消息队列中。

Description

一种消息投递方法、装置、电子设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种消息投递方法、装置、电子设备及存储介质。

背景技术

在当今的互联网时代，各种类型的数据通信***，如即时通信(InstantMessaging，IM)***，扮演着一个极为重要的角色，而通讯能力无疑是***最为重要的功能。在通讯这个环节中，最为重要的无疑是消息的质量。在评估消息的质量时主要考虑两个方面，一个是消息投递的时间，另一个是消息投递的达到率。

现有技术中，通常采用消息队列模式服务的方法进行消息的投递。消息队列模式服务是分布式***中重要的组件模型，基于消息的异步处理模型采用非阻塞的调用特性，发送者将消息发送给消息队列服务器，消息队列服务器在合适的时候再将消息转发给接收者。发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同，而且发送者可以将消息间接传给多个接收者，解决应用解耦，实现了异步消息通信，流量削锋等问题。

但是，消息在投递的过程中，仍会因网络超时，服务宕机，brokers集群脑裂等客观原因导致消息在投递过程中出现投递失败、消息积压或消息丢失的情况。

发明内容

本发明提供一种消息投递方法、装置、电子设备及存储介质，用于实现消息体的高可用投递。

第一方面，提供一种消息投递方法，该方法包括：

在通过消息投递器将消息队列中的消息体投递至业务***发生失败之后，判断消息体的投递次数是否达到最大投递次数；

若消息体的投递次数未达到最大投递次数，将消息体添加到多个死信队列中与消息体的投递次数对应的目标死信队列，并将消息体从消息队列中删除；其中，多个死信队列中每个死信队列对应的延时时长与该死信队列对应的投递次数存在正相关关系；

在消息体在目标死信队列中的存续时长达到目标死信队列对应的延时时长之后，将消息体从目标死信队列中删除，并将消息体重新添加至消息队列中。

本发明提供的技术方案至少带来以下有益效果：在消息体投递至业务***发生失败之后，在消息体的投递次数未达到最大投递次数时，将消息体添加到多个死信队列中与消息体的投递次数对应的目标死信队列，再次进行投递。这样，一方面在消息投递失败时，可重试投递，提高了消息的投递成功率；另一方面，根据消息投递失败的次数，将消息加入不同的死信队列中，等待再次投递，避免了大量的消息体在等待投递的过程中产生挤压，保障了消息体投递过程的有序性，实现了消息体的高可用投递。

在一种可能的实现方式中，通过消息投递器将消息队列中的消息体投递至业务***发生失败，包括：在通过消息投递器将消息队列中的消息体投递至业务***之后的预设时长内，未接收到业务***的确认消息。

基于该可能的实现方式，在预设时长内未接收到业务***的确认消息，消息投递器则确定将消息队列中的消息体投递至业务***发生失败，就可以进行消息体的再次投递，提高消息体的投递效率。

另一种可能的实现方式中，若消息体的投递次数达到最大投递次数，将消息体存储至数据库中，并通过消息投递监控平台监控业务***是否恢复正常。

基于该可能的实现方式，若消息体的投递次数达到最大投递次数还未投递成功，则说明业务***可能出现拥堵或者故障。这时再次进行投递是只会浪费资源。因此可以先将消息体存储至数据库中，并通过消息投递监控平台监控业务***，在其恢复正常时，再进行消息体的投递。这样既节省了资源，又保障了消息体的高可用投递。

另一种可能的实现方式中，通过消息投递监控平台接收到消息发送端发送的消息体；运行令牌桶算法以获取令牌，在获取到令牌之后，将消息体从消息投递监控平台投递至消息接收器。

基于该可能的实现方式，令牌桶算法是为了避免投递的消息体过多，超过了***运行的极限，使得消息在***中产生积压，进而造成投递失败的情况。运行令牌桶算法以使得获取令牌的消息体才可以进入投递阶段，控制了***中消息体的流量，保障了***的高可用性。

另一种可能的实现方式中，判断包含消息队列以及多个死信队列的容器是否处于正常状态；若容器处于正常状态，将消息体从消息接收器投递至容器；若消息体从消息接收器投递至容器发生失败，重新将消息体从消息接收器投递至容器，直至将消息体投递至容器的失败次数达到预设失败次数；在失败次数达到预设失败次数之后，将消息体保存至数据库。

基于该可能的实现方式，在将消息体从消息接收器投递至容器过程中，为了避免因容器中消息体过多或者容器出现故障，导致消息体不能成功投递，在此阶段也对消息体进行多次投递。在消息体多次未能成功投递至容器时，则将其保存至数据库中，在给容器恢复时间的同时，也避免了消息体的丢失，保障了消息的高可用投递。

第二方面，提供一种消息投递装置，该装置包括：

判断模块，用于在通过消息投递器将消息队列中的消息体投递至业务***发生失败之后，判断消息体的投递次数是否达到最大投递次数；

调度模块，用于若消息体的投递次数未达到最大投递次数，将消息体添加到多个死信队列中与消息体的投递次数对应的目标死信队列，并将消息体从消息队列中删除；其中，多个死信队列中每个死信队列对应的延时时长与该死信队列对应的投递次数存在正相关关系；

调度模块，还用于在消息体在目标死信队列中的存续时长达到目标死信队列对应的延时时长之后，将消息体从目标死信队列中删除，并将消息体重新添加至消息队列中。

另一种可能的实现方式中，通过消息投递器将消息队列中的消息体投递至业务***发生失败，包括：在通过消息投递器将消息队列中的消息体投递至业务***之后的预设时长内，未接收到业务***的确认消息。

另一种可能的实现方式中，存储模块，用于若消息体的投递次数达到最大投递次数，将消息体存储至数据库中，并通过消息投递监控平台监控业务***是否恢复正常。

另一种可能的实现方式中，接收模块，用于通过消息投递监控平台接收到消息发送端发送的消息体；投递模块，用于运行令牌桶算法以获取令牌，在获取到令牌之后，将消息体从消息投递监控平台投递至消息接收器。

另一种可能的实现方式中，判断模块，还用于判断包含消息队列以及所述多个死信队列的容器是否处于正常状态；投递模块，还用于若容器处于正常状态，将消息体从所述消息接收器投递至容器；投递模块，还用于若消息体从消息接收器投递至容器发生失败，重新将消息体从消息接收器投递至所述容器，直至将消息体投递至容器的失败次数达到预设失败次数；存储模块，还用于在失败次数达到预设失败次数之后，将消息体保存至数据库。

第三方面，提供了一种电子设备，该电子设备包括：处理器和用于存储处理器可执行指令的存储器；其中，处理器被配置为执行如第一方面及其任一种可能的实现方式的消息投递方法。

第四方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行如第一方面及其任一种可能实现方式的消息投递方法。

本发明中第二方面到第四方面及其各种实现方式的具体描述，可以参考第一方面及其各种实现方式中的详细描述。第二方面到第四方面及其各种实现方式的有益效果，可以参考第一方面及其各种实现方式的有益效果分析，此处不再赘述。

附图说明

图1为本发明实施例提供的一种消息投递***的架构示意图；

图2为本发明实施例提供的一种消息投递方法的流程图一；

图3为本发明实施例提供的一种消息投递方法的流程图二；

图4为本发明实施例提供的一种消息投递方法的流程图三；

图5为本发明实施例提供的一种消息投递方法的完整流程示意图；

图6为本发明实施例提供的一种消息投递装置的结构示意图；

图7为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

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

需要说明的是，本发明中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本发明中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

消息队列已经逐渐成为企业互联网技术(Internet Technology，IT)***内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步远程过程调用(Remote Procedure Call Protocol，RPC)的主要手段之一。

当今市面上有很多主流的消息中间件，如ActiveMQ、RabbitMQ和RocketMQ等。RocketMQ是一种基于分布式队列模型producers->brokers->consumers的开源消息中间件，RocketMQ的消息投递过程分为两种：一种是消息发送端producers往MQ broker中投递消息体；另外一种则是MQ broker往消息消费端consumers业务***投递消息体。消息体为根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输。

现有技术为了保证消息体的可靠投递通常采用的是消息确认投递的方式，没有对投递过程中，事务消息持续投递、消息堆积，失败消息重试等高可用投递方案做阐述。因此，消息在投递的过程中，经常会因各方***故障或网络异常等原因，导致消息堆积和消息无法及时投递的情况发生。

鉴于此，本发明基于分布式队列模型producers->brokers->consumers做了二次设计和方法实现，在消息入队列、出队列、消息积压和投递控制环节做了高可用设计和方法实现，并对消息在各个环节流转和存储做了幂等处理。避免了因网络超时、服务宕机、brokers集群脑裂等客观原因导致消息体在投递过程中出现投递失败、消息积压或消息丢失的问题。在保障消息体在有序传递和持续输出同时，实现消息体在投递过程中达到高性能，高可用，高可靠，可伸缩和最终一致性。

本发明实施例提供的技术方案可以应用于各种消息投递***。

示例性的，图1为本发明实施例提供了一种消息投递***的架构示意图，应用于消息发送端的业务***和消息消费端的目标业务***之间。如图1所示，该消息投递***包括Committer集群、MQ brokers集群和Deliverer集群。

其中，Committer集群为消息接收器，异常消息存储器，功能为向队列MQ brokers集群提交消息。

MQ brokers集群为消息队列，负责消息的存储和分发，向Deliverer集群派发消息。MQ brokers中搭建多Master多Slave镜像，在主机宕机时，可以通过从节点从主节点里面的同步过来的消息体数据，将这些消息体实时地消费掉，保障了消息投递***的的高可用性。

Deliverer集群为消息投递器，可控制投递并发数，投递失败，消息重新入MQbrokers集群中的延时队列，等消息时延(Time To Live，TTL)到期后，路由到正常消息队列做重试投递操作。Deliverer的面积大小代表并发投递器能力的大小。这样一来，根据目标业务***的接收能力，定制投递能力相适应的Deliverer，可以保护目标业务***不因投递量过而出现宕机。

可以理解的是，该***具有限流服务用于防止访问量过大所导致服务器宕机，以及投递监控用于监控消息体在投递过程中的实际投递情况。

如图2所示，本发明实施例提供一种消息投递方法，应用于图1所示的消息投递***，该方法包括以下步骤：

S101、在通过消息投递器将消息队列中的消息体投递至业务***发生失败之后，判断消息体的投递次数是否达到最大投递次数。

在一些实施例中，通过消息投递器将消息队列中的消息体投递至业务***发生失败，包括：在通过消息投递器将消息队列中的消息体投递至业务***之后的预设时长内，未接收到业务***的确认消息。该确认消息用于指示业务***成功接收到消息投递器投递的消息。这样，在预设时间没有接收到确认消息就可以确定消息体投递至业务***发生失败。

在一些实施例中，在通过消息投递器将消息队列中的消息体投递至业务***后，业务***在预设时间内向消息投递器发送响应消息，该响应消息用于指示业务***是否成功接收到消息体；在消息投递器接收到用于指示业务***接收消息体的失败的响应消息时，消息投递器对该消息体的投递次数进行计算。这样，在消息投递器接收到指示业务***接收消息体的失败的响应消息时，会立刻对该消息体的投递次数进行计算，便于消息投递器根据投递次数进行下一步的操作。

在一些实施例中，若消息体的投递次数达到最大投递次数，将消息体存储至数据库中，并通过消息投递监控平台监控业务***是否恢复正常。在业务***恢复正常后，将消息体进行重新投递。这样，避免了因业务***故障导致消息体在投递中丢失。

S102、若消息体的投递次数未达到最大投递次数，将消息体添加到多个死信队列中与消息体的投递次数对应的目标死信队列，并将消息体从消息队列中删除。

其中，死信队列用来保存处理失败或者过期的消息体的队列。每个消息队列绑定了多级阶梯死信队列。

在一些实施例中，多个死信队列中每个死信队列对应的延时时长与该死信队列对应的投递次数存在正相关关系。

在一些实施例中，消息体添加到多个死信队列中与消息体的投递次数对应的目标死信队列具体实现为：假设消息体在第n次投递时，投递失败，n小于最大投递次数；将该消息体加入延时时长为n*a毫秒的目标死信队列，a为预设参数。这样的话，重试投递的次数越多，则消息体加入的死信队列所对应的延时时长会越长，避免所有的消息体加入同一个死信队列，造成消息体积压，保障了消息体的高可用投递。

S103、在消息体在目标死信队列中的存续时长达到目标死信队列对应的延时时长之后，将消息体从目标死信队列中删除，并将消息体重新添加至消息队列中。

基于此，在消息投递失败时，根据消息投递失败的次数，将消息加入不同的死信队列中，等待再次投递，实现了消息投递可重试，也避免了大量的消息体在等待投递的过程中产生挤压，保障了消息体投递过程的有序性，实现了消息体的高可用投递。

图3为本发明实施例提供的一种消息投递方法的流程图。如图3所示，该消息投递方法包括以下步骤：

S201、通过消息投递监控平台接收到消息发送端发送的消息体。

在一些实施例中，消息发送端以预设周期向消息投递监控平台发送消息体。示例性的，消息发送端从上一次发送结束时间开始存储消息体，直至达到一个预设周期时长后向消息投递监控平台发送消息体。

在另一些实施例中，消息发送端以存储阈值向消息投递监控平台发送消息体。示例性的，消息发送端在上一次发送结束时开始存储消息体，直至达到消息发送端的存储阈值后向消息投递监控平台发送消息体。

这样，可以避免消息发送端一直运行向消息投递监控平台发送消息体的操作，节约资源。

S202、运行令牌桶算法以获取令牌，在获取到令牌之后，将消息体从消息投递监控平台投递至消息接收器。

令牌桶算法是网络流量整形(Traffic Shaping)和速率限制(Rate Limiting)中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。

一种可能的实现方式，令牌桶以恒定的速率产生令牌，直至令牌桶达到存储限制；将消息体投递至消息接收器时，投递一个消息体需要消耗一个令牌，直至将令牌桶的所有令牌消耗完毕，停止投递；一次性投递的消息体数目与令牌桶中的令牌数目一致。可以理解的是，在令牌桶未达到存储限制时，消息体不会被投递至消息接收器。在令牌桶达到存储限制时，令牌桶不会继续产生令牌，此时进行将消息体从消息投递监控平台投递至消息接收器的操作。

基于此，通过消息投递监控平台接收到消息发送端发送的消息体，并运用令牌桶算法，将消息体从消息投递监控平台投递至消息接收器。防止消息接收器拥塞，限制流出消息体的流量，使消息体以比较均匀的速度向消息接收器发送。这样，避免投递服务因访问量过大而宕机。

图4为本发明实施例提供的一种消息投递方法的流程图。如图4所示，该消息投递方法包括以下步骤：

S301、判断包含消息队列以及多个死信队列的容器是否处于正常状态。

在一些实施例中，判断包含消息队列以及多个死信队列的容器是否处于正常状态，可以通过记录包含消息队列以及多个死信队列的容器中的消息体数目；在包含消息队列以及多个死信队列的容器中的消息体数目超过预设阈值时，则判定该容器不在正常状态；在包含消息队列以及多个死信队列的容器中的消息体数目未超过预设阈值时，则判定该容器在正常状态。

在另一些实施例中，判断包含消息队列以及多个死信队列的容器是否处于正常状态，可以通过容器是否能继续接收消息体进行判断；在容器不能继续接收到消息体的情况下可以发出警告，确定包含消息队列以及多个死信队列的容器不是处于正常状态。

这样一来，判断容器的当前状态可以便于消息接收器进行下一步的消息体投递操作，避免因容器出现网络波动，脑裂，流控等异常问题，导致消息投递失败，提高消息投递的成功率。

S302、若容器处于正常状态，将消息体从消息接收器投递至容器。

在一些实施例中，消息接收器以预设周期向消息投递监控平台容器投递消息体。示例性的，消息接收器从上一次投递操作结束时间开始存储消息体，直至达到一个预设周期时长后向容器投递消息体。

在另一些实施例中，消息接收器以存储阈值向容器平台投递消息体。示例性的，消息接收器在上一次投递操作结束时开始存储消息体，直至达到消息接收器的存储阈值后向容器投递消息体。

这样，可以避免消息接收器一直运行重复向容器投递消息体的操作，节约资源。

S303、若消息体从消息接收器投递至容器发生失败，重新将消息体从消息接收器投递至容器，直至将消息体投递至容器的失败次数达到预设失败次数。

在一些实施例中，将消息体从消息接收器投递至容器；在容器接收消息体成功的情形下，容器向消息接收器发送用于指示消息体接收成功的响应消息；在容器接收消息体失败的情形下，容器向消息接收器发送用于指示消息体接收失败的响应消息。

在一些实施例中，在消息接收器接收到容器发送的用于指示消息体接收失败的响应消息时，将消息体投递至容器的失败次数进行计算，并判断该消息体是否达到预设的失败次数。这样一来，消息接收器可以根据接收到的响应消息，及时进行下一步的消息体投递操作，提高消息体的投递效率，保障消息体的高可用投递。

这样的话，将消息体进行多次重试投递至容器，可以避免因意外导致消息体的偶然性投递失败，提高消息体的投递成功率。

S304、在失败次数达到预设失败次数之后，将消息体保存至数据库。

在一些实施例中，在消息接收器判断该消息体达到预设的失败次数时，将该消息体保存至数据库中。这样一来，可以避免在将消息体投递至容器失败后，消息体出现丢失，保障了消息体的高可用投递。

基于此，在将消息体从消息接收器投递至容器时，进行投递失败可重试的操作，提高了消息体投递的成功率，使得投递***具有容错性，保障了消息体的高可用投递。

示例性的，图5为本发明实施例提供了一种消息投递方法的完整流程示意图。具体包括以下步骤：

通过消息投递监控平台接收到消息发送端批量导入的消息体；

运行令牌桶算法以获取令牌，在获取到令牌之后，将消息体从消息投递监控平台投递至消息接收器Committer；

判断包含消息队列queue以及多个死信队列dead-letter-queue的容器Broker是否处于正常状态；

若容器处于正常状态，将消息体从消息接收器中的递交单元submit投递至容器；通过消息接收器中的认证单元Confirm验证容器返回的响应消息，并判断消息体是否成功投递至容器；若消息体从消息接收器投递至容器发生失败，重新将消息体通过消息接收器中的提交单元submit投递至容器，直至将消息体投递至容器的失败次数达到预设失败次数；在失败次数达到预设失败次数之后，例如，继续参考图5，在retry＝3时，将消息体通过消息接收器中的返回单元Return保存至数据库；

通过消息投递器Deliverer中的信息接收单元MessageListener接收来自于消息队列中的消息体；通过消息投递器Deliverer中的信息认证单元MessageConfirm将消息体投递至业务***，并判断是否投递成功；在通过消息投递器将消息队列中的消息体投递至业务***发生失败之后，通过消息投递器中的MessageConfirm判断消息体的投递次数notify是否达到最大投递次数n；在通过消息投递器将消息队列中的消息体投递至业务***成功之后，通过消息投递器中的MessageConfirm将消息体从消息队列中删除；

若消息体的投递次数未达到最大投递次数，则通过消息投递器中的返回死信队列单元ReturnDeadLetterQueue将消息体添加到多个死信队列中与消息体的投递次数对应的目标死信队列，并将消息体从消息队列中删除；其中，多个死信队列中每个死信队列对应的延时时长TTL与该死信队列对应的投递次数存在正相关关系；示例性的，继续参考图5，在消息体投递次数为1且投递失败时，将消息体添加到TTL为10ms的死信队列，并将消息体从消息队列中删除；在消息体投递次数为n且投递失败时，将消息体添加到TTL为n*10ms的死信队列，并将消息体从消息队列中删除；

在消息体在目标死信队列中的存续时长达到目标死信队列对应的延时时长之后，将消息体从目标死信队列中删除，并将消息体重新添加至消息队列中；

若消息体的投递次数达到最大投递次数，将消息体存储至数据库中，并通过消息投递监控平台监控业务***是否恢复正常；在业务***正常时，将消息体投递至消息接收器，进行再次投递操作。

可以理解的是，上述方法可以由消息投递装置实现。消息投递装置为了实现上述功能，其包含了执行各个功能相应的硬件结构或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本发明实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的范围。

本发明实施例可以根据上述方法示例对上述消息投递装置等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图6示出了上述实施例中所涉及消息投递装置的一种可能的结构示意图。如图6所示，消息投递装置60包括：判断模块61、调度模块62、存储模块63、接收模块64和投递模块65。

在一些实施例中，判断模块61，用于在通过消息投递器将消息队列中的消息体投递至业务***发生失败之后，判断消息体的投递次数是否达到最大投递次数；

调度模块62，用于若消息体的投递次数未达到最大投递次数，将消息体添加到多个死信队列中与消息体的投递次数对应的目标死信队列，并将消息体从消息队列中删除；其中，多个死信队列中每个死信队列对应的延时时长与该死信队列对应的投递次数存在正相关关系；

调度模块62，还用于在消息体在目标死信队列中的存续时长达到目标死信队列对应的延时时长之后，将消息体从目标死信队列中删除，并将消息体重新添加至消息队列中。

在一些实施例中，通过消息投递器将消息队列中的消息体投递至业务***发生失败，包括：在通过消息投递器将消息队列中的消息体投递至业务***之后的预设时长内，未接收到业务***的确认消息。

在一些实施例中，存储模块63，用于若消息体的投递次数达到最大投递次数，将消息体存储至数据库中，并通过消息投递监控平台监控业务***是否恢复正常。

在一些实施例中，接收模块64，用于通过消息投递监控平台接收到消息发送端发送的消息体；

投递模块65，用于运行令牌桶算法以获取令牌，在获取到令牌之后，将消息体从消息投递监控平台投递至消息接收器。

在一些实施例中，判断模块61，还用于判断包含消息队列以及多个死信队列的容器是否处于正常状态；

投递模块65，还用于若容器处于正常状态，将消息体从消息接收器投递至容器；

投递模块65，还用于若消息体从消息接收器投递至容器发生失败，重新将消息体从消息接收器投递至容器，直至将消息体投递至容器的失败次数达到预设失败次数；

存储模块63，还用于在失败次数达到预设失败次数之后，将消息体保存至数据库。

当然，消息投递装置60包括但不限于上述所列举的模块。并且，上述功能模块的具体所能够实现的功能也包括但不限于上述实例的方法步骤对应的功能，消息投递装置60的其他模块的详细描述可以参考其所对应方法步骤的详细描述，本发明实施例这里不再赘述。

在采用集成的单元的情况下，图7示出了上述实施例中所涉及的电子设备的一种可能的结构示意图。电子设备700可以包括处理器701和存储器702。存储器702用于存储处理器701可执行指令的存储器。处理器701被配置为执行该指令，使得电子设备执行上述方法实施例中的各个功能或者步骤。

具体地，处理器701用于对电子设备的动作进行控制管理。存储器702，用于保存电子设备的程序代码和数据，如消息投递方法，预设权重、预设取值范围等。

其中，处理器701可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器701可以包括附属处理器(Attached Processor，AP)、调制解调处理器、图形处理器(Graphic Processing Unit，GPU)、图像信号处理器(Image Signal Processor，ISP)、控制器、存储器、视频编解码器、数字信号处理器(Digital Signal Processing，DSP)、基带处理器、和/或神经网络处理器(Neural Network Processing Unit，NPU)等。

存储器702可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器702还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器702中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器701所执行以实现本发明实施例提供的消息投递方法。

本申请的一些实施例提供了一种计算机可读存储介质(例如，非暂态计算机可读存储介质)，该计算机可读存储介质中存储有计算机程序指令，计算机程序指令在计算机上运行时，使得计算机执行如上述实施例中任一实施例所述的消息投递方法。

示例性的，上述计算机可读存储介质可以包括，但不限于：磁存储器件(例如，硬盘、软盘或磁带等)，光盘(例如，压缩盘(Compact Disk，CD)、数字通用盘(DigitalVersatile Disk，DVD)等)，智能卡和闪存器件(例如，可擦写可编程只读存储器(ErasableProgrammable Read-Only Memory，EPROM)、卡、棒或钥匙驱动器等)。本申请描述的各种计算机可读存储介质可代表用于存储信息的一个或多个设备和/或其它机器可读存储介质。术语“机器可读存储介质”可包括但不限于，无线信道和能够存储、包含和/或承载指令和/或数据的各种其它介质。

本申请实施例提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得该计算机执行上述实施例中任一实施例所述的消息投递方法。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (12)

1.一种消息投递方法，其特征在于，所述方法包括：

在通过消息投递器将消息队列中的消息体投递至业务***发生失败之后，判断所述消息体的投递次数是否达到最大投递次数；

若所述消息体的投递次数未达到所述最大投递次数，将所述消息体添加到多个死信队列中与所述消息体的投递次数对应的目标死信队列，并将所述消息体从所述消息队列中删除；其中，所述多个死信队列中每个死信队列对应的延时时长与该死信队列对应的投递次数存在正相关关系；

在所述消息体在所述目标死信队列中的存续时长达到所述目标死信队列对应的延时时长之后，将所述消息体从所述目标死信队列中删除，并将所述消息体重新添加至所述消息队列中。

2.根据权利要求1所述的方法，其特征在于，所述通过消息投递器将消息队列中的消息体投递至业务***发生失败，包括：

在通过所述消息投递器将所述消息队列中的所述消息体投递至所述业务***之后的预设时长内，未接收到所述业务***的确认消息。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述消息体的投递次数达到所述最大投递次数，将所述消息体存储至数据库中，并通过消息投递监控平台监控所述业务***是否恢复正常。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

通过所述消息投递监控平台接收到消息发送端发送的所述消息体；

运行令牌桶算法以获取令牌，在获取到令牌之后，将所述消息体从所述消息投递监控平台投递至消息接收器。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

判断包含所述消息队列以及所述多个死信队列的容器是否处于正常状态；

若所述容器处于正常状态，将所述消息体从所述消息接收器投递至所述容器；

若所述消息体从所述消息接收器投递至所述容器发生失败，重新将所述消息体从所述消息接收器投递至所述容器，直至将所述消息体投递至所述容器的失败次数达到预设失败次数；

在所述失败次数达到所述预设失败次数之后，将所述消息体保存至所述数据库。

6.一种消息投递装置，其特征在于，所述装置包括：

判断模块，用于在通过消息投递器将消息队列中的消息体投递至业务***发生失败之后，判断所述消息体的投递次数是否达到最大投递次数；

调度模块，用于若所述消息体的投递次数未达到所述最大投递次数，将所述消息体添加到多个死信队列中与所述消息体的投递次数对应的目标死信队列，并将所述消息体从所述消息队列中删除；其中，所述多个死信队列中每个死信队列对应的延时时长与该死信队列对应的投递次数存在正相关关系；

所述调度模块，还用于在所述消息体在所述目标死信队列中的存续时长达到所述目标死信队列对应的延时时长之后，将所述消息体从所述目标死信队列中删除，并将所述消息体重新添加至所述消息队列中。

7.根据权利要求6所述的装置，其特征在于，所述通过消息投递器将消息队列中的消息体投递至业务***发生失败，包括：

在通过所述消息投递器将所述消息队列中的所述消息体投递至所述业务***之后的预设时长内，未接收到所述业务***的确认消息。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

存储模块，用于若所述消息体的投递次数达到所述最大投递次数，将所述消息体存储至数据库中，并通过消息投递监控平台监控所述业务***是否恢复正常。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

接收模块，用于通过所述消息投递监控平台接收到消息发送端发送的所述消息体；

投递模块，还用于运行令牌桶算法以获取令牌，在获取到令牌之后，将所述消息体从所述消息投递监控平台投递至消息接收器。

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

所述判断模块，还用于判断包含所述消息队列以及所述多个死信队列的容器是否处于正常状态；

所述投递模块，还用于若所述容器处于正常状态，将所述消息体从所述消息接收器投递至所述容器；

所述投递模块，还用于若所述消息体从所述消息接收器投递至所述容器发生失败，重新将所述消息体从所述消息接收器投递至所述容器，直至将所述消息体投递至所述容器的失败次数达到预设失败次数；

所述存储模块，还用于在所述失败次数达到所述预设失败次数之后，将所述消息体保存至所述数据库。

11.一种电子设备，其特征在于，所述电子设备包括：处理器和用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，使得所述电子设备执行如权利要求1-5中任一项所述的消息投递方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-5中任一项所述的消息投递方法。

Images