CN115550280B - 多级消息队列实现方法、系统、电子设备和可读存储介质 - Google Patents

Abstract

本发明提供一种多级消息队列实现方法、系统、电子设备和可读存储介质，该多级消息队列实现方法包括：配置多个消息队列，并分别配置所述多个消息队列的优先级，并保存所述多个消息队列的配置信息；在接收到系统启动的指令之后，读取所述配置信息，定时对各个消息队列的健康状态进行探测，根据所述健康状态对消息队列的可用状态进行调整；在接收到发送消息数据的指令之后，按照所述从高到低的优先级顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列；若所述消息数据发送失败，返回上一步骤，直至所述消息数据发送成功。本发明消除了消息队列内部单点隐患，实现消息队列故障发现和恢复后的自动化处理，故障响应速度增快。

Description

多级消息队列实现方法、系统、电子设备和可读存储介质

技术领域

本发明实施例涉及通信技术领域，尤其涉及一种多级消息队列实现方法、系统、电子设备和可读存储介质。

背景技术

现如今的系统中，为了实现服务间的解耦或流量高峰的削峰处理，引入越来越多的消息队列，随之而来的是系统复杂性的增加和稳定性的降低，故障发生概率也逐步增加。

目前，针对引入的消息队列的故障应急处置，一般是通过运维监控或客户服务保障观测到消息队列发生问题时，由运维人员手动创建新的消息队列服务，业务系统将使用的消息队列切换至新的消息队列服务上。

但是，目前系统大多引入单个消息队列，消息队列内部存在单点隐患，在故障发生后若不能及时切换，会影响用户体验；并且由运维人员在观测到故障后手动切换新的消息队列的应急处置方式，故障的发现和故障恢复后的处理存在滞后性，也会影响用户体验。

发明内容

本发明实施例提供一种多级消息队列实现方法、系统、电子设备和可读存储介质，用于解决消息队列内部存在单点隐患，消息队列故障的发现和故障恢复后的处理存在滞后性，影响用户体验的问题。

为了解决上述技术问题，本发明是这样实现的：

第一方面，本发明实施例提供了一种多级消息队列实现方法，包括：

配置多个消息队列，并分别配置所述多个消息队列的优先级，并保存所述多个消息队列的配置信息；

在接收到系统启动的指令之后，读取所述配置信息，定时对各个消息队列的健康状态进行探测，根据所述健康状态对消息队列的可用状态进行调整；

在接收到发送消息数据的指令之后，按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列；

若所述消息数据发送失败，返回按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列的步骤，直至所述消息数据发送成功。

可选的，所述接收到发送消息数据的指令之后还包括：

将要发送的消息数据保存在消息记录表中，记录消息数据的执行信息；

所述执行信息至少包括以下之一：

发送流水和消息数据状态；

所述消息数据状态为未发送或已发送。

可选的，所述多个消息队列为：

三个消息队列，第一个消息队列为Kafka消息队列，第二个消息队列为Redis消息队列，第三个消息队列为本地内存消息队列。

可选的，保存所述多个消息队列的配置信息包括：

将所述多个消息队列的配置信息保存在以下之一中：动态配置中心Apollo、ZooKeeper、数据库或Redis缓存。

可选的，所述消息发送给第一个可用的消息队列还包括：

若消息发送成功，在所述消息记录表中将消息数据状态修改为已发送。

可选的，所述根据健康状态对消息队列的可用状态进行调整包括：

对所述消息队列进行健康探测，若所述消息队列的探测错误次数超过规定次数，将所述消息队列的可用状态设置为不可用；

若消息队列探测正确，且消息队列的可用状态为不可用，且所述消息队列的探测正确次数超过规定次数，将所述消息队列的可用状态设置为可用，恢复所述消息队列原本的优先级。

可选的，所述消息队列的可用状态设置为不可用之后还包括：

对已在所述消息队列中的消息数据启动数据补偿方案；

所述数据补偿方案包括：

读取所述消息记录表中的流水；

按照所述消息记录表中的流水和数据状态，从前到后，定时从消息记录表中抽取规定数目的已发送但未处理数据；

将所述已发送但未处理数据按照当前多个消息队列的优先级重新发送至下一级可用的消息队列。

第二方面，本发明实施例提供了一种多级消息队列实现系统，包括：

预处理模块，用于配置多个消息队列，并分别配置所述多个消息队列的优先级，并保存所述多个消息队列的配置信息；

第一处理模块，用于在接收到系统启动的指令之后，读取所述配置信息，定时对各个消息队列的健康状态进行探测，根据所述健康状态对消息队列的可用状态进行调整；

第二处理模块，用于在接收到发送消息数据的指令之后，按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列；

