一种消息队列的消息推送方法和装置、服务器、存储介质与流程

本公开实施例涉及业务处理领域，尤其涉及一种消息队列的消息推送方法和装置、服务器、存储介质。

背景技术：

消息队列常用于系统之间解耦、流量削峰等场景。对于消息队列中间件，一个重要的概念是主题topic，topic是消息队列用于实现不同业务间隔离的重要手段。通常，不同的子业务会单独申请各自的topic，在各自的topic当中处理本业务相关的消息。在实际场景中，为了避免topic数量过多，不便维护，会存在一个大类业务下多个子业务复用同一个topic的需要。这种情况下，往往通过为不同的子业务设置不同的tag标签来进行区分。但是，在这种使用情况中，如果不同子业务的消息数量存在较大差异，则会使得数量较少的子业务的消费机会受到较大影响。

技术实现要素：

本公开关于一种消息队列的消息推送方法和装置、服务器、存储介质，能够降低复用同一消息队列的不同子业务消息中部分数量较少的子业务消息的处理时延。

为达到上述目的，本公开实施例采用如下技术方案：

第一方面，本公开提供一种消息队列的消息推送方法，包括：确定待处理消息队列中每个子队列的权重；子队列用于存储对应待处理消息队列的业务消息中的一种子业务消息；根据待处理消息队列中子队列的权重，从待处理消息队列中的子队列中获取子业务消息，并向对应的业务处理设备发送。

可选的，确定待处理消息队列中每个子队列的权重，包括：确定每个子队列的权重均为默认权重；或者，根据子队列的特征参数，确定子队列的权重；特征参数至少包括子队列中存储的子业务信息的时延需求。

可选的，根据待处理消息队列中子队列的权重，从待处理消息队列中的子队列中获取子业务消息，包括：根据待处理消息队列中子队列的权重，按照预设加权轮询算法，从待处理消息队列中的子队列中获取子业务消息。

可选的，根据待处理消息队列中子队列的权重，从待处理消息队列中的子队列中获取子业务消息，包括：从每个子队列中，获取与子队列的权重对应数量的子业务消息。

可选的，根据待处理消息队列中子队列的权重，从待处理消息队列中的子队列中获取子业务消息，包括：根据待处理消息队列中子队列的权重，从待处理消息队列中除无效子队列以外的子队列中获取子业务消息；无效子队列中不存在子业务消息。

可选的，还包括：接收对应待处理消息队列的子业务消息，并确定子业务消息对应的子业务标签；将子业务消息存储在待处理消息队列中对应子业务标签的子队列中。

可选的，将子业务消息存储在待处理消息队列中对应子业务标签的子队列中，包括：在待处理消息队列中不存在对应子业务标签的子队列的情况下，在待处理消息队列中创建对应子业务标签的子队列，并在其中存储子业务消息；在待处理消息队列中存在对应子业务标签的子队列的情况下，在待处理消息队列中对应子业务标签的子队列中存储子业务消息。

第二方面，本公开提供一种消息队列的消息推送装置，该装置包括确定模块和处理模块。其中，确定模块，被配置为确定对应待处理消息队列中每个子队列的权重；子队列用于存储对应待处理消息队列的业务消息中的一种子业务消息；处理模块，被配置为根据确定模块确定的待处理消息队列中子队列的权重，从待处理消息队列中的子队列中获取子业务消息，并向对应的业务处理设备发送。

可选的，确定模块具体被配置为：确定每个子队列的权重均为默认权重；或者，根据子队列的特征参数，确定子队列的权重；特征参数至少包括子队列中存储的子业务信息的时延需求。

可选的，处理模块具体被配置为：根据确定模块确定的待处理消息队列中子队列的权重，按照预设加权轮询算法，从待处理消息队列中的子队列中获取子业务消息。

可选的，处理模块具体被配置为：从每个子队列中，获取与确定模块确定的子队列的权重对应数量的子业务消息。

可选的，处理模块具体被配置为：根据确定模块确定的待处理消息队列中子队列的权重，从待处理消息队列中除无效子队列以外的子队列中获取子业务消息；无效子队列中不存在子业务消息。

可选的，还包括获取模块和存储模块；获取模块，被配置为接收对应待处理消息队列的子业务消息，并确定子业务消息对应的子业务标签；存储模块，被配置为将获取模块接收的子业务消息存储在待处理消息队列中对应子业务标签的子队列中。

