消息处理方法、装置、设备及计算机存储介质

技术领域

本申请涉及金融科技(Fintech)的客户消息通知管理技术，涉及但不限于一种消息处理方法、装置、电子设备及计算机存储介质。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技转变，但由于金融行业的安全性、实时性要求，也对技术提出了更高的要求。

目前，在消息发送场景中，需要预先配置消息的发送参数，例如，需要预先配置消息的发送优先级以及每秒事务数(Transaction Per Second，TPS)等信息，这样，可以基于预先配置的发送参数进行消息队列中的消息发送，然而，相关技术中，仅仅是基于预配置的固定的发送参数进行消息发送，导致消息发送的灵活性较差。

发明内容

本申请实施例提供一种消息处理方法、装置、电子设备及计算机存储介质，可以解决相关技术中消息发送时灵活性较差的问题。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种消息处理方法，所述方法包括：

获取待处理的消息队列；

在所述待处理的消息队列不满足预设的发送时效要求时，按照预设的队列拆分策略，对所述消息队列进行拆分，得到拆分后的每个消息队列，将拆分后的每个消息队列确定为所述待处理的消息队列；

在所述待处理的消息队列满足预设的发送时效要求时，发送所述待处理的消息队列中的消息。

在本申请的一些实施例中，所述方法还包括：

在所述待处理的消息队列的平均发送时长大于第一预设时长，或者，所述待处理的消息队列的整体发送时长大于第二预设时长，或者，所述待处理的消息队列中无需优先发送的消息的个数大于第一预设值时，确定所述待处理的消息队列不满足预设的发送时效要求；

在所述待处理的消息队列的平均发送时长小于或等于第一预设时长，且所述待处理的消息队列的整体发送时长小于或等于第二预设时长，且所述待处理的消息队列中无需优先发送的消息的个数小于或等于第一预设值时，确定所述待处理的消息队列满足预设的发送时效要求。

可以看出，本申请实施例中，可以基于待处理的消息队列的平均发送时长、整体发送时长、以及待处理的消息队列中无需优先发送的消息等因素，对消息队列进行拆分，从而，在拆分后的消息队列满足预设的发送时效要求时，可以认为待处理的消息队列的平均发送时长、整体发送时长、以及待处理的消息队列中无需优先发送的消息等因素满足预设的发送时效要求，进而，使得消息队列中消息的发送满足实际需求。

在本申请的一些实施例中，所述方法还包括：

在对所述消息队列进行拆分后，确定拆分后的每个消息队列的流控配置信息；

根据所述待处理的消息队列的流控配置信息，确定所述待处理的消息队列的平均发送时长；根据所述待处理的消息队列的平均发送时长，确定所述待处理的消息队列的整体发送时长。

可以看出，本申请实施例可以根据待处理的消息队列的流控配置信息，准确地确定待处理的消息队列的平均发送时长和整体发送时长，从而有利于准确地判断待处理的消息队列是否满足预设的发送时效要求，进而，有利于准确地按照发送时效要求实现消息发送。

在本申请的一些实施例中，所述确定拆分后的每个消息队列的流控配置信息，包括：

根据拆分后的每个消息队列的消息数、以及所述预设的发送时效要求，确定拆分后的每个消息队列的流控配置信息。

这样，基于拆分后的每个消息队列的流控配置信息，有利于使拆分后的每个消息队列满足发送时效要求，即有利于及时得出满足发送时效要求的待处理的消息队列，提升了待处理的消息队列的发送效率。

在本申请的一些实施例中，所述确定拆分后的每个消息队列的流控配置信息，包括：

根据拆分后的每个消息队列中消息的类型，确定拆分后的每个消息队列的流控配置信息。

这样，基于拆分后的每个消息队列的流控配置信息，有利于使拆分后的每个消息队列的发送符合消息类型的客观情况，有利于各类消息的分类加载和发送

在本申请的一些实施例中，所述按照预设的队列拆分策略，对所述消息队列进行拆分，得到拆分后的每个消息队列，包括：

在所述待处理的消息队列的平均发送时长大于第一预设时长或所述待处理的消息队列的整体发送时长大于第二预设时长时，在所述待处理的消息队列中，将优先级高于预先优先级的消息拆分，得到拆分后的每个消息队列；

在所述待处理的消息队列中无需优先发送的消息的个数大于第一预设值时，在所述待处理的消息队列中，将所述无需优先发送的消息拆分，得到拆分后的每个消息队列。

可以看出，本申请实施例可以将无需优先发送的消息进行针对性地处理，并且将优先级高于预先优先级的消息进行针对性的处理，因而，有利于按照客观的实际需求实施消息的发送。

在本申请的一些实施例中，在所述待处理的消息队列满足预设的发送时效要求时，发送所述待处理的消息队列中的消息，包括：

在所述待处理的消息队列满足预设的发送时效要求时，根据所述待处理的消息队列与旧队列集合的关系、以及所述待处理的消息队列与新队列集合的关系，确定所述待处理的消息队列的类型；所述旧队列集合表示每个应用实例当前处理的消息队列的集合，所述每个应用实例表示用于处理消息队列的服务，所述新队列集合表示拆分后的各个消息队列的集合；

根据所述待处理的消息队列的类型，发送所述待处理的消息队列中的消息。

可以看出，本申请实施例，可以根据待处理的消息队列与旧队列集合的关系、以及待处理的消息队列与新队列集合的关系，准确地判断待处理的消息队列的类型，进而，有利于根据待处理的消息队列的类型，准确地发送待处理的消息队列中的消息。