第三处理模块，用于若所述消息数据发送失败，返回按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列的步骤，直至所述消息数据发送成功。

第三方面，本发明实施例提供了一种电子设备，包括：处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序，所述程序被所述处理器执行时实现如上述第一方面所述的多级消息队列实现方法的步骤。

第四方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的多级消息队列实现方法的步骤。

在本发明实施例中，配置多个消息队列及其优先级，从而消除了消息队列内部单点隐患；根据健康状态探测的结果对消息队列的可用状态进行调整，将消息数据发送给优先级最高的可用的消息队列，若发送失败，重新选择可用消息队列发送直到成功，实现故障发现和恢复后的自动化处理，故障响应速度增快。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例的多级消息队列实现方法的流程示意图；

图2为本发明实施例的执行多级消息队列的工作过程示意图；

图3为本发明实施例的执行数据补偿方案的工作过程示意图；

图4为本发明实施例的多级消息队列实现系统的结构示意图；

图5为本发明实施例的电子设备的结构示意图。

具体实施方式

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

请参考图1和图2，本发明实施例提供一种多级消息队列实现方法，包括：

步骤11：配置多个消息队列，并分别配置所述多个消息队列的优先级，并保存所述多个消息队列的配置信息；

步骤12：在接收到系统启动的指令之后，读取所述配置信息，定时对各个消息队列的健康状态进行探测，根据所述健康状态对消息队列的可用状态进行调整；

所述定时的功能可以由定时器实现，时间可以设置为每秒。

步骤13：在接收到发送消息数据的指令之后，按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列；

步骤14：若所述消息数据发送失败，返回按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列的步骤，直至所述消息数据发送成功。

所述步骤13、步骤14可以由多级消息队列调度引擎执行，在接收到系统启动的指令之后启动所述多级消息队列调度引擎，将所述读取的所述配置信息初始化在所述多级消息队列调度引擎中，在接收到发送消息数据的指令之后，由所述多级消息队列调度引擎按照优先级从高到底依次进行队列组件的可用状态判断，进行消息数据发送，若发送失败，从所述多级消息队列调度引擎中重新按照优先级获取一个可用的消息队列组件进行消息数据发送。

在本发明实施例中，配置多个消息队列及其优先级，从而消除了消息队列内部单点隐患；根据健康状态探测的结果对消息队列的可用状态进行调整，将消息数据发送给优先级最高的可用的消息队列，若发送失败，重新选择可用消息队列发送直到成功，实现故障发现和恢复后的自动化处理，故障响应速度增快。

图2中的健康状态探测在接收到系统启动的指令之后启动，在系统启动到系统关闭的全过程中执行，所述健康状态的探测是指通过指定的方法或命令定时对对各个消息队列的健康状态进行探测，根据健康探测的结果将所述接收消息数据的消息队列可用状态调整为可用或不可用。

本发明实施例中，可选的，所述接收到发送消息数据的指令之后还包括：

将要发送的消息数据保存在消息记录表中，记录消息数据的执行信息；

所述执行信息至少包括以下之一：

发送流水和消息数据状态；

所述消息数据状态为未发送或已发送。

所述消息记录表可以防止消息数据丢失，在消息队列出现故障不可用之后，可以通过所述多级消息队列调度引擎将消息记录表保存的消息数据直接发送至新的可用消息队列，不需要消息发送端重复发送，所述消息记录表可以为Mysql数据表或Redis缓存文件。

可选的，所述多个消息队列为：

三个消息队列，第一个消息队列为Kafka消息队列，第二个消息队列为Redis消息队列，第三个消息队列为本地内存消息队列。

所述本地内存消息队列可以设置为优先级最低的消息队列，所述本地内存消息队列的处理信息能力依赖单机处理能力，与第三方消息队列相比信息处理能力较差，但从事故应急角度出发，增加所述本地内存消息队列可摆脱对外部第三方消息队列的依赖，增加本发明实施例异步数据的处理能力。

若所述多个消息队列多于三个，本发明实施例的性能会大幅下降，复杂度会指数级增加。

所述多个消息队列包括以下至少一项：

ActiveMQ消息队列，ZeroMQ消息队列，RocketMQ消息队列，RabbitMQ消息队列，Mysql消息队列，ElasticSearch消息队列。

所述多个消息队列的优先级顺序无需强制指定，可随时根据实际情况灵活调整。

可选的，保存所述多个消息队列的配置信息包括：

将所述多个消息队列的配置信息保存在以下之一中：动态配置中心Apollo、ZooKeeper、数据库或Redis缓存。

可选的，所述消息发送给第一个可用的消息队列还包括：

若消息发送成功，在所述消息记录表中将消息数据状态修改为已发送。

本发明实施例中，可选的，所述根据健康状态对消息队列的可用状态进行调整包括：