可选的，存储模块具体被配置为：在待处理消息队列中不存在对应子业务标签的子队列的情况下，在待处理消息队列中创建对应子业务标签的子队列，并在其中存储子业务消息；在待处理消息队列中存在对应子业务标签的子队列的情况下，在待处理消息队列中对应子业务标签的子队列中存储子业务消息。

第三方面，本公开提供一种服务器，该服务器包括处理器和用于存储处理器可执行指令的存储器；其中，处理器被配置为执行指令，以实现如第一方面提供及其任一种可能的实施方式的消息队列的消息推送方法。

第四方面，本公开提供一种计算机可读存储介质，该计算机可读存储介质上存储有指令，当计算机可读存储介质中的指令由服务器的处理器执行时，使得服务器执行如第一方面提供及其任一种可能的实施方式的消息队列的消息推送方法。

第五方面，本公开实施例还提供一种计算机程序产品，包括一条或多条指令，该一条或多条指令可以在服务器上运行，使得服务器执行如第一方面及其任一种可能的实施方式的消息队列的消息推送方法。

可以理解的，本公开提供的技术方案中，消息队列的消息推送装置会提前在所有的消息队列中设置对应不同子业务的子队列，然后在需要对某个消息队列(即待处理消息队列)进行消息推送时，首先确定需要进行消息推送的待处理消息队列中每个子队列的权重，然后根据每个子队列的权重，从各个子队列中获取子业务消息并向对应的业务服务器发送处理。因为在该技术方案中，不同子业务消息是存储在不同子队列的，而每个子队列都有对应的权重，消息队列的消息推送装置在向业务处理设备发送业务消息时会根据权重从子队列中获取相应的子业务信息，这种情况下，即便某个子队列中消息很少，其内部的子业务消息也具备足够的机会被发送至业务处理设备，降低复用同一消息队列的不同的子业务消息中部分数量较少的一类子业务消息的处理时延，提高了各类子业务消息对应用户的使用体验。避免了现有技术中所有同一主题的子业务消息存储在同一消息队列中时，如果某类子业务消息较少且被排在一些数量较多的子业务消息之后时，会导致该类子消息很长时间不能被处理，影响该类子业务消息对应的用户的使用体验的缺陷。

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

附图说明

图1为本公开实施例提供的一种实施环境示意图；

图2为现有技术提供的一种消息队列的逻辑结构示意图；

图3为本公开实施例提供的一种消息队列的消息推送方法的流程示意图一；

图4为本公开实施例提供一种消息队列的逻辑结构示意图；

图5为本公开实施例提供的一种消息队列的消息推送方法的流程示意图二；

图6为本公开实施例提供的一种消息队列的消息推送方法的流程示意图三；

图7为本公开实施例提供的一种消息队列的消息推送方法的流程示意图四；

图8为本公开实施例提供的一种消息队列的消息推送方法的流程示意图五；

图9为本公开实施例提供的一种消息队列的消息推送方法的流程示意图六；

图10为本公开实施例提供的一种消息队列的消息推送方法的补充流程示意图；

图11为本公开实施例提供的另一种消息队列的消息推送方法的补充流程示意图；

图12为本公开实施例提供的一种消息队列的消息推送装置的结构示意图；

图13为本公开实施例提供的一种服务器的结构示意图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

另外，在本公开实施例的描述中，除非另有说明，“/”表示或的意思，例如，a/b可以表示a或b；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，在本公开实施例的描述中，“多个”是指两个或多于两个。

本公开所涉及的数据可以为经用户授权或者经过各方充分授权的数据。

首先，对本公开所涉及的技术术语进行介绍：

消息队列：消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。“消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器(消息队列服务器)在将消息从它的源(消息的生产者)中继到它的目标(消息的消费者)时充当中间人。消息队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

topic：主题。用于区分不同类型的业务消息对应的消息队列，不同主题的消息队列存储不同类型的业务消息。

参照图1所示，为本公开实施例提供的技术方案可能涉及的实施环境的示意图。该实施环境，可以包括客户端01、消息队列服务器02和业务处理设备03。其中，客户端01、消息队列服务器02和业务处理设备03三者时间可以通过有线通讯或无线通讯的方式通信。实际中，客户端01、消息队列服务器02和业务处理设备03三者均可以有多个，具体使用三者之间构筑的通讯网络中的那一条线路由业务消息的具体内容或参数决定。