在本申请的一些实施例中，所述根据所述待处理的消息队列与旧队列集合的关系、以及所述待处理的消息队列与新队列集合的关系，确定所述待处理的消息队列的类型，包括：

在所述待处理的消息队列处于旧队列集合中，且所述待处理的消息队列未处于新队列集合中时，确定所述待处理的消息队列为需要停止发送的消息队列；

在所述待处理的消息队列处于旧队列集合中，且所述待处理的消息队列处于新队列集合中时，确定所述待处理的消息队列为需要更新流控配置信息的消息队列；

在所述待处理的消息队列未处于旧队列集合中，且所述待处理的消息队列处于新队列集合中时，确定所述待处理的消息队列为新增队列。

可以看出，本申请实施例可以根据待处理的消息队列与旧队列集合的关系、以及待处理的消息队列与新队列集合的关系，准确地判断待处理的消息队列是否为需要停止发送的消息队列、需要更新流控配置信息的消息队列或新增队列，进而，有利于根据待处理的消息队列的类型对消息队列进行后续针对性地处理。

在本申请的一些实施例中，所述根据所述待处理的消息队列的类型，发送所述待处理的消息队列中的消息，包括：

在所述待处理的消息队列为需要停止发送的消息队列时，在所述每个应用实例中，停止所述待处理的消息队列的处理过程；

在所述待处理的消息队列为需要更新流控配置信息的消息队列时，在所述每个应用实例中，更新所述待处理的消息队列的流控配置信息；

在所述待处理的消息队列为新增队列时，在所述每个应用实例中，启动对所述待处理的消息队列的处理过程。

可以看出，本申请实施例可以根据待处理的消息队列的类型对消息队列进行后续针对性地处理。

在本申请的一些实施例中，所述在所述每个应用实例中，更新所述待处理的消息队列的流控配置信息，包括：

在各个应用实例的状态同步时，在所述每个应用实例中，更新所述待处理的消息队列的流控配置信息；

所述在所述每个应用实例中，启动对所述待处理的消息队列的处理过程，包括：

在各个应用实例的状态同步时，所述在所述每个应用实例中，启动对所述待处理的消息队列的处理过程。

可以看出，本申请实施例可以在各个应用实例的状态同步时，更新流控配置信息或启动对待处理的消息队列的处理过程，从而使各个应用实例同步进行消息处理。

在本申请的一些实施例中，所述方法还包括：

在各个应用实例中，剔除状态异常的应用实例，所述状态异常的应用实例的心跳时间与当前时间的间隔大于预设时间间隔。

可以看出，本申请实施例通过剔除状态异常的应用实例，可以剔除长时间没有进行数据更新的应用实例，有利于节省资源并提高消息队列处理的准确性和可靠性。

在本申请的一些实施例中，所述方法还包括：

所述待处理的消息队列中的消息的标识与已发送的消息的标识一致时，停止发送所述待处理的消息队列中的消息。

可以看出，本申请实施例可以通过消息的标识的唯一性，实现防重复发送的兜底控制

在本申请的一些实施例中，所述方法还包括：

在距离上次发送消息的时间间隔超过第三预设时长时，利用预设的消息发送方式，发送所述待处理的消息队列中的消息。

可以看出，在距离上次发送消息的时间间隔超过第三预设时长时，可以认为应用实例长时间不进行消息处理，可能导致出现漏发消息的情况，在本申请实施例中，通过预设的消息发送方式，发送待处理的消息队列中的消息，有利于防止消息的漏发。

本申请实施例提供一种消息处理装置，所述装置包括：

获取模块，用于获取待处理的消息队列；

处理模块，用于在所述待处理的消息队列不满足预设的发送时效要求时，按照预设的队列拆分策略，对所述消息队列进行拆分，得到拆分后的每个消息队列，将拆分后的每个消息队列确定为所述待处理的消息队列；在所述待处理的消息队列满足预设的发送时效要求时，发送所述待处理的消息队列中的消息。

本申请实施例提供一种电子设备，所述电子设备包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现上述任意一种消息处理方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于被处理器执行时，实现上述任意一种消息处理方法。

本申请实施例中，获取待处理的消息队列；在所述待处理的消息队列不满足预设的发送时效要求时，按照预设的队列拆分策略，对所述消息队列进行拆分，得到拆分后的每个消息队列，将拆分后的每个消息队列确定为所述待处理的消息队列；在所述待处理的消息队列满足预设的发送时效要求时，发送所述待处理的消息队列中的消息。

可以看出，本申请实施例中，可以根据待处理的消息队列与预设的发送时效要求的关系，动态地对消息队列进行拆分，从而，本申请实施例无需依赖于预配置的固定的发送参数进行消息发送，而是可以消息发送过程中，灵活地改变消息的发送方式，即，消息发送时灵活性较高，并且，通过动态地对消息队列进行拆分，可以使消息的发送满足预设的发送时效要求，从而本申请实施例可以按照实际时效要求进行消息队列中消息的发送。

附图说明

图1为本申请实施例的消息处理方法的一个流程图；

图2为本申请实施例的消息处理方法的另一个流程图；

图3为本申请实施例的消息处理装置的一个可选的组成结构示意图；

图4为本申请实施例提供的电子设备的一个可选的组成结构示意图。

具体实施方式

以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本申请，并不用于限定本申请。另外，以下所提供的实施例是用于实施本申请的部分实施例，而非提供实施本申请的全部实施例，在不冲突的情况下，本申请实施例记载的技术方案可以任意组合的方式实施。