对所述消息队列进行健康探测，若所述消息队列的探测错误次数超过规定次数，将所述消息队列的可用状态设置为不可用；

若消息队列探测正确，且消息队列的可用状态为不可用，且所述消息队列的探测正确次数超过规定次数，将所述消息队列的可用状态设置为可用，恢复所述消息队列原本的优先级。

所述消息队列的可用状态设置为不可用之后，消息队列不会接受新的消息数据，不会发送数据至业务系统。

不同的消息队列的健康探测方法和工具不同，举例来说：

Kafka消息队列：使用Golang Kafka客户端中的HeartBeatLoop方法对所述Kafka消息队列进行健康探测，若探测错误超过规定次数，则将所述Kafka消息队列可用状态置为不可用；若探测正确且所述Kafka消息队列为不可用状态，将所述Kafka消息队列的可用状态设置为可用，恢复所述Kafka消息队列其原本的优先级；

Redis消息队列：使用Ping命令探测所述Redis消息队列的可用性，如果所述Redis消息队列状态为可用且连续超过规定次数Ping命令执行失败时，则将所述Redis消息队列的可用状态置为不可用；如果所述Redis消息队列状态不可用且连续超过规定次数Ping命令正确，则将所述Redis消息队列的可用状态设置为可用，所述Redis消息队列的优先级恢复为其原本的优先级。

所述消息队列的探测错误或正确规定次数根据不同业务场景进行配置。

本发明实施例中，可选的，请参考图3，所述消息队列的可用状态设置为不可用之后还包括：

对已在所述消息队列中的消息数据启动数据补偿方案；

所述数据补偿方案包括：

读取所述消息记录表中的流水；

按照所述消息记录表中的流水和数据状态，从前到后，定时从消息记录表中抽取规定数目的已发送但未处理数据；

将所述已发送但未处理数据按照当前多个消息队列的优先级重新发送至下一级可用的消息队列。

举例来说，若优先级为第一的消息队列A发生故障，所述消息队列A的可用状态设置为不可用，此时若所述消息队列A存在已经成功发送至消息队列且尚未成功被业务系统处理的数据，读取所述消息记录表中的流水，定时根据消息记录表的流水将所述数据进行重新发送至下一级可用的消息队列，即定时发送至优先级为第二的可用消息队列B。

所述定时从消息记录表中抽取规定数目的已发送但未处理数据可以为，每10秒钟从消息记录表中抽取所有未处理完成的前200条数据重新发送至优先级为第二的消息队列B。

同样的，若优先级为第一的消息队列A发生故障后，优先级为第二的消息队列B也发生故障，此时若所述消息队列A和所述消息队列B中均存在已经成功发送至消息队列且尚未被成功业务系统处理的数据，读取所述消息记录表中的流水，仍按照消息记录表中的流水将所述数据进行重新发送至下一级可用的消息队列，即定时发送至优先级为第三的消息队列C。

请参考图4，本发明还提供一种多级消息队列实现系统40，包括：

预处理模块41，用于配置多个消息队列，并分别配置所述多个消息队列的优先级，并保存所述多个消息队列的配置信息；

第一处理模块42，用于在接收到系统启动的指令之后，读取所述配置信息，定时对各个消息队列的健康状态进行探测，根据所述健康状态对消息队列的可用状态进行调整；

第二处理模块43，用于在接收到发送消息数据的指令之后，按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列；

第三处理模块44，用于若所述消息数据发送失败，返回按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列的步骤，直至所述消息数据发送成功。

可选的，多级消息队列实现系统40还包括：

第四处理模块，用于将要发送的消息数据保存在消息记录表中，记录消息数据的执行信息；

所述执行信息至少包括以下之一：

发送流水和消息数据状态；

所述消息数据状态为未发送或已发送。

可选的，所述多个消息队列为：

三个消息队列，第一个消息队列为Kafka消息队列，第二个消息队列为Redis消息队列，第三个消息队列为本地内存消息队列。

可选的，保存所述多个消息队列的配置信息包括：

将所述多个消息队列的配置信息保存在以下之一中：动态配置中心Apollo、ZooKeeper、数据库或Redis缓存。

可选的，多级消息队列实现系统40还包括：

第五处理模块，用于若消息发送成功，在所述消息记录表中将消息数据状态修改为已发送。

可选的，多级消息队列实现系统40还包括：

健康探测模块，用于对所述消息队列进行健康探测，若所述消息队列的探测错误次数超过规定次数，将所述消息队列的可用状态设置为不可用；

若消息队列探测正确，且消息队列的可用状态为不可用，且所述消息队列的探测正确次数超过规定次数，将所述消息队列的可用状态设置为可用，恢复所述消息队列原本的优先级。