示例性的，本公开中的客户端01可以是手机、平板电脑、桌面型、膝上型、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobilepersonalcomputer，umpc)、上网本，以及蜂窝电话、个人数字助理(personaldigitalassistant，pda)、增强现实(augmentedreality，ar)\虚拟现实(virtualreality，vr)设备等可以进行业务消息生产的设备，本公开实施例对该客户端的具体形态不作特殊限制。

示例性的，本公开中的消息队列服务器02可以是一台服务器，也可以是多台服务器组成的服务器集群，或者是一个云计算服务中心，本公开对此不做限定。消息队列服务器02主要用于接收客户端01发送的业务消息，并根据业务消息对应的主题创建相应的消息队列存储业务消息，同时还会根据对应同一主题的业务消息的中子业务消息的不同在对应的消息队列中建立不同的子队列用于存储不同的子业务消息。

示例性的，本公开中的业务处理设备03可以任意能够对消息队列服务器02发送的业务消息进行处理的设备。例如可以是一台服务器，也可以是多台服务器组成的服务器集群，或者是一个云计算服务中心，本公开对此不做具体限制。业务处理设备03主要用于接收消息队列服务器02发送的业务消息，并对其进行处理后将处理结果返回。

目前消息队列的实际使用过程中，为了避免对应不同主题topic的消息队列过多，不方便维护，会存在一个大类业务下多个子业务复用同一个消息队列的情况。在这种情况下，会通过为不同子业务设置不同的标签来区分。但是，参照图2所示，以两个子业务为例，对于某一个消息队列而言，如果其中子业务2的子业务消息较少，子业务1的子业务消息较多，则会存在消息队列中子业务2的子业务消息夹杂在大量的子业务1的子业务消息中，这样一来，需要每次多个子业务1的子业务消息被发送给业务处理设备处理之后才会将一个子业务2的子业务消息发送给业务处理设备处理，导致子业务2的子业务消息处理时延较大，用户体验较低。

针对上述问题，本公开提供一种消息队列的消息推送方法，能够降低复用同一消息队列的不同的子业务消息中部分数量较少的子业务消息的处理时延。该方法的具体执行主体可以为消息队列的消息推送装置，该装置可以为上述的消息队列服务器或者其中的一部分，具体根据实际需求而定。

参照图3所示，为本公开实施例提供的一种消息队列的消息推送方法的流程示意图。该方法由消息队列的消息推送装置执行，该装置可以为上述消息队列服务器或者其中一部分。该方法可以包括201和202。

201、确定待处理消息队列中每个子队列的权重。

其中，子队列用于存储待处理消息队列的业务消息中的一种子业务消息。

具体的，客户端产生了业务消息时，会将属于同一大类(例如视频业务)的业务消息发送到消息队列服务器中的一个消息队列，该消息队列便作为该大类业务消息的主题便于该大类业务消息的大类对应。同时，客户端对于属于同一大类的业务消息中不同的子业务的业务消息(例如主窗口消息和工具栏消息等)会设置不同的tag标签，使得消息队列服务器可以根据标签确定不同的子业务消息，从而为在消息队列中设置与子业务消息的对应的子队列，每个子队列中存储一种子业务消息。以某一大类业务消息包括两种子业务为例，消息队列服务器设定的消息队列的逻辑结构具体可参照图4所示，其中子队列1用于存储子业务1的子业务消息，子队列2用于存储子业务2的子业务消息。

202、根据待处理消息队列中子队列的权重，从待处理消息队列中的子队列中获取子业务消息，并向对应的业务处理设备发送。

基于上述方案可以看出，因为在该技术方案中，消息队列的消息推送装置中不同的子业务消息是存储在不同子队列的，而每个子队列都有对应的权重，消息队列的消息推送装置在向业务处理设备发送业务消息时会根据权重从子队列中获取相应的子业务信息，这种情况下，即便某个子队列中消息很少，其内部的子业务消息也具备足够的机会被发送至业务处理设备，降低复用同一消息队列的不同的子业务消息中部分数量较少的一类子业务消息的处理时延，提高了各类子业务消息对应用户的使用体验。避免了现有技术中所有同一主题的子业务消息存储在同一消息队列中时，如果某类子业务消息较少且被排在一些数量较多的子业务消息之后时，会导致该类子消息很长时间不能被处理，影响该类子业务消息对应的用户的使用体验的缺陷。