需要说明的是，在本申请实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的方法或者装置不仅包括所明确记载的要素，而且还包括没有明确列出的其他要素，或者是还包括为实施方法或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括该要素的方法或者装置中还存在另外的相关要素(例如方法中的步骤或者装置中的单元，例如的单元可以是部分电路、部分处理器、部分程序或软件等等)。

例如，本申请实施例提供的消息处理方法包含了一系列的步骤，但是本申请实施例提供的消息处理方法不限于所记载的步骤，同样地，本申请实施例提供的消息处理装置包括了一系列模块，但是本申请实施例提供的装置不限于包括所明确记载的模块，还可以包括为获取相关信息、或基于信息进行处理时所需要设置的模块。

在相关技术中，消息队列可以表示若干符合某一预设规则的待发送消息的集合，预设规则根据消息类型确定，在一些实施例中，可以按照消息优先级、产品、业务场景等对消息进行分类。这里，消息优先级表示加载发送消息的优先级顺序；产品表示消息对应的产品，例如，两个消息分别属于两种不同的贷款产品的消息时，这两个消息属于不同的产品的消息；业务场景表示一个产品下的不同消息场景，例如，对于贷款产品A，贷款产品A的还款提醒消息与借款成功提醒消息，属于不同的业务场景。

在相关技术中，对于消息队列，基于预先配置的发送参数进行消息队列中的消息发送，然而，这种消息发送方案存在以下问题：1)需要预先定义消息优先级、以及配置业务产品、业务场景到优先级的映射关系，消息的发送依赖于预先定义和配置的信息，当消息保存至待发送表后，其队列属性已根据预配置信息固定，无法再度动态更新，新拆分的队列无法应用至已保存但未发送的数据，灵活性较低；2)消息发送的流控配置信息如TPS等于预先配置的固定信息，即，消息发送时的TPS为固定的TPS，不能够使用动态预测模型来实时计算及分配流控配置信息。

针对上述技术问题，提出本申请实施例的技术方案。本申请实施例可以应用于终端和/服务器中，这里，终端可以是瘦客户机、厚客户机、手持或膝上设备、基于微处理器的系统、可编程消费电子产品、网络个人电脑、小型计算机系统，等等。服务器可以是小型计算机系统﹑大型计算机系统和包括上述任何系统的分布式云计算技术环境，等等。

服务器等电子设备可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机系统/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。

图1为本申请实施例的消息处理方法的一个流程图，如图1所示，该流程可以包括：

步骤101：获取待处理的消息队列。

本申请实施例中，待处理的消息队列表示需要加载发送的消息的集合，待处理的消息队列包括至少一个消息；待处理的消息队列的个数可以是一个，也可以是多个，本申请实施例对此并不进行限定。

在一些实施例中，可以获取消息发送请求，在消息发送请求中可以携带需要加载发送的消息，这样，通过对消息发送请求进行消息加工处理，可以确定出待处理的消息队列。

在一些实施例中，在获取待处理的消息队列后，可以确定消息队列中的消息所属的产品或业务场景，消息所属的产品或业务场景可以由消息发送请求中的指示信息确定，因而，通过对待处理的消息队列进行消息加工处理，可以确定消息队列中的消息所属的产品或业务场景。

示例性地，可以使用结构化查询语言(Structured Query Language，SQL)直接统计待发送表，待发送表用于记录每种产品或每种业务场景的待发送消息数，使用SQL直接统计待发送表的缺点在于：在待发送的消息的数据量较大时，SQL执行效率较低，依据预先确定的性能要求，此类SQL可能需要在备库执行，由于受到主备数据库同步时延、以及查询效率的限制，统计数据的及时性较差。

针对使用SQL统计带发送表的方案的问题，在一些实施例中，可以由缓存中的消息记数器记录每种产品或每种业务场景的待发送消息数，在这种情况下，即使在待发送的消息的数据量较大时，也可以用缓存记录待发送消息数，无需基于主备数据库记录数据，不受到主备数据库同步时延、以及查询效率的限制，因而，与上述使用SQL统计带发送表的方案相比，在一定程度上可以更加及时地获取统计数据。

步骤102：在待处理的消息队列不满足预设的发送时效要求时，按照预设的队列拆分策略，对消息队列进行拆分，得到拆分后的每个消息队列，将拆分后的每个消息队列确定为待处理的消息队列；在待处理的消息队列满足预设的发送时效要求时，发送所述待处理的消息队列中的消息。

本申请实施例中，发送时效要求用于表征使消息的发送时效满足实际需求的参数，例如，产品1的消息需要优先发送，业务场景2中的消息无需优先发送等。

队列拆分策略可以与发送时效要求相关，需要说明的是，在对待处理的消息队列按照预设的队列拆分策略进行第一次拆分后，拆分后的每个消息队列不一定满足预设的时效发送要求，在拆分后的任意一个消息队列不满足预设的时效发送要求时，可以再次拆分后的上述任意一个消息队列进行拆分，直至拆分后的每个消息队列满足预设的时效发送要求。

在本申请实施例中，在将拆分后的每个消息队列确定为待处理的消息队列，可以重复执行步骤102，直至待处理的消息队列满足预设的发送时效要求时，发送所述待处理的消息队列中的消息。

在一些实施例中，在待处理的消息队列不满足预设的发送时效要求时，也可以不对消息队列进行拆分，而是更改消息队列中消息的流控配置信息，然后，将更改流控配置信息的消息队列确定为待处理的消息队列。