可选的，多级消息队列实现系统40还包括：

补偿模块，用于对已在所述消息队列中的消息数据启动数据补偿方案；

所述数据补偿方案包括：

读取所述消息记录表中的流水；

按照所述消息记录表中的流水和数据状态，从前到后，定时从消息记录表中抽取规定数目的已发送但未处理数据；

将所述已发送但未处理数据按照当前多个消息队列的优先级重新发送至下一级可用的消息队列。

请参考图5，本发明实施例还提供一种电子设备50，包括处理器51，存储器52，存储在存储器52上并可在所述处理器51上运行的计算机程序，该计算机程序被处理器51执行时实现上述多级消息队列实现方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现上述多级消息队列实现方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random AccessMemory，RAM）、磁碟或者光盘等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端（可以是手机，计算机，服务器，空调器，或者网络设备等）执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。

Claims (8)

1.一种多级消息队列实现方法，其特征在于，包括：

配置多个消息队列，并分别配置所述多个消息队列的优先级，并保存所述多个消息队列的配置信息；

在接收到系统启动的指令之后，读取所述配置信息，定时对各个消息队列的健康状态进行探测，根据所述健康状态对消息队列的可用状态进行调整；

在接收到发送消息数据的指令之后，按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列；

若所述消息数据发送失败，返回按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列的步骤，直至所述消息数据发送成功；

将要发送的消息数据保存在消息记录表中，记录消息数据的执行信息；

所述执行信息至少包括以下之一：发送流水和消息数据状态；

所述消息数据状态为未发送或已发送；

其中，所述根据所述健康状态对消息队列的可用状态进行调整包括：

对所述消息队列进行健康探测，若所述消息队列的探测错误次数超过规定次数，将所述消息队列的可用状态设置为不可用；

若消息队列探测正确，且消息队列的可用状态为不可用，且所述消息队列的探测正确次数超过规定次数，将所述消息队列的可用状态设置为可用，恢复所述消息队列原本的优先级。

2.根据权利要求1所述的方法，其特征在于，所述多个消息队列为：

三个消息队列，第一个消息队列为Kafka消息队列，第二个消息队列为Redis消息队列，第三个消息队列为本地内存消息队列。

3.根据权利要求1所述的方法，其特征在于，所述保存所述多个消息队列的配置信息包括：

将所述多个消息队列的配置信息保存在以下之一中：动态配置中心Apollo、ZooKeeper、数据库或Redis缓存。

4.根据权利要求1所述的方法，其特征在于，所述消息数据发送给第一个可用的消息队列还包括：

若消息发送成功，在所述消息记录表中将消息数据状态修改为已发送。

5.根据权利要求1所述的方法，其特征在于，所述消息队列的可用状态设置为不可用之后还包括：

对已在所述消息队列中的消息数据启动数据补偿方案；

所述数据补偿方案包括：

读取所述消息记录表中的流水；

按照所述消息记录表中的流水和数据状态，从前到后，定时从消息记录表中抽取规定数目的已发送但未处理数据；

将所述已发送但未处理数据按照当前多个消息队列的优先级重新发送至下一级可用的消息队列。

6.一种多级消息队列实现系统，其特征在于，包括：

预处理模块，用于配置多个消息队列，并分别配置所述多个消息队列的优先级，并保存所述多个消息队列的配置信息；

第一处理模块，用于在接收到系统启动的指令之后，读取所述配置信息，定时对各个消息队列的健康状态进行探测，根据所述健康状态对消息队列的可用状态进行调整；第二处理模块，用于在接收到发送消息数据的指令之后，按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列；

第三处理模块，用于若所述消息数据发送失败，返回按照所述多个消息队列的优先级从高到低的顺序依次进行消息队列的可用状态判断，将消息数据发送给第一个可用的消息队列的步骤，直至所述消息数据发送成功；

第四处理模块，用于将要发送的消息数据保存在消息记录表中，记录消息数据的执行信息；

所述执行信息至少包括以下之一：发送流水和消息数据状态；

所述消息数据状态为未发送或已发送；

其中，所述第一处理模块包括：

健康探测模块，用于对所述消息队列进行健康探测，若所述消息队列的探测错误次数超过规定次数，将所述消息队列的可用状态设置为不可用；

若消息队列探测正确，且消息队列的可用状态为不可用，且所述消息队列的探测正确次数超过规定次数，将所述消息队列的可用状态设置为可用，恢复所述消息队列原本的优先级。

7.一种电子设备，其特征在于，包括：处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序，所述程序被所述处理器执行时实现如权利要求1至5中任一项所述的多级消息队列实现方法的步骤。

8.一种计算机可读存储介质，其特征在于，计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5中任一项所述的多级消息队列实现方法的步骤。

Images