一种可实现的方式中，结合图3，参照图5所示，201步骤具体可以为201a：

201a、确定待处理消息队列中每个子队列的权重均为默认权重。

默认权重可以为用户根据实际需求设定。

这样一来，在根据权重从每个子队列中获取子业务消息时，每种子业务消息被选中的几率时一样的，从而使得无论每个子队列中的子业务消息的数量少还是多，都不会极大的影响到其他子队列中业务消息的处理时延，提高了用户的使用体验。

另一种可实现的方式中，结合图3，参照图6所示，201步骤具体可以为201b：

201b、根据待处理消息队列中子队列的特征参数，确定子队列的权重；特征参数至少包括子队列中存储的子业务信息的时延需求。

具体的，如果某个子队列中存储的子业务信息要求的时延越低，则可以将该子队列的权重设置的越大，这样一来便可以保证低时延要求的子业务能够更迅速的得到处理。另外，为了保证一些时延要求不是很低的子业务也不会很久才被处理，这里虽然会结合每种子业务消息的时延需求考虑对应子队列的权重，但也不会将不同子队列的权重设置的差别过大，防止出现某类子业务的处理时延过大，影响用户体验。

这样一来，既可以保证了复用同一消息队列的不同子业务消息中部分数量较少的一类子业务消息的处理时延不会很大，也保证了一些对时延要求很高的子业务消息能够被及时处理，进一步提高了用户体验。

可选的，结合图3，参照图7所示，202步骤具体可以为202a：

202a、根据待处理消息队列中子队列的权重，按照预设加权轮询算法，从待处理消息队列中的子队列中获取子业务消息，并向对应的业务处理设备发送。

一种可实现的方式，当预设加权轮询算法为普通加权轮询算法时，首先需要按照权重由小到大的顺序将不同子队列进行排序形成一个子队列数组，并计算所有子队列权重的最大公约数gcd，并设定一个调度权值cw为所有权重中的最大权重；然后轮询该子队列数组，依次找到其中权重大于或等于cw的子队列，从其中提取一定数量的子业务消息，直至该子队列数组的末尾；然后将cw更新为原调度权值减去gcd的差后，再次轮询该子队列数组，找到其中权重大于或等于cw的子队列，从其中提取一定数量的子业务消息，直至该子队列数组的末尾；循环上述cw更新和轮询子队列数组的步骤，若cw被更新指0时，则将其重置为最大权重。

示例性的，以消息队列中包括三个子队列a、b和c，a权重为1，b权重为2，c权重为4为例，对上述普通加权轮询算法进行如下说明：

首先gcd为1，cw初始值为4；

第一次轮询时，cw为4，则选中c，从c中获取一定数量的子业务信息；

第二次轮询时，cw为3，则选中c，从c中获取一定数量的子业务信息；

第三次轮询时，cw为2，则先选中b，从b中获取一定数量的子业务信息，然后选中c，从c中获取一定数量的子业务信息；

第四次轮询时，cw为1，则先选中a，从a中获取一定数量的子业务信息，然后选中b，从b中获取一定数量的子业务信息，然后选中c，从c中获取一定数量的业务信息；

第五次轮询时，cw为0重置为4，则重复上述的四次轮询过程。

可以看出，c被选中的几率最大，b次之，a再次之，四次轮询七次选中，c被选中4次，b被选中两次，a被选中一次。这样一来，即便某个子队列中的业务信息很少，也可以很快的被选中作为提取子业务消息的子队列，不会使得其中子业务消息的处理时延很大。

需要说明的是，实际中从消息队列中各个子队列中获取子业务消息，存在以下两种方式：

(1)每选中一次子队列，则从该子队列中获取到足够处理的子业务消息发送至业务处理设备，此时上述的一定数量为业务处理设备可以一次性处理完成的子业务消息的目标数量。

(2)每一轮算法循环后(即上述的四次轮询(第一次轮询至第四次轮询)或七次选中)，从每一次选中的子队列中获取一定数量的子业务消息发送至业务处理设备，此时上述的一定数量为目标数量和一轮算法循环中选中子队列的次数的商值；相比于前一种方式，这种选取子业务消息的方式能够使得每一次业务处理设备处理子业务消息时，会处理到所有的子业务消息，避免了前一种子业务消息选取方式中如果业务处理设备一次处理的时间过长的话，导致权重较小的子队列中的子业务消息的处理时延会较长的情况。当然，实际中还可以是其他任意可行方式，本公开对此不做具体限制。