在实际应用中，步骤101至步骤102可以基于电子设备的处理器实现，上述处理器可以是特定用途集成电路(Application Specific Integrated Circuit，A SIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(Digital SignalProcessing Device，DSPD)、可编程逻辑装置(Programmable Logic Device，PLD)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、CPU、控制器、微控制器、微处理器中的至少一种。可以理解地，实现上述处理器功能的电子器件还可以为其它，本申请实施例不作限制。

可以看出，本申请实施例可以根据待处理的消息队列与预设的发送时效要求的关系，动态地对消息队列进行拆分，从而，本申请实施例无需依赖于预配置的固定的发送参数进行消息发送，而是可以消息发送过程中，灵活地改变消息的发送方式，即，消息发送时灵活性较高，并且，通过动态地对消息队列进行拆分，可以使消息的发送满足预设的发送时效要求，从而本申请实施例可以按照实际时效要求进行消息队列中消息的发送。

在一些实施例中，预设的发送时效要求可以包括以下至少一项：待处理的消息队列的平均发送时长小于或等于第一预设时长、待处理的消息队列的整体发送时长小于或等于第二预设时长、待处理的消息队列中无需优先发送的消息的个数小于或等于第一预设值。

本申请实施例中，待处理的消息队列的平均发送时长表示预估的平均发送时长，而不是实际的平均发送时长；在一些实施例中，第一预设时长可以根据实际需求预先设置，例如，第一预设时长可以是业务参数中配置的最大可接受的发送时长，业务参数可以是预先配置的参数。示例性地，在待处理的消息队列的平均发送时长大于第一预设时长时，可以认为高优先级消息存在延误风险；在处理的消息队列的平均发送时长小于或等于第一预设时长时，可以认为高优先级消息不存在延误风险。

本申请实施例中，在得出待处理的消息队列的平均发送时长后，可以根据待处理的消息队列中消息的个数，确定出待处理的消息队列的整体发送时长，即将待处理的消息队列中消息的个数与平均发送时长相乘，得到待处理的消息队列的整体发送时长。显然，待处理的消息队列的整体发送时长也是预估值。在一些实施例中，第二预设时长可以根据实际需求预先设置，例如，第二预设时长可以是预设阈值的150％。示例性地，在待处理的消息队列的整体发送时长大于第二预设时长时，可以认为待处理的消息队列的整体发送时长不符合实际的时延要求；在待处理的消息队列的整体发送时长小于或等于第二预设时长时，可以认为待处理的消息队列的整体发送时长符合实际的时延要求。

本申请实施例中，无需优先发送的消息表示时长不敏感的消息，第一预设值可以实际场景需求进行经验性设置，也可以根据消息队列的历史发送时长进行设置；示例性地，在待处理的消息队列中无需优先发送的消息的个数大于第一预设值时，可以认为消息队列中无需优先发送的消息需要进行针对性地处理。

可以看出，本申请实施例中，可以基于待处理的消息队列的平均发送时长、整体发送时长、以及待处理的消息队列中无需优先发送的消息等因素，对消息队列进行拆分，从而，在拆分后的消息队列满足预设的发送时效要求时，可以认为待处理的消息队列的平均发送时长、整体发送时长、以及待处理的消息队列中无需优先发送的消息等因素满足预设的发送时效要求，进而，使得消息队列中消息的发送满足实际需求。

在一些实施例中，在对消息队列进行拆分后，还可以确定拆分后的每个消息队列的流控配置信息；然后根据待处理的消息队列的流控配置信息，确定待处理的消息队列的平均发送时长；根据待处理的消息队列的平均发送时长，确定待处理的消息队列的整体发送时长。

示例性地，如果待处理的消息队列是在待处理的消息队列的整体发送时长大于第二预设时长的情况下拆分的，则可以根据待处理的消息队列的流控配置信息，确定待处理的消息队列的平均发送时长；然后，根据待处理的消息队列的平均发送时长，更新待处理的消息队列的整体发送时长。

如果待处理的消息队列不是在待处理的消息队列的整体发送时长大于第二预设时长的情况下拆分的，则在对待处理的消息队列进行拆分后，可以根据待处理的消息队列的流控配置信息，确定待处理的消息队列的平均发送时长；然后，根据待处理的消息队列的平均发送时长，直接确定待处理的消息队列的整体发送时长。

示例性地，在对消息队列进行首次拆分前，待处理的消息队列的流控配置信息可以根据消息的类型确定，消息的类型可以是消息所属的产品类型和/或消息所属的业务场景类型。

对于根据待处理的消息队列的流控配置信息，确定待处理的消息队列的平均发送时长的实现方式，在一些实施例中，可以确定待处理的消息队列的消息个数与待处理的消息队列的TPS的比值，然后根据上述比值确定待处理的消息队列的平均发送时长。

下面结合一个应用场景进行示例性说明。在该应用场景中，待处理的消息队列记为队列Q，队列Q中包含类型A的消息、类型B的消息和类型C的消息，类型A、类型B和类型C是根据消息所属的产品或业务场景进行区分的；类型A的消息、类型B的消息和类型C的消息中的消息数分别为X

MaxCost＝SUM(X

其中，MaxCost表示待处理的消息队列中最晚发送的消息的预估发送时长，即，待处理的消息队列中消息发送时长的最大值；SUM(X

在得出待处理的消息队列中最晚发送的消息的预估发送时长后，可以计算得出待处理的消息队列的平均发送时长，待处理的消息队列的平均发送时长为MaxCost*1/2。

示例性地，在对消息队列进行拆分后，可以根据拆分后的每个消息队列的消息数、以及预设的发送时效要求，确定拆分后的每个消息队列的流控配置信息。这样，基于拆分后的每个消息队列的流控配置信息，有利于使拆分后的每个消息队列满足发送时效要求，即有利于及时得出满足发送时效要求的待处理的消息队列，提升了待处理的消息队列的发送效率。

在一种实现方式中，可以预设的发送时效要求，确定每种类型的消息能够接受的最大发送时长，然后，根据拆分后的每个消息队列的消息数、以及拆分后的每个消息队列的每个消息能够接受的最大发送时长，得出拆分后的每个消息队列的流控配置信息，例如，以拆分后的每个消息队列的每个消息的实际发送时长小于对应的能够接受的最大发送时长为目标，确定拆分后的每个消息队列的流控配置信息。

示例性地，在对消息队列进行拆分后，可以根据拆分后的每个消息队列中消息的类型，确定拆分后的每个消息队列的流控配置信息。这样，基于拆分后的每个消息队列的流控配置信息，有利于使拆分后的每个消息队列的发送符合消息类型的客观情况，有利于各类消息的分类加载和发送。

可以看出，本申请实施例可以根据待处理的消息队列的流控配置信息，准确地确定待处理的消息队列的平均发送时长和整体发送时长，从而有利于准确地判断待处理的消息队列是否满足预设的发送时效要求，进而，有利于准确地按照发送时效要求实现消息发送。

在一些实施例中，上述按照预设的队列拆分策略，对消息队列进行拆分，得到拆分后的每个消息队列，可以包括：在待处理的消息队列中无需优先发送的消息的个数大于第一预设值时，在待处理的消息队列中，将无需优先发送的消息拆分，得到拆分后的每个消息队列；在待处理的消息队列的平均发送时长大于第一预设时长或所述待处理的消息队列的整体发送时长大于第二预设时长时，在待处理的消息队列中，将优先级高于预先优先级的消息拆分，得到拆分后的每个消息队列。

本申请实施例中，如果待处理的消息队列中无需优先发送的消息的个数大于第一预设值，可以认为存在大批量时长不敏感消息，此时，需要将无需优先发送的消息从原消息队列中拆分出去，以得到由无需优先发送的消息组成的新消息队列。

示例性地，待处理的消息队列Q中类型D的消息为无需优先发送的消息，在类型D的消息的个数X

在一种实现方式中，在对处理的消息队列Q进行拆分后，新队列Q

SUM(X

其中，SUM(X

在确定新队列Q

通过上述计算过程，可确定待处理的新队列Q

本申请实施例中，如果待处理的消息队列的平均发送时长大于第一预设时长或待处理的消息队列的整体发送时长大于第二预设时长，可以认为高优先级消息存在延误风险，此时，需要将高优先级消息从原消息队列中拆分出去，以得到由高优先级消息组成的新消息队列。

示例性地，待处理的消息队列Q中业务场景A的消息和业务场景B的消息的优先级高于预设优先级，在待处理的消息队列Q的平均发送时长大于第一预设时长时，可以将业务场景A的消息和业务场景B的消息从待处理的消息队列Q中拆分出去，形成新队列Q

在一种实现方式中，新队列Q

SUM(Q

其中，SUM(Q

在确定新队列Q

通过上述计算过程，可确定拆分出去的新队列Q

本申请实施例中，在待处理的消息队列不满足预设的发送时效要求时，可以重复执行待处理的消息队列的拆分步骤，直至拆分后的每个消息队列满足预设的发送时效要求。

可以看出，本申请实施例可以将无需优先发送的消息进行针对性地处理，并且将优先级高于预先优先级的消息进行针对性的处理，因而，有利于按照客观的实际需求实施消息的发送。

在一些实施例中，在待处理的消息队列满足预设的发送时效要求时，发送待处理的消息队列中的消息的实现方式，可以包括：

在待处理的消息队列满足预设的发送时效要求时，根据待处理的消息队列与旧队列集合的关系、以及待处理的消息队列与新队列集合的关系，确定待处理的消息队列的类型；旧队列集合表示每个应用实例当前处理的消息队列的集合，每个应用实例表示用于处理消息队列的服务，新队列集合表示拆分后的各个消息队列的集合；

根据待处理的消息队列的类型，发送待处理的消息队列中的消息。

本申请实施例中，每个应用实例可以基于进程或线程实现；在一些实施例中，可以利用多个应用实例处理消息队列，以实现消息处理的高可用，在多个应用实例处于正常工作状态时，各个应用实例的状态以及处理的消息队列应是同步的，各个应用实例执行的消息处理流程是相同的。

在一些实施例中，可以判断每个应用实例处理的消息队列的哈希值与新队列集合中消息队列的哈希值是否一致，这里，可以将每个应用实例处理的每个消息队列以及该应用实例处理的每个消息队列的消息加载条件作为整体来计算哈希值，得到每个应用实例处理的消息队列的哈希值；可以将新队列集合中的每个消息队列以及新队列集合的每个消息队列的消息加载条件作为整体来计算哈希值，得到新队列集合中的消息队列的哈希值。

示例性地，消息加载条件可以包括以下至少一项：消息队列中的消息所属的产品列表bidList、消息队列中的消息所属的业务场景列表bizTypeList、消息队列中需要排除的产品列表exBidList、消息队列中需要排除的业务场景列表exBizTypeList；在消息加载条件包括列表exBidList时，消息列表需要排除列表exBidList中的产品的消息，在消息加载条件包括列表exBizTypeList时，消息列表需要排除列表exBizTypeListt中的业务场景的消息。

示例性地，消息队列的流控配置信息可以根据消息加载条件确定；这样，在每个应用实例处理的消息队列的哈希值与新队列集合中消息队列的哈希值不一致时，可以认为每个应用实例处理的消息队列与新队列集合中消息队列不一致，或，每个应用实例处理的消息队列与新队列集合中消息队列的流控配置信息不一致；此时，如果待处理的消息队列满足预设的发送时效要求，则可以进行各个应用实例的状态同步，各个应用实例的状态同步的一种实现方式可以是：根据待处理的消息队列与旧队列集合的关系、以及待处理的消息队列与新队列集合的关系，确定待处理的消息队列的类型；然后，在各个应用实例进行状态同步后，每个应用实例根据待处理的消息队列的类型进行消息处理。

在每个应用实例处理的消息队列的哈希值与新队列集合中消息队列的哈希值一致时，可以认为各个应用实例的状态已经实现同步。

可以看出，本申请实施例，可以根据待处理的消息队列与旧队列集合的关系、以及待处理的消息队列与新队列集合的关系，准确地判断待处理的消息队列的类型，进而，有利于根据待处理的消息队列的类型，准确地发送待处理的消息队列中的消息。

在一些实施例中，根据待处理的消息队列与旧队列集合的关系、以及待处理的消息队列与新队列集合的关系，确定待处理的消息队列的类型的实现方式，可以包括：

在待处理的消息队列处于旧队列集合中，且待处理的消息队列未处于新队列集合中时，确定待处理的消息队列为需要停止发送的消息队列；

在待处理的消息队列处于旧队列集合中，且待处理的消息队列处于新队列集合中时，确定待处理的消息队列为需要更新流控配置信息的消息队列；

在待处理的消息队列未处于旧队列集合中，且待处理的消息队列处于新队列集合中时，确定待处理的消息队列为新增队列。

可以看出，本申请实施例可以根据待处理的消息队列与旧队列集合的关系、以及待处理的消息队列与新队列集合的关系，准确地判断待处理的消息队列是否为需要停止发送的消息队列、需要更新流控配置信息的消息队列或新增队列，进而，有利于根据待处理的消息队列的类型对消息队列进行后续针对性地处理。

在一些实施例中，上述根据待处理的消息队列的类型，发送待处理的消息队列中的消息的实现方式，可以包括：

在待处理的消息队列为需要停止发送的消息队列时，在每个应用实例中，停止待处理的消息队列的处理过程。

在待处理的消息队列为需要更新流控配置信息的消息队列时，在每个应用实例中，更新待处理的消息队列的流控配置信息；

在待处理的消息队列为新增队列时，在每个应用实例中，启动对待处理的消息队列的处理过程。

本申请实施例中，在待处理的消息队列为需要停止发送的消息队列时，说明待处理的消息队列的消息处于新队列集合的消息队列中，此时，在每个应用实例中，可以停止加载待处理的消息队列；示例性地，在每个应用实例停止待处理的消息队列的处理过程后，可以利用临时线程将待处理的消息队列记为已加载的消息队列，然后可以关闭临时线程。

在一些实施例中，在待处理的消息队列为新增队列时，可以在每个应用实例中，新建待处理的消息队列的加载及发送线程，从而启动对待处理的消息队列的处理过程。

在一些实施例中，在待处理的消息队列为需要停止发送的消息队列时，可以将待处理的消息队列记为旧队列；在每个应用实例中，需要先停止旧队列的处理过程，然后，启动对新增队列的处理过程并针对需要更新流控配置信息的消息队列，更新流控配置信息；这里，并不对启动对新增队列的处理过程与更新流控配置信息的顺序进行限定。

本申请实施例中，应用实例涉及的数据切换原则为：先停止旧队列的数据加载，再更新新增队列的数据加载并更新流控配置信息。

可以看出，本申请实施例可以根据待处理的消息队列的类型对消息队列进行后续针对性地处理。

在一些实施例中，上述在每个应用实例中，更新所述待处理的消息队列的流控配置信息，可以包括：在各个应用实例的状态同步时，在每个应用实例中，更新待处理的消息队列的流控配置信息；

相应地，上述在每个应用实例中，启动对待处理的消息队列的处理过程，可以包括：在各个应用实例的状态同步时，在每个应用实例中，启动对待处理的消息队列的处理过程。

示例性地，可以设置实例状态表，用于记录每个应用实例的心跳时间、每个应用实例处理的消息队列的哈希值以及每个应用实例的队列信息，从而根据实例状态表记录的信息实现各个应用实例的同步。

示例性地，可以在每个应用实例启动时，更新每个应用实例的心跳时间、每个应用实例处理的消息队列的哈希值。

示例性地，在在各个应用实例的状态不同步时，在每个应用实例中，可以不更新待处理的消息队列的流控配置信息，不启动对待处理的消息队列的处理过程。

可以看出，本申请实施例可以在各个应用实例的状态同步时，更新流控配置信息或启动对待处理的消息队列的处理过程，从而使各个应用实例同步进行消息处理。

进一步地，本申请实施例通过增加实例状态表，记录应用实例的心跳时间、应用实例处理的消息队列的哈希值以及应用实例的队列信息，可以实现各个应用实例的状态同步；如果多个应用实例的状态不一致，则可能出现不同应用实例的不同消息队列的消息加载条件部分重合，导致部分数据重复加载，重复加载的数据会占用消息队列空间，造成资源浪费，影响消息处理效率；而在本申请实施例中，在确定各个应用实例的状态同步后再启动新增队列的处理过程以及更新流控配置信息，有利于使新队列集合和旧队列集合的数据切换在各个应用实例间保持一致，使得在整个消息处理流程中同一个消息不会被重复处理；反之，

在一些实施例中，可以在各个应用实例中，剔除状态异常的应用实例，所述状态异常的应用实例的心跳时间与当前时间的间隔大于预设时间间隔。

示例性地，预设时间间隔可以进行经验性设置；每个应用实例可以按照预设计划定时更新心跳时间，如果应用实例的心跳时间与当前时间的间隔大于预设时间间隔，则说明该应用实例的状态异常，此时，可以剔除该应用实例，利用其它的应用实例进行消息队列的处理。

可以看出，本申请实施例通过剔除状态异常的应用实例，可以剔除长时间没有进行数据更新的应用实例，有利于节省资源并提高消息队列处理的准确性和可靠性。

在一些实施例中，在待处理的消息队列中的消息的标识与已发送的消息的标识一致时，可以停止发送待处理的消息队列中的消息。

本申请实施例中，消息的标识可以消息的身份标识号(Identity Document，ID)，消息的标识具有唯一性，例如，消息的ID在消息创建时生成，在整体消息处理流程中具有唯一性。在一些实施例中，可以通过新增记录表，记录各消息的标识，从而利用消息的标识的唯一性实现防重复发送的兜底控制。

在实际应用场景中，可能出现以下极端情况：在心跳检查过程中，有个别应用实例性能低或其他异常卡顿导致更新心跳不及时，但实际该应用实例还在运行状态中，会现出该应用实例与其它应用实例重复加载部分数据的问题，在这种情况下可以依赖消息的标识进行防重复发送的兜底控制。

可以看出，本申请实施例可以通过消息的标识的唯一性，实现防重复发送的兜底控制；另外，如果不检查各个应用实例的状态是否同步，而是直接基于消息的标识唯一性进行消息发送的控制，可能出现数据重复加载后再触发防重拦截，会产生防重拦截告警。

在一些实施例中，可以在距离上次发送消息的时间间隔超过第三预设时长时，利用预设的消息发送方式，发送所述待处理的消息队列中的消息。

本申请实施例中，第三预设时长可以根据实际需求设置。下面对预设的消息发送方式进行示例性说明，在距离上次发送消息的时间间隔超过第三预设时长时，可以将待处理的消息队列中的消息重新按照默认的消息类型与优先级的映射关系，确定消息发送方式。

可以看出，在距离上次发送消息的时间间隔超过第三预设时长时，可以认为应用实例长时间不进行消息处理，可能导致出现漏发消息的情况，在本申请实施例中，通过预设的消息发送方式，发送待处理的消息队列中的消息，有利于防止消息的漏发。

下面结合附图对消息处理方法的流程进行示例性说明，图2为本申请实施例的消息处理方法的另一个流程图，如图2所示，该流程可以包括：

在接收消息请求后，可以进行消息加工，从而缓存中更新消息记数器；根据消息加工结果可以确定业务参数配置信息(例如可以包括流控配置信息、消息加载条件等信息)；然后可以结合消息记数器以及业务参数配置信息进行消息时延分析，这里的消息时延分析包括上述判断待处理的消息队列是否满足预设的发送时效要求的过程；基于消息时延分析的结果可以进行消息队列的拆分，在进行消息队列的拆分后，可以更新消息队列以及消息队列的配置信息(例如可以是流控配置信息)，这里的更新消息队列包括停止旧队列的处理和启动对新增队列的处理。

队列管理模块可以读取消息队列的配置信息和实例状态表，然后可以根据前述实施例记载的内容，在各个应用实例同步后，启动加载线程和发送线程；加载线程用于从缓存中读取缓存数据，缓存数据包括需要发送的消息，加载线程可以将消息按照消息队列进行加载；发送线程可以从消息队列中依次取出消息进行发送。

在前述实施例提出的消息处理方法的基础上，本申请实施例还提出了一种消息处理装置；图3为本申请实施例的消息处理装置的一个可选的组成结构示意图，如图3所示，该消息处理装置300可以包括：

获取模块301，用于获取待处理的消息队列；

处理模块302，用于在所述待处理的消息队列不满足预设的发送时效要求时，按照预设的队列拆分策略，对所述消息队列进行拆分，得到拆分后的每个消息队列，将拆分后的每个消息队列确定为所述待处理的消息队列；在所述待处理的消息队列满足预设的发送时效要求时，发送所述待处理的消息队列中的消息。

在一些实施例中，所述处理模块302，还用于：

在所述待处理的消息队列的平均发送时长大于第一预设时长，或者，所述待处理的消息队列的整体发送时长大于第二预设时长，或者，所述待处理的消息队列中无需优先发送的消息的个数大于第一预设值时，确定所述待处理的消息队列不满足预设的发送时效要求；

在所述待处理的消息队列的平均发送时长小于或等于第一预设时长，且所述待处理的消息队列的整体发送时长小于或等于第二预设时长，且所述待处理的消息队列中无需优先发送的消息的个数小于或等于第一预设值时，确定所述待处理的消息队列满足预设的发送时效要求。

在一些实施例中，所述处理模块302，还用于：

在对所述消息队列进行拆分后，确定拆分后的每个消息队列的流控配置信息；

根据所述待处理的消息队列的流控配置信息，确定所述待处理的消息队列的平均发送时长；根据所述待处理的消息队列的平均发送时长，确定所述待处理的消息队列的整体发送时长。

在一些实施例中，所述处理模块302，用于确定拆分后的每个消息队列的流控配置信息，包括：

根据拆分后的每个消息队列的消息数、以及所述预设的发送时效要求，确定拆分后的每个消息队列的流控配置信息。

在一些实施例中，所述处理模块302，用于确定拆分后的每个消息队列的流控配置信息，包括：

根据拆分后的每个消息队列中消息的类型，确定拆分后的每个消息队列的流控配置信息。

在一些实施例中，所述处理模块302，用于按照预设的队列拆分策略，对所述消息队列进行拆分，得到拆分后的每个消息队列，包括：

在所述待处理的消息队列的平均发送时长大于第一预设时长或所述待处理的消息队列的整体发送时长大于第二预设时长时，在所述待处理的消息队列中，将优先级高于预先优先级的消息拆分，得到拆分后的每个消息队列；

在所述待处理的消息队列中无需优先发送的消息的个数大于第一预设值时，在所述待处理的消息队列中，将所述无需优先发送的消息拆分，得到拆分后的每个消息队列。

在一些实施例中，所述处理模块302，用于在所述待处理的消息队列满足预设的发送时效要求时，发送所述待处理的消息队列中的消息，包括：

在所述待处理的消息队列满足预设的发送时效要求时，根据所述待处理的消息队列与旧队列集合的关系、以及所述待处理的消息队列与新队列集合的关系，确定所述待处理的消息队列的类型；所述旧队列集合表示每个应用实例当前处理的消息队列的集合，所述每个应用实例表示用于处理消息队列的服务，所述新队列集合表示拆分后的各个消息队列的集合；

根据所述待处理的消息队列的类型，发送所述待处理的消息队列中的消息。

在一些实施例中，所述处理模块302，用于根据所述待处理的消息队列与旧队列集合的关系、以及所述待处理的消息队列与新队列集合的关系，确定所述待处理的消息队列的类型，包括：

在所述待处理的消息队列处于旧队列集合中，且所述待处理的消息队列未处于新队列集合中时，确定所述待处理的消息队列为需要停止发送的消息队列；

在所述待处理的消息队列处于旧队列集合中，且所述待处理的消息队列处于新队列集合中时，确定所述待处理的消息队列为需要更新流控配置信息的消息队列；

在所述待处理的消息队列未处于旧队列集合中，且所述待处理的消息队列处于新队列集合中时，确定所述待处理的消息队列为新增队列。

在一些实施例中，所述处理模块302，用于根据所述待处理的消息队列的类型，发送所述待处理的消息队列中的消息，包括：

在所述待处理的消息队列为需要停止发送的消息队列时，在所述每个应用实例中，停止所述待处理的消息队列的处理过程；

在所述待处理的消息队列为需要更新流控配置信息的消息队列时，在所述每个应用实例中，更新所述待处理的消息队列的流控配置信息；

在所述待处理的消息队列为新增队列时，在所述每个应用实例中，启动对所述待处理的消息队列的处理过程。

在一些实施例中，所述处理模块302，用于在所述每个应用实例中，更新所述待处理的消息队列的流控配置信息，包括：

在各个应用实例的状态同步时，在所述每个应用实例中，更新所述待处理的消息队列的流控配置信息；

所述处理模块302，用于在所述每个应用实例中，启动对所述待处理的消息队列的处理过程，包括：

在各个应用实例的状态同步时，所述在所述每个应用实例中，启动对所述待处理的消息队列的处理过程。

在一些实施例中，所述处理模块302，还用于：

在各个应用实例中，剔除状态异常的应用实例，所述状态异常的应用实例的心跳时间与当前时间的间隔大于预设时间间隔。

在一些实施例中，所述处理模块302，还用于：

所述待处理的消息队列中的消息的标识与已发送的消息的标识一致时，停止发送所述待处理的消息队列中的消息。

在一些实施例中，所述处理模块302，还用于：

在距离上次发送消息的时间间隔超过第三预设时长时，利用预设的消息发送方式，发送所述待处理的消息队列中的消息。

在实际应用中，获取模块301和处理模块302均可以利用电子设备的处理器实现，上述处理器可以是ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。可以理解地，实现上述处理器功能的电子器件还可以为其它，本申请实施例不作限制。

需要说明的是，以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是终端、服务器等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例再提供一种计算机程序产品，所述计算机程序产品包括计算机可执行指令，该计算机可执行指令用于实现本申请实施例提供的任意一种消息处理方法。

相应的，本申请实施例再提供一种计算机存储介质，所述计算机存储介质上存储有计算机可执行指令，该计算机可执行指令用于实现上述实施例提供的任意一种消息处理方法。

本申请实施例还提供一种电子设备，图4为本申请实施例提供的电子设备的一个可选的组成结构示意图，如图4所示，所述电子设备40包括：

存储器401，用于存储可执行指令；

处理器402，用于执行所述存储器401中存储的可执行指令时，实现上述任意一种消息处理方法。

上述处理器402可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。

上述计算机可读存储介质/存储器可以是只读存储器(Read Only Memory，ROM)、可编程只读存储器(Programmable Read-Only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，EPROM)、电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性随机存取存储器(Ferromagnetic Random Access Memory，FRAM)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(Compact Disc Read-Only Memory，CD-ROM)等存储器；也可以是包括上述存储器之一或任意组合的各种终端，如移动电话、计算机、平板设备、个人数字助理等。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一些实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本申请实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得设备自动测试线执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。