另外，依据上述示例可以看出，如果消息队列中各个子队列的权重差异较大，例如三个子队列a、b和c的权重比值为5:1:1时，则会导致a被连续选中五次，那么如果获取子业务消息的方式为上述方式(1)，且业务处理设备每次处理子业务消息时间较大，则会使得b和c两个子队列中的子业务消息的处理时延较大，不够理想。所以为了进一步避免这种情况，在另一种可实现的方式中，本公开中的预设加权轮询算法还可以为平滑加权轮询算法，在该算法中，首先计算所有子队列的权重和为total，并为每个子队列另外设置一个调度权重cw，cw初始均为0；然后轮询所有子队列，让每个子队列的cw更新为上次更新的cw与自身权重的和，然后选取cw最大的子队列，从中提取业务信息，然后将选中子队列的cw更新为上次更新的cw减去total的差值。而后循环重复上述轮询过程。

示例性的，以消息队列中包括三个子队列a、b和c，a权重为4，b权重为2，c权重为1为例，对上述普通加权轮询算法进行如下说明：

首先所有子队列的cw均为0，total为7；

第一次轮询时，a的cw更新为4，b的cw更新为2，c的cw更新为1，则选中a，从a中获取一定数量的子业务信息，然后将a的cw更新为-3；

第二次轮询时，a的cw更新为1，b的cw更新为4，c的cw更新为2，则选中b，从b中获取一定数量的子业务信息，然后将b的cw更新为-3；

第三次轮询时，a的cw更新为5，b的cw更新为-1，c的cw更新为3，则选中a，从a中获取一定数量的子业务信息，然后将a的cw更新为-2；

第四次轮询时，a的cw更新为2，b的cw更新为1，c的cw更新为4，则选中c，从c中获取一定数量的子业务信息，然后将c的cw更新为-3；

第五次轮询时，a的cw更新为6，b的cw更新为3，c的cw更新为-2，则选中a，从a中获取一定数量的子业务信息，然后将a的cw更新为-1；

第六次轮询时，a的cw更新为3，b的cw更新为5，c的cw更新为-1，则选中b，从b中获取一定数量的子业务信息，然后将b的cw更新为-2；

第七次轮询时，a的cw更新为7，b的cw更新为0，c的cw更新为0，则选中a，从a中获取一定数量的子业务信息，然后将a的cw更新为0；

第八次轮询时，a的cw更新为4，b的cw更新为2，c的cw更新为1，循环执行上述的七次轮询过程。

可以看出，一轮算法循环，即七次轮询过程中，权重最大的a并没有被连续选中，每种子队列被选中的情况分布的比较均匀。这样一来，保证了复用同一消息队列的不同子业务消息中部分数量较少的一类子业务消息的处理时延不会很大。另外，从各个子队列中获取子业务消息的方式可以为上述的(1)或(2)，或者其他任意可行方式，本公开对此不做具体限制。

基于上述202a对应的技术方案，可以保证复用同一消息队列的不同子业务消息中部分数量较少的一类子业务消息的处理时延不会很大，避免了现有技术中所有子业务消息存储在同一消息队列中时，如果某类子业务消息较少且被排在一些数量较多的子业务消息之后时，会导致该类子业务消息很长时间不能被处理，影响该类子业务消息对应的用户的使用体验的缺陷。

可选的，结合图3，参照图8所示，202步骤具体可以为202b：

202b、从待处理消息队列中每个子队列中，获取与子队列的权重对应数量的子业务消息，并向对应的业务处理设备发送。

示例性的，以业务处理设备每次可以处理1000条子业务消息，消息队列中包括三个子队列a、b和c，且a、b和c之间权重比为3:3:4为例，执行2023b步骤时，会从a中获取300条子业务消息，从b中获取300条子业务消息，从c中获取400条子业务消息。

这样一来，可以保证每次业务处理设备处理子业务消息时，每个子队列中的子业务消息都会被提取一部分处理，降低复用同一消息队列的不同子业务消息中部分数量较少的一类子业务消息的处理时延，提高了各类子业务消息对应用户的使用体验。进一步的，对于权重高的子队列，其内的子业务信息处理的速度会更快写，也就保证这类高优先级(例如要求低时延)的业务信息可以被更快处理，进一步保障用户需求，提高用户体验。

可选的，该方法还包括：在确定待处理消息队列中的某个子队列中不存在子业务消息的情况下，将该子队列设定为无效子队列。此时，结合图3，参照图9所示，202步骤具体可以为202c：

202c、根据待处理消息队列中子队列的权重，从待处理消息队列中除无效子队列以外的子队列中获取子业务消息；无效子队列中不存在子业务消息。

这样一来，因为不需要消息队列服务器从一些暂时没有接收到子业务消息的子队列中提取子业务信息，所以可以降低整个消息推送过程的时延，以及减少整个消息推送过程的信令消耗。

可选的，为了能够及时存储子业务消息，参照图10所示，该方法还包括s1和s2：

s1、接收对应待处理消息队列的子业务消息，并确定子业务消息对应的子业务标签。

具体的，当然，实际中设置在消息队列服务中的消息队列的消息推送装置可以接收所有的业务消息(包括所有待处理消息队列的子业务消息)，客户端在生成业务消息并发送给消息队列服务器时，便会申请相应的topic主题队列，同时给同一主题不同子业务消息设置不同的tag标签，所以本公开可以根据子业务消息中附带的相关参数确定其主题，以决定其对应的待处理消息队列，然后可以根据tag标签(即子业务标签)确定其对应的子队列。

s2、将该子业务消息存储在待处理消息队列中对应该子业务标签的子队列中。

进一步可选的，为了能够及时建立新的子业务消息对应的子队列以存储该子业务信息，结合图10，参照图11所示，s2具体可以包括s21和s22：

s21、在待处理消息队列中不存在对应子业务标签的子队列的情况下，在待处理消息队列中创建对应子业务标签的子队列，并在其中存储子业务消息。

s22、在待处理消息队列中存在对应子业务标签的子队列的情况下，在待处理消息队列中对应子业务标签的子队列中存储子业务消息。

本公开提供的技术方案中，消息队列的消息推送装置会提前在所有的消息队列中设置对应不同子业务的子队列，然后在需要对某个消息队列(即待处理消息队列)进行消息推送时，首先确定需要进行消息推送的待处理消息队列中每个子队列的权重，然后根据每个子队列的权重，从各个子队列中获取子业务消息并向对应的业务服务器发送处理。因为在该技术方案中，不同子业务消息是存储在不同子队列的，而每个子队列都有对应的权重，消息队列的消息推送装置在向业务处理设备发送业务消息时会根据权重从子队列中获取相应的子业务信息，这种情况下，即便某个子队列中消息很少，其内部的子业务消息也具备足够的机会被发送至业务处理设备，降低复用同一消息队列的不同子业务消息中部分数量较少的一类子业务消息的处理时延，提高了各类子业务消息对应用户的使用体验。避免了现有技术中所有同一主题的子业务消息存储在同一消息队列中时，如果某类子业务消息较少且被排在一些数量较多的子业务消息之后时，会导致该类子消息很长时间不能被处理，影响该类子业务消息对应的用户的使用体验的缺陷。

上述明主要从服务器的角度对本公开实施例提供的方案进行了介绍。可以理解的是，服务器可以分别通过其中配置的消息队列的消息推送装置实现上述功能。为了实现上述功能，消息队列的消息推送装置包含了执行各个功能相应的硬件结构和/或软件模块，这些执行各个功能相应的硬件结构和/或软件模块可以构成一个。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的算法步骤，本公开能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

本公开实施例可以根据上述方法示例对服务器进行功能模块的划分，例如，服务器可以包括消息队列的消息推送装置，消息队列的消息推送装置可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本公开实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在采用对应各个功能划分各个功能模块的情况下，图12示出了应用在图2中所示消息队列服务器02的消息队列的消息推送装置04的一种可能的结构示意图，该消息队列的消息推送装置04包括：确定模块31和处理模块32。

其中，确定模块31，被配置为确定对应待处理消息队列中每个子队列的权重；子队列用于存储对应待处理消息队列的业务消息中的一种子业务消息；处理模块32，被配置为根据确定模块31确定的待处理消息队列中子队列的权重，从待处理消息队列中的子队列中获取子业务消息，并向对应的业务处理设备发送。

可选的，确定模块31具体被配置为：确定每个子队列的权重均为默认权重；或者，根据子队列的特征参数，确定子队列的权重；特征参数至少包括子队列中存储的子业务信息的时延需求。

可选的，处理模块32具体被配置为：根据确定模块31确定的待处理消息队列中子队列的权重，按照预设加权轮询算法，从待处理消息队列中的子队列中获取子业务消息。

可选的，处理模块32具体被配置为：从每个子队列中，获取与确定模块31确定的子队列的权重对应数量的子业务消息。

可选的，处理模块32具体被配置为：根据确定模块31确定的待处理消息队列中子队列的权重，从待处理消息队列中除无效子队列以外的子队列中获取子业务消息；无效子队列中不存在子业务消息。

可选的，还包括获取模块33和存储模块34；获取模块33，被配置为接收对应待处理消息队列的子业务消息，并确定子业务消息对应的子业务标签；存储模块34，被配置为将获取模块33接收的子业务消息存储在待处理消息队列中对应子业务标签的子队列中。

可选的，存储模块34具体被配置为：在待处理消息队列中不存在对应子业务标签的子队列的情况下，在待处理消息队列中创建对应子业务标签的子队列，并在其中存储子业务消息；在待处理消息队列中存在对应子业务标签的子队列的情况下，在待处理消息队列中对应子业务标签的子队列中存储子业务消息。

关于上述实施例中的消息队列的消息推送装置，其中各个模块执行操作的具体方式已经在前述中的消息队列的消息推送方法的实施例中进行了详细描述，此处将不做详细阐述说明。

在采用集成的单元的情况下，图13是根据一示例性实施例示出的如图1所示的消息队列服务器02的一种可能的结构示意图，该消息队列服务器02可以是上述的消息队列的消息推送装置04。如图13所示，该消息队列服务器02包括处理器41和存储器42。其中，存储器42用于存储处理器41可执行的指令，处理器41则可以实现上述实施例中消息队列的消息推送装置04中各个模块的功能。

其中，在具体的实现中，作为一种实施例，处理器41(41-1和41-2)可以包括一个或多个cpu，例如图13中所示的cpu0和cpu1。且作为一种实施例，空调的控制装置可以包括多个处理器41，例如图13中所示的处理器41-1和处理器41-2。这些处理器41中的每一个cpu可以是一个单核处理器(single-cpu)，也可以是一个多核处理器(multi-cpu)。这里的处理器41可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。处理器501可以包括应用处理器(applicationprocessor，ap)，调制解调处理器，图形处理器(graphicsprocessingunit，gpu)，图像信号处理器(imagesignalprocessor，isp)，控制器，存储器，视频编解码器，数字信号处理器(digitalsignalprocessor，dsp)，基带处理器，和/或神经网络处理器(neural-networkprocessingunit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

存储器42可以是只读存储器(read-onlymemory，rom)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(randomaccessmemory，ram)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、只读光盘(compactdiscread-onlymemory，cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘可读存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器42可以是独立存在，通过总线43与处理器41相连接。存储器42也可以和处理器41集成在一起。

总线43，可以是工业标准体系结构(industrystandardarchitecture，isa)总线、外部设备互连(peripheralcomponentinterconnect，pci)总线或扩展工业标准体系结构(extendedindustrystandardarchitecture，eisa)总线等。该总线43可以分为地址总线、数据总线、控制总线等。为便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

另外，为了方便消息队列服务器02与其他设备(例如开发客户端)进行信息交互，该消息队列服务器02包括通信接口44。通信接口44，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如控制系统、无线接入网(radioaccessnetwork，ran)，无线局域网(wirelesslocalareanetworks，wlan)等。通信接口44可以包括接收单元实现接收功能，以及发送单元实现发送功能。

本领域技术人员可以理解，图13中示出的结构并不构成对服务器的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有指令，当该可读存储介质上的指令由服务器的处理器执行时，使得服务器能够执行前述实施例中提供的应用在服务器上的消息队列的消息推送方法。

本公开实施例还提供一种包含指令的计算机程序产品，当其在服务器上运行时，使得服务器执行前述实施例提供的消息队列的消息推送方法。

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

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

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

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

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本公开实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。