CN115211092B - 一种消息拉取方法、装置以及计算机存储介质 - Google Patents

Abstract

本申请实施例公开了一种消息拉取方法、装置以及计算机存储介质，该方法包括：确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；根据所述第二拉取比例，对所述待消费主题进行消息拉取。

Description

一种消息拉取方法、装置以及计算机存储介质

技术领域

本申请实施例涉及数据应用技术领域，尤其涉及一种消息拉取方法、装置以及计算机存储介质。

背景技术

Kafka作为一种高吞吐量的分布式发布订阅消息系统，每条发布到kafka集群的消息都有一个主题，该主题被称为Topic。具体地，针对同一Topic可以创建具有不同优先级的多个子主题，每个子主题配置一个消费组，不同的消费组按照默认或用户自定义配置的不同优先级等级对应的消息个数比例，可以计算出不同优先级的最大拉取量。

然而，考虑到多个子主题中可能存在某个或某几个子主题无消息堆积时，这时候消费者拉取的消息量不满足初始化时分配的最大拉取量。如果部分子主题存在消息堆积，但是仍以固定比例来拉取消息，将会使得消费者拉取拉取的消息量小于最大拉取量，从而对用户造成存在异常的假象；另外，当较低优先级出现消息堆积而较高优先级无消息时，若较低优先级仍然以低配额的比例拉取消息，则会导致消费者频繁拉取小批量的消息，从而使得磁盘IO负载上升，且降低了操作系统预读带来的性能优势，导致Kafka集群出现性能瓶颈。

发明内容

本申请提供一种消息拉取方法、装置以及计算机存储介质，通过自适应动态配额方式，可以实时分配和更新各子主题的流控速率，且能够避免消费组频繁小批次拉取消息所导致的计算速率下降和Kafka集群性能瓶颈的问题。

本申请实施例的技术方案可以如下实现：

第一方面，本申请实施例提供了一种消息拉取方法，该方法包括：

确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；

根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；

若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；

根据所述第二拉取比例，对所述待消费主题进行消息拉取。

第二方面，本申请实施例提供了一种消息拉取装置，该消息拉取装置包括确定单元、调整单元和拉取单元，其中，

所述确定单元，配置为确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；

所述确定单元，还配置为根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；

所述调整单元，配置为若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；

所述拉取单元，配置为根据所述第二拉取比例，对所述待消费主题进行消息拉取。

第三方面，本申请实施例提供了一种消息拉取装置，该消息拉取装置包括存储器和处理器，其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如第一方面所述的方法。

第四方面，本申请实施例提供了一种计算机存储介质，该计算机存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如第一方面所述的方法。

本申请实施例提供了一种消息拉取方法、装置以及计算机存储介质，通过确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；根据所述第二拉取比例，对所述待消费主题进行消息拉取。这样，通过自适应动态配额方式进行动态流控，当部分子主题没有消息堆积时，能够避免因消费组频繁小批次拉取消息所导致的计算速率下降和Kafka集群性能瓶颈的问题，实现了计算性能的优化；另外，在某一子主题突发大流量消息写入的情况下，还能够实时分配和更新其流控速率，从而实现了最优的消费性能。

附图说明

图1为相关技术方案提供的一种消息拉取系统的流程框图示意图；

图2为相关技术方案提供的一种拉取消息应用的场景示意图；

图3为本申请实施例提供的一种消息拉取方法的流程示意图；

图4为本申请实施例提供的一种预设削减模式应用的场景示意图；

图5为本申请实施例提供的一种预设征集模式应用的场景示意图；

图6为本申请实施例提供的一种消息拉取装置的组成结构示意图；

图7为本申请实施例提供的另一种消息拉取装置的组成结构示意图；

图8为本申请实施例提供的一种消息拉取装置的硬件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。

消息中间件是一种广泛运用在分布式系统中的用于节点间通信的软件。在大规模高并发后台服务架构体系中，Kafka作为常用的消息中间件，应用非常广泛。

Kafka是由Linkedin公司开发并开源的消息中间件，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。其中，kafka开发的主要目标是构建一个用来处理海量日志、用户行为和网站运营统计等的数据处理框架，在结合了数据挖掘、行为分析、运营监控等需求的情况下，需要能够满足各种实时在线和批量离线处理应用场合对低延迟和批量吞吐性能的要求，并且可以通过集群来提供实时的消息。

Kafka集群包含一个或多个服务器，这种服务器被称为broker，每条发布到kafka集群的消息都有一个主题，该主题被称为topic，每个topic包含一个或多个子主题。参见图1，其示出了相关技术方案提供的一种消息拉取系统的流程框图实例；如图1所示，该消息拉取系统10包括有消息生产者101、Kafka集群102、客户端103和消费者104；其中，客户端103通常为第三方开发者提供的软件开发工具包(Software Development Kit，SDK)，也就是说SDK为开发人员快速接入中间件所提供的适配客户端。这样，在消息生产者101产生消息(message)之后，可以同时配置有该消息的优先级参数；例如：message1{priority:2；data:A3615C}、message2{priority:5；data:B36D4}等；即在客户端103中封装有优先级消息逻辑，然后通过在Kafka集群102中对同一主题创建以不同优先级结尾的子主题(topic-1、topic-2、topic-3、topic-4和topic-5等)来模拟具有不同优先级参数的消息写入；在消息写入对应优先级的子主题后，再通过客户端103从Kafka集群102内不同的子主题拉取消息，比如拉取的消息为message1(priority:2；data:A3615C)和message2(priority:5；data:B36D4)，最后将所拉取的消息发送给消费者104，由消费者104对所拉取的消息进行相关处理。

具体地，每一个优先级参数对应的子主题配置一个消费组，不同的消费组按照默认或用户自定义配置的不同优先级参数对应的拉取比例，乘以所有优先级所拉取消息的额定拉取量，就可以计算出不同优先级所分配的基准配额，再通过所配套的客户端SDK汇总不同子主题所拉取的消息，返回给用户一个拉取的批次消息，该批次消息中包含了不同优先级参数对应的拉取消息量，以此实现Kafka对不同优先级所拉取消息的支持。

考虑对于多个优先级参数对应的子主题，特定时刻下可能存在某一个和某几个子主题无消息堆积，这时候消费者所拉取消息的实际拉取量不满足初始化时分配的额定拉取量。如图2所示，其示出了相关技术方案提供的一种拉取消息应用的场景示意图。在图2中，同一主题所包括的topic-1、topic-2、topic-3、topic-4和topic-5等五个子主题中，优先级参数包括有5个等级，优先级参数等于5，表示优先级最高；优先级参数等于1，表示优先级最低；而且topic-1和topic-5中有消息堆积，但是topic-2、topic-3和topic-4无消息堆积；假定默认的额定拉取量为500，不同优先级参数对应的拉取比例(优先级从高到低)分别为：40％、30％、15％、10％、5％；具体地，topic-5的拉取配额为200，即优先级参数等于5的子主题每次可以拉取到200条消息；而topic-4的拉取配额为150，topic-3的拉取配额为75，topic-2的拉取配额为50，topic-1的拉取配额为25；也就是说，仅从topic-5和topic-1中可以拉取消息，而且实际拉取总量为225条消息。这样，基于图2所示的场景示例，在有子主题存在消息堆积的情况下，用户预期可以一次拉取到500条消息，但是由于不同优先级对应的拉取比例限制，使得用户实际上只拉取到了225条消息。如此，将会存在如下的问题：一方面，当部分子主题存在消息堆积，但是SDK所拉取消息的实际拉取总量小于用户设定的额定拉取量时，这时候会对用户造成存在异常的假象；另一方面，如果较低优先级出现消息堆积而较高优先级无消息(处于空闲态)，那么较低优先级仍然以低配额的比例拉取消息，可能导致消费者频繁拉取小批量的消息；而频繁地小批量拉取消息会导致大量随机读，从而导致磁盘IO负载上升，同时降低操作系统预读带来的性能优势，进而使得Kafka集群出现性能瓶颈。

基于此，本申请实施例提供了一种消息拉取方法，通过确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；根据所述第二拉取比例，对所述待消费主题进行消息拉取。这样，通过自适应动态配额方式进行动态流控，当部分子主题没有消息堆积时，能够避免因消费组频繁小批次拉取消息所导致的计算速率下降和Kafka集群性能瓶颈的问题，实现了计算性能的优化；另外，在某一子主题突发大流量消息写入的情况下，还能够实时分配和更新其流控速率，从而实现了最优的消费性能。

下面将结合附图对本申请各实施例进行详细描述。

本申请的一实施例中，参见图3，其示出了本申请实施例提供的一种消息拉取方法的流程示意图。如图3所示，该方法可以包括：

S301：确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；

需要说明的是，该方法应用于消息拉取系统。在消息拉取系统中，SDK向kafka集群内的待消费主题拉取消息。其中，同一个待消费主题可以创建多个子主题，且这多个子主题具有不同的优先级参数。

还需要说明的是，第一拉取比例为预先根据不同优先级参数所设定的默认拉取比例；这里，第一拉取比例表示各个子主题所预设的消息拉取数量相对整个待消费主题所预设的额定拉取量的占比。例如，假定多个子主题可以包括topic-5、topic-4、topic-3、topic-2和topic-1等五个子主题；而且优先级参数为5、4、3、2、1，5对应的优先级最高，1对应的优先级最低，这时候可以设定第一拉取比例分别为40％、30％、15％、10％、5％。

另外，在这多个子主题中，可能部分的子主题内存储有待消费消息，而部分的子主题内没有存储待消费消息。对于每一个子主题内所存储的待消费消息，则是由消息生产者所生产的，然后按照优先级参数放入对应的子主题中。具体地，在一些实施例中，在S301之前，该方法还可以包括：

接收消息生产者所发送的待消费消息，所述待消费消息中包括消息内容和优先级参数；

将所接收的待消费消息保存至所述优先级参数对应的子主题中，得到每一子主题对应的消息堆积量。

也就是说，在消息生产者生产出待消费消息之后，同时还会配置该待消费消息对应的优先级参数；这样，在通过kafka集群接收消息生产者所发送的待消费消息后，可以根据优先级参数，将所接收的待消费消息保存至对应的子主题中，从而得到每一个子主题的消息堆积量。

其中，如果消息生产者所生产的某优先级参数的消息较多，那么该优先级参数对应的子主题中，消息堆积量就越大；如果消息生产者所生产的某优先级参数的消息较少甚至没有，那么该优先级参数对应的子主题中，消息堆积量就越小，甚至消息堆积量等于0。

S302：根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；

需要说明的是，在获取到第一拉取比例之后，可以根据第一拉取比例进行消息拉取，从而确定出待消费主题中每一子主题的实际拉取量，以确定出待消费主题所拉取消息的实际拉取量。具体地，在一些实施例中，对于S302来说，所述根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量，可以包括：

根据所述第一拉取比例对每一子主题对应的消息堆积量进行消息拉取，获得每一子主题所拉取消息的实际拉取量；

将所述每一子主题所拉取消息的实际拉取量进行累加，得到所述待消费主题所拉取消息的实际拉取量。

也就是说，在获取到第一拉取比例之后，可以根据第一拉取比例对每一子主题对应的消息堆积量进行消息拉取，获得每一子主题所拉取消息的实际拉取量；然后将每一子主题所拉取消息的实际拉取量进行累加，从而得到该待消费主题所拉取消息的实际拉取量。

S303：若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；

需要说明的是，当多个子主题中其中一个子主题对应的消息堆积量等于0，那么可以得到该子主题所拉取消息的实际拉取量为0；这时候，待消费主题所拉取消息的实际拉取量将小于预设的额定拉取量，也就是说，该方法还可以包括：若其中一个子主题对应的消息堆积量等于0，则对第一拉取比例进行调整，以得到所述多个子主题各自分配的第二拉取比例。

进一步地，在一些实施例中，该方法还可以包括：

基于所述预设的额定拉取量以及所述第一拉取比例，确定所述多个子主题各自对应的预设配额；

将所述多个子主题中每一子主题所拉取消息的实际拉取量与每一子主题对应的预设配额进行比较；

若所述多个子主题中存在实际拉取量小于预设配额的至少一个子主题，则确定所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量。

也就是说，根据预设的额定拉取量以及第一拉取比例，可以确定出这多个子主题各自对应的预设配额(也可以称为基站配额)。具体地，可以包括：针对所述多个子主题，分别将每一子主题对应的第一拉取比例与所述预设的额定拉取量进行相乘，得到每一子主题对应的预设配额，从而确定出所述多个子主题各自对应的预设配额。

这里，每一子主题对应的预设配额表示每一子主题在进行消息拉取时的预设拉取消息个数。在计算出每一子主题对应的预设配额之后，可以将每一子主题所拉取消息的实际拉取量与每一子主题对应的预设配额进行比较；当多个子主题中存在实际拉取量小于预设配额的至少一个子主题，则确定待消费主题所拉取消息的实际拉取量小于预设的额定拉取量。

这样，当待消费主题所拉取消息的实际拉取量小于预设的额定拉取量时，表明了这时候需要对第一拉取比例进行动态调整，使得每一优先级参数对应的子主题所分配的拉取配额发生变化；根据变换后的拉取配额所对应的分配比例即为第二拉取比例，如此在下一次的消息拉取时，可以根据第二拉取比例进行消息拉取。

换句话说，这种自适应调整不同优先级参数所分配的拉取比例，可以称之为动态配额。具体地，通过动态调整不同优先级的拉取配额(或拉取比例)，可以实现动态流控；即在给定的总流控速率下，各优先级的流控速率动态分配，比如当某一优先级队列不存在消息堆积或者称之为消息堆积量等于0时，其流控速率(即拉取配额)可以动态分配给其他优先级使用，即对拉取比例进行调整，从而可以实现总消费速率的最优。

还需要说明的是，可以利用预设削减模式和/或预设征集模式来实现动态配额/动态流控。这里，预设削减模式可以看作是主动削减的，预设征集模式可以看作是被动征集的。

可选地，在一些实施例中，对于S303来说，所述对所述第一拉取比例进行调整，可以包括：

利用预设削减模式对所述多个子主题中待削减子主题对应的预设配额进行削减，并将得到的削减量分配给下一优先级参数对应的子主题，以实现对所述第一拉取比例的调整；其中，所述待削减子主题表示所述多个子主题中所存在的实际拉取量小于预设配额的子主题。

可选地，在一些实施例中，对于S303来说，所述对所述第一拉取比例进行调整，可以包括：

利用预设征集模式对所述多个子主题对应的预设配额进行征集，并将得到的征集量分配给待扩充子主题，以实现对所述第一拉取比例的调整；其中，所述待扩充子主题表示所述多个子主题中所存在的实际拉取量等于预设配额的子主题。

也就是说，在预设削减模式下，针对某一优先级参数对应的子主题所拉取消息的实际拉取量不足时，将主动释放自身的配额给其他优先级，以实现对第一拉取比例的调整；而在预设征集模式下，针对某一优先级参数对应的子主题所拉取消息的实际拉取量满足预设配额(benchMarkAllocation)时，如果这时候存在空闲配额，比如处于背压(BackPress)状态的优先级参数对应的子主题所主动削减的配额量，此时该优先级参数对应的子主题可以征集这部分配额，以实现对第一拉取比例的调整；其中，benchMarkAllocation表示根据默认或者用户自定义预先配置的不同优先级参数所分配的拉取比例，计算得到的基准配额；BackPress状态表示一种流量控制手段，当某一子主题所拉取消息的实际拉取量低于基准配额，这就表明了该子主题处于背压状态。

S304：根据所述第二拉取比例，对所述待消费主题进行消息拉取。

这样，经过对不同优先级参数对应的拉取比例进行调整后，可以得到第二拉取比例。这时候，如果用户触发SDK再次进行消息拉取，那么可以根据第二拉取比例对待消费主题进行消息拉取，从而再次得到待消费主题所拉取消息的实际拉取量。如此，在S304之后，该方法还可以包括：

若所得到的待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则继续对所述第二拉取比例进行调整，得到所述多个子主题各自分配的第三拉取比例；

根据所述第三拉取比例，对所述待消费主题进行消息拉取。

也就是说，只要所得到的待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则需要继续对当前的拉取比例进行调整，然后在下一次用户触发SDK进行消息拉取时，将会根据调整后的新拉取比例进行消息拉取；以实现对拉取比例的动态调整，从而也就实现了对不同优先级参数对应的多个子主题的动态配额。

需要说明的是，本申请实施例的该消息拉取方法中，除了kafka之外，动态配额或者动态流控方式还可以应用到其他具有动态流控需求的中间件，从而获取最优的消费性能。

本实施例提供了一种消息拉取方法，通过确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；根据所述第二拉取比例，对所述待消费主题进行消息拉取。这样，通过自适应动态配额方式进行动态流控，当部分子主题没有消息堆积时，能够避免因消费组频繁小批次拉取消息所导致的计算速率下降和Kafka集群性能瓶颈的问题，实现了计算性能的优化；另外，在某一子主题突发大流量消息写入的情况下，还能够实时分配和更新其流控速率，从而实现了最优的消费性能。

本申请的另一实施例中，以预设削减模式为例，对于S303来说，所述对所述第一拉取比例进行调整，可以包括：

若所述多个子主题中其中一个子主题对应的实际拉取量小于预设配额，则将所述其中一个子主题作为待削减子主题，并对所述待削减子主题对应的预设配额进行削减，得到剩余预设配额；

当所述剩余预设配额不低于预设最低配额时，计算所述待削减子主题对应的预设配额与剩余预设配额之间的差值，得到可用配额；

顺序降低优先级参数，将降低后的优先级参数对应的子主题作为第一子主题；

判断所述第一子主题所对应的预设配额是否大于最大配额阈值且所述第一子主题是否处于全速处理状态；

当所述第一子主题对应的预设配额不大于最大配额阈值且所述第一子主题处于全速处理状态时，将所述可用配额分配给所述第一子主题，并更新所述第一子主题对应的预设配额；

当所述第一子主题对应的预设配额大于最大配额阈值且所述第一子主题处于非全速处理状态时，继续执行所述顺序降低优先级参数，将降低后的优先级参数对应的子主题作为第一子主题的步骤，直至将所述可用配额分配至最低优先级参数对应的子主题，以实现对所述第一拉取比例的调整。

需要说明的是，“顺序降低优先级参数”表示当前为优先级4对应的子主题，执行顺序降低优先级参数后，降低后的优先级参数对应的子主题为优先级3对应的子主题；再一次执行顺序降低优先级参数后，降低后的优先级参数对应的子主题为优先级2对应的子主题，依次类推，在所有优先级参数均处于非全速处理状态下，直至将可用配额分配至最低优先级参数对应的子主题。

还需要说明的是，最大配额阈值可以用highWaterMark限制表示，主要是为了避免动态配额导致预设的额定拉取量全部集中分配到特定优先级参数对应的子主题，这时候需要为每个优先级参数配置最大的拉取量限制。而全速处理状态可以用Full Progress状态表示，表示为当前子主题所动态配额后的实际拉取量大于或等于基准配额，也即表明了当前子主题在全速消费消息。

这样，预设削减模式而言，每次拉取消息时，针对实际拉取量不足预设分配量的优先级参数所对应的子主题，可以降低自身配额。这里，所降低的配额量可以根据实际情况进行设定，比如削减一半的配额量；然后将该子主题自身的配额与该子主题的剩余配额量进行差值计算，所得到的差值作为可用配额进行分配，同时仅向次一级优先级参数对应的子主题分配配额，如果次一级优先级参数对应的子主题自身的配额到达最大配额阈值(highWaterMark限制)时，那么多余的配额可以继续向下一级优先级参数对应的子主题进行分配。另外，受配额的优先级参数需要处于全速处理(Full Progress)状态，如果所有优先级参数均不处于全速处理状态，那么可用配额最终会聚集到最低优先级参数所对应的子主题，同时最低优先级不做highWaterMark限制。

进一步地，针对待削减子主题的配额削减，并不会一直无限削减下去，当待削减子主题所对应的动态配额低于预设最低配额时，将会停止对待削减子主题的配额削减；在所有待削减子主题所对应的动态配额均低于预设最低配额时，将会停止对拉取比例的动态调整。因此，在一些实施例中，该方法还可以包括：

每一次对所述待消费主题进行消息拉取后，利用所述第二拉取比例更新所述第一拉取比例；

根据更新后的第一拉取比例对待消费主题进行消息拉取，得到所述待消费主题所拉取消息的更新后实际拉取量；

若所述待消费主题所拉取消息的更新后实际拉取量小于预设的额定拉取量，则继续对所述第一拉取比例进行调整，以得到所述第二拉取比例，返回所述利用所述第二拉取比例更新所述第一拉取比例的步骤；

在对待消费主题进行多次消息拉取后，当所述待削减子主题所对应的动态配额均达到预设最低配额时，停止对所述第一拉取比例进行调整的步骤。

也就是说，在每一次对待消费主题进行消息拉取后，可以利用第二拉取比例更新第一拉取比例；如此在下一次通过触发客户端SDK来拉取消息时，可以利用更新后的第一拉取比例进行消息拉取，然后得到待消费主题所拉取消息的更新后实际拉取量；如果所得到的待消费主题所拉取消息的更新后实际拉取量小于预设的额定拉取量，那么需要继续对第一拉取比例进行调整。

如此，在经过多次消息拉取后，当待削减子主题所对应的动态配额均达到预设最低配额时，表明了待削减子主题所对应的动态配额均已经达到低水位限制，这时候需要停止对第一拉取比例进行调整，后续再次通过触发客户端SDK来拉取消息时，可以按照最新动态更新后的拉取比例进行消息拉取。还需要说明的是，预设最低配额主要是为了避免无消息堆积的子主题对应的配额主动削减为0，而设置的配额下限。这里，预设最低配额可以根据实际情况进行具体设定，通常可以将默认配置的预设配额(或者称之为基准配额)的十六分之一作为预设最低配额，但是并不作具体限定。

参见图4，其示出了本申请实施例提供的一种预设削减模式的应用场景示意图。在图4中，除了Kafka集群102、客户端103和消费者104之外，消息拉取系统10还可以包括有内部状态维护器105；这里，内部状态维护器105可以是一个状态窗口(window)。具体地，同一主题所包括的topic-1、topic-2、topic-3、topic-4和topic-5等五个子主题中，优先级参数包括有5个等级，优先级参数等于5，表示优先级最高；优先级参数等于1，表示优先级最低；而且topic-1和topic-5中有消息堆积，但是topic-2、topic-3和topic-4无消息堆积；假定默认的额定拉取量为500，不同优先级参数对应的预设拉取比例(优先级从高到低)分别为：40％、30％、15％、10％、5％；具体地，topic-5的预设配额为200，topic-4的预设配额为150，topic-3的预设配额为75，topic-2的预设配额为50，topic-1的预设配额为25；也就是说，仅可以从topic-5和topic-1中拉取消息；这时候利用预设削减模式，topic-2、topic-3、topic-4作为待削减子主题；在每一次拉取消息时，由于实际拉取量低于预设配额，那么将会针对其中一个待削减子主题主动削减一半配额，削减配额将依次分配给次优先级参数对应的子主题；如果次优先级参数也无消息堆积，将继续向下一级优先级参数分配，最终落到最低优先级，以实现拉取比例的调整；在经过多次拉取消息之后，topic-2、topic-3、topic-4这三个待削减子主题的动态配额被将至其默认配额的1/16后，针对topic-2、topic-3、topic-4的更新后配额分别为：3、4、9；而且topic-2、topic-3、topic-4所释放出的配额可以为topic-1和topic-5使用，即可以作为topic-1和topic-5的可征集配额；这里，topic-1和topic-5的可征集配额为259。

本申请的又一实施例中，以预设削减模式为例，对于S303来说，所述对所述第一拉取比例进行调整，可以包括：

若所述多个子主题中其中一个子主题对应的实际拉取量等于预设配额，则将所述其中一个子主题作为待扩充子主题，按照预设增加量增加所述待扩充子主题对应的预设配额；

针对所述预设增加量，将最低优先级对应的子主题作为第二子主题；

判断所述第二子主题是否处于全速处理状态；

当所述第二子主题处于全速处理状态时，从所述第二子主题进行配额征集；

若所征集的配额量小于所述预设增加量，计算所述预设增加量与所征集的配额量之间的差值；

针对所计算的差值，顺序升高优先级参数，将升高后的优先级参数对应的子主题作为第二子主题，继续执行所述判断所述第二子主题是否处于全速处理状态的步骤，直至所征集得到的配额量等于所述预设增加量，以实现对所述第一拉取比例的调整。

进一步地，在所述判断所述第二子主题是否处于全速处理状态之后，该方法还可以包括：

当所述第二子主题处于非全速处理状态时，顺序升高优先级参数，将升高后的优先级参数对应的子主题作为第二子主题，继续执行所述判断所述第二子主题是否处于全速处理状态的步骤。

需要说明的是，“顺序升高优先级参数”表示当前为优先级2对应的子主题，执行顺序升高优先级参数后，升高后的优先级参数对应的子主题为优先级3对应的子主题；再一次执行顺序升高优先级参数后，升高后的优先级参数对应的子主题为优先级4对应的子主题，依次类推，所征集得到的配额量等于所述预设增加量。

还需要说明的是，从第二子主题进行配额征集，首先需要计算第二子主题所能够征集的配额量，即因为其他优先级参数主动削减而加入到本优先级参数的配额；可以通过第二子主题当前的动态配额减去预设配额，差值即为第二子主题所能够征集的配额量；然后将所能够征集的配额量与预设增加量进行比较；当所征集的配额量小于预设增加量时，计算预设增加量与所征集的配额量之间的差值，该差值递归从高一优先级参数对应的子主题进行征集；当所征集的配额量不小于预设增加量时，该预设增加量可以全部从该子主题进行征集；然后针对其他的待扩充子主题继续进行配额征集。

这样，对于特定优先级参数无消息堆积的情况下，而后因为消息生产所导致的消息堆积情况，那么之前被削减配额的优先级参数对应的子主题需要补充配额。具体地，可以为通过消费组本次从某优先级参数对应的子主题中所拉取消息的实际拉取量等于当前为其动态分配的预设配额，那么可以对该子主题的配额更新为其增加一倍的拉取配额，即预设增加量可以为该子主题当前的预设配额；而预设增加量(可以用A表示)需要从其他优先级参数对应的子主题征集，征集策略为优先从最低优先级参数对应的子主题征集；针对该最低优先级参数对应的子主题，需要计算该子主题的配额扩充量(即因为其他优先级参数主动削减而加入到本优先级参数的配额)，如果当前的配额扩充量B低于预设增加量A，那么剩余部分(A-B)递归从高一优先级征集，直至达到所需的预设增加量。这里，被征集的高优先级参数对应的子主题必须处于Full Progress状态，可征集的配额量大小除了受当前优先级参数对应的highWaterMark限制，还受其他优先级参数对应的配额扩充量限制，总之，还需要保持动态配额的总量是一致的。

进一步地，针对待扩充子主题的配额扩充，并不会一直无限扩充下去，当待扩充子主题所对应的动态配额高于预设最高配额时，将会停止对待扩充子主题的配额扩充；在所有待削减子主题所对应的动态配额均高于预设最低配额时，将会停止对拉取比例的动态调整。因此，在一些实施例中，该方法还可以包括：

每一次对所述待消费主题进行消息拉取后，利用所述第二拉取比例更新所述第一拉取比例；

根据更新后的第一拉取比例对待消费主题进行消息拉取，得到所述待消费主题所拉取消息的更新后实际拉取量；

若所述待消费主题所拉取消息的更新后实际拉取量小于预设的额定拉取量，则继续对所述第一拉取比例进行调整，以得到所述第二拉取比例，返回所述利用所述第二拉取比例更新所述第一拉取比例的步骤；

在对待消费主题进行多次消息拉取后，当所述待扩充子主题所对应的动态配额均达到预设最高配额时，停止对所述第一拉取比例进行调整的步骤。

也就是说，在每一次对待消费主题进行消息拉取后，可以利用第二拉取比例更新第一拉取比例；如此在下一次通过触发客户端SDK来拉取消息时，可以利用更新后的第一拉取比例进行消息拉取，然后得到待消费主题所拉取消息的更新后实际拉取量；如果所得到的待消费主题所拉取消息的更新后实际拉取量小于预设的额定拉取量，那么需要继续对第一拉取比例进行调整。

如此，在经过多次消息拉取后，当待扩充子主题所对应的动态配额均达到预设最高配额时，表明了待扩充子主题所对应的动态配额均已经达到高水位限制，这时候需要停止对第一拉取比例进行调整，后续再次通过触发客户端SDK来拉取消息时，可以按照最新动态更新后的拉取比例进行消息拉取。还需要说明的是，预设最高配额主要是为了避免有消息堆积的子主题对应的配额被动征集后全部集中到特定优先级参数对应的子主题，而设置的配额上限。这里，预设最高配额可以根据实际情况进行具体设定，通常对于最低优先级参数而言，其预设最高配额可以为默认配置的预设配额(或者称之为基准配额)的一倍；而其他优先级参数，其预设最高配额可以为其自身基准配额的八倍，但是并不作具体限定。

参见图5，其示出了本申请实施例提供的一种预设征集模式的应用场景示意图。在图5中，除了Kafka集群102、客户端103和消费者104之外，消息拉取系统10仍包括有内部状态维护器105。具体地，同一主题所包括的topic-1、topic-2、topic-3、topic-4和topic-5等五个子主题中，优先级参数包括有5个等级，优先级参数等于5，表示优先级最高；优先级参数等于1，表示优先级最低；而且topic-1和topic-5中有消息堆积，但是topic-2、topic-3和topic-4无消息堆积；假定默认的额定拉取量为500，不同优先级参数对应的预设拉取比例(优先级从高到低)分别为：40％、30％、15％、10％、5％；具体地，topic-5的预设配额为200，topic-4的预设配额为150，topic-3的预设配额为75，topic-2的预设配额为50，topic-1的预设配额为25；也就是说，仍然是仅可以从topic-5和topic-1中拉取消息；这时候利用预设征集模式，对于topic-1来说，其作为最低优先级参数，其预设最高配额可以为默认配置的预设配额的一倍，即可以增加的配额量为25，也就是说，topic-1更新后配额为50；这里，所增加的配额量可以从topic-2征集；由于topic-2、topic-3、topic-4等三个优先级参数所释放出的可征集配额为259；那么对于topic-5来说，其作为最高优先级参数，从该可征集配额中，可以获得能够增加的配额量为234，也就是说，topic-5更新后配额为434；这种情况下，再次通过触发客户端SDK来拉取消息时，待消费主题所拉取消息的实际拉取量为484。

也就是说，基于图5所示的场景示例，topic-1和topic-5作为待扩充子主题，可以征集从topic-2、topic-3、topic-4等3个优先级参数所释放出来的配额，然后根据高优先级参数对应高配额的拉取消息占比以及高水位限制，从而保证高优先级参数可以拥有更多的计算资源来处理消息。

在本申请实施例中，通过预设削减模式和预设征集模式等两个策略来实现动态配额和动态流控，可以避免固定比例拉取消息时所存在的因当部分子主题没有消息堆积时而消费组频繁小批次拉取消息所导致的计算速率下降和Kafka集群性能瓶颈的问题，实现了计算性能的最优；并且依赖动态配额实现的动态流控，在某一子主题突发大流量消息写入的情况下，还能够实时分配和更新其流控速率，以实现最优的消费性能。也就是说，本申请实施例的消息拉取方法的实现方式中存在有一个状态窗口(Window)，用于收集元数据、保存默认配额、当前配额、配额高水位、配额低水位、各优先级的处理状态等；而Window会被具体的实现策略(比如负载均衡(Load Balance)策略)调用以实现配额比例的分配和征集，各个优先级参数对应的子主题每次拉取消息的实际拉取量可以作为元数据写入Window，并且Window会实时更新各优先级参数的处理状态，然后由Load Balance在给定时间间隔内调用以触发动态配额和动态流控，而且动态配额会计算出发生配额变化的优先级参数并通过反射更新Kafka集群内消费者每次拉取消息的实际拉取量，动态流控则是通过计算动态配额后各优先级参数相对于默认的预设配额的比例，从而得出各优先级参数当前应分配的流控速率，且保持动态配额的总量是一致的。

本实施例提供了一种消息拉取方法，通过上述实施例对前述实施例的具体实现进行详细阐述，从中可以看出，通过预设削减模式和预设征集模式等两个策略来实现动态配额和动态流控，当部分子主题没有消息堆积时，能够避免因消费组频繁小批次拉取消息所导致的计算速率下降和Kafka集群性能瓶颈的问题，实现了计算性能的优化；另外，在某一子主题突发大流量消息写入的情况下，还能够实时分配和更新其流控速率，从而实现了最优的消费性能。

基于前述实施例相同的发明构思，参见图6，其示出了本申请实施例提供的一种消息拉取装置的组成结构示意图。如图6所示，该消息拉取装置60可以包括确定单元601、调整单元602和拉取单元603；其中，

确定单元601，配置为确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；

确定单元601，还配置为根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；

调整单元602，配置为若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；

拉取单元603，配置为根据所述第二拉取比例，对所述待消费主题进行消息拉取。

在上述方案中，参见图7，该消息拉取装置60还可以包括接收单元604和保存单元605；其中，

接受单元604，配置为接收消息生产者所发送的待消费消息，所述待消费消息中包括消息内容和优先级参数；

保存单元605，配置为将所接收的待消费消息保存至所述优先级参数对应的子主题中，得到每一子主题对应的消息堆积量。

在上述方案中，参见图7，该消息拉取装置60还可以包括计算单元606；其中，

拉取单元603，还配置为根据所述第一拉取比例对每一子主题对应的消息堆积量进行消息拉取，获得每一子主题所拉取消息的实际拉取量；

计算单元606，配置为将所述每一子主题所拉取消息的实际拉取量进行累加，得到所述待消费主题所拉取消息的实际拉取量。

在上述方案中，确定单元601，还配置为若所述多个子主题中其中一个子主题对应的消息堆积量等于0，则得到所述其中一个子主题所拉取消息的实际拉取量为0；

相应的，调整单元602，还配置为若其中一个子主题对应的消息堆积量等于0，则对所述第一拉取比例进行调整，以得到所述多个子主题各自分配的第二拉取比例。

在上述方案中，参见图7，该消息拉取装置60还可以包括比较单元607；其中，

确定单元601，还配置为基于所述预设的额定拉取量以及所述第一拉取比例，确定所述多个子主题各自对应的预设配额；

比较单元607，配置为将所述多个子主题中每一子主题所拉取消息的实际拉取量与每一子主题对应的预设配额进行比较；以及若所述多个子主题中存在实际拉取量小于预设配额的至少一个子主题，则确定所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量。

在上述方案中，调整单元602，还配置为利用预设削减模式对所述多个子主题中待削减子主题对应的预设配额进行削减，并将得到的削减量分配给下一优先级参数对应的子主题，以实现对所述第一拉取比例的调整；其中，所述待削减子主题表示多个子主题中所存在的实际拉取量小于预设配额的子主题。

在上述方案中，比较单元607，还配置为若所述多个子主题中其中一个子主题对应的实际拉取量小于预设配额，则将所述其中一个子主题作为待削减子主题，并对所述待削减子主题对应的预设配额进行削减，得到剩余预设配额；以及当所述剩余预设配额不低于预设最低配额时，计算所述待削减子主题对应的预设配额与剩余预设配额之间的差值，得到可用配额；

调整单元602，具体配置为顺序降低优先级参数，将降低后的优先级参数对应的子主题作为第一子主题；以及判断所述第一子主题所对应的预设配额是否大于最大配额阈值且所述第一子主题是否处于全速处理状态；以及当所述第一子主题对应的预设配额不大于最大配额阈值且所述第一子主题处于全速处理状态时，将所述可用配额分配给所述第一子主题，并更新所述第一子主题对应的预设配额；以及当所述第一子主题对应的预设配额大于最大配额阈值且所述第一子主题处于非全速处理状态时，继续执行所述顺序降低优先级参数，将降低后的优先级参数对应的子主题作为第一子主题的步骤，直至将所述可用配额分配至最低优先级参数对应的子主题，以实现对所述第一拉取比例的调整。

在上述方案中，调整单元602，还配置为利用预设征集模式对所述多个子主题对应的预设配额进行征集，并将得到的征集量分配给待扩充子主题，以实现对所述第一拉取比例的调整；其中，所述待扩充子主题表示多个子主题中所存在的实际拉取量等于预设配额的子主题。

在上述方案中，比较单元607，还配置为若所述多个子主题中其中一个子主题对应的实际拉取量等于预设配额，则将所述其中一个子主题作为待扩充子主题，按照预设增加量增加所述待扩充子主题对应的预设配额；

调整单元602，具体配置为针对所述预设增加量，将最低优先级对应的子主题作为第二子主题；以及判断所述第二子主题是否处于全速处理状态；以及当所述第二子主题处于全速处理状态时，从所述第二子主题进行配额征集；以及若所征集的配额量小于所述预设增加量，计算所述预设增加量与所征集的配额量之间的差值；以及针对所计算的差值，顺序升高优先级参数，将升高后的优先级参数对应的子主题作为第二子主题，继续执行所述判断所述第二子主题是否处于全速处理状态的步骤，直至所征集得到的配额量等于所述预设增加量，以实现对所述第一拉取比例的调整。

在上述方案中，调整单元602，还配置为当所述第二子主题处于非全速处理状态时，顺序升高优先级参数，将升高后的优先级参数对应的子主题作为第二子主题，继续执行所述判断所述第二子主题是否处于全速处理状态的步骤。

可以理解地，在本实施例中，“单元”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是模块，还可以是非模块化的。而且在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

因此，本实施例提供了一种计算机存储介质，该计算机存储介质存储有消息拉取程序，所述消息拉取程序被至少一个处理器执行时实现前述实施例中任一项所述的方法。

基于上述消息拉取装置60的组成以及计算机存储介质，参见图8，其示出了本申请实施例提供的消息拉取装置60的具体硬件结构示例，可以包括：通信接口801、存储器802和处理器803；各个组件通过总线系统804耦合在一起。可理解，总线系统804用于实现这些组件之间的连接通信。总线系统804除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图8中将各种总线都标为总线系统804。其中，通信接口801，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；

存储器802，用于存储能够在处理器803上运行的计算机程序；

处理器803，用于在运行所述计算机程序时，执行：

确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；

根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；

若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；

根据所述第二拉取比例，对所述待消费主题进行消息拉取。

可以理解，本申请实施例中的存储器802可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步链动态随机存取存储器(Synchronous link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本申请描述的系统和方法的存储器802旨在包括但不限于这些和任意其它适合类型的存储器。

而处理器803可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器803中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器803可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器802，处理器803读取存储器802中的信息，结合其硬件完成上述方法的步骤。

可以理解的是，本申请描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(Application Specific Integrated Circuits，ASIC)、数字信号处理器(Digital SignalProcessing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(ProgrammableLogic Device，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本申请所述功能的模块(例如过程、函数等)来实现本申请所描述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

可选地，作为另一个实施例，处理器803还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法的步骤。

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

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

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

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

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

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

工业实用性

本申请实施例中，通过确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；根据所述第二拉取比例，对所述待消费主题进行消息拉取。这样，通过自适应动态配额方式进行动态流控，当部分子主题没有消息堆积时，能够避免因消费组频繁小批次拉取消息所导致的计算速率下降和Kafka集群性能瓶颈的问题，实现了计算性能的优化；另外，在某一子主题突发大流量消息写入的情况下，还能够实时分配和更新其流控速率，从而实现了最优的消费性能。

Claims (13)

1.一种消息拉取方法，所述方法包括：

确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；

根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；

若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；

根据所述第二拉取比例，对所述待消费主题进行消息拉取。

2.根据权利要求1所述的方法，其中，所述方法还包括：

接收消息生产者所发送的待消费消息，所述待消费消息中包括消息内容和优先级参数；

将所接收的待消费消息保存至所述优先级参数对应的子主题中，得到每一子主题对应的消息堆积量。

3.根据权利要求2所述的方法，其中，所述根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量，包括：

根据所述第一拉取比例对每一子主题对应的消息堆积量进行消息拉取，获得每一子主题所拉取消息的实际拉取量；

将所述每一子主题所拉取消息的实际拉取量进行累加，得到所述待消费主题所拉取消息的实际拉取量。

4.根据权利要求3所述的方法，其中，所述获得每一子主题所拉取消息的实际拉取量，包括：

若所述多个子主题中其中一个子主题对应的消息堆积量等于0，则得到所述其中一个子主题所拉取消息的实际拉取量为0；

相应的，所述方法还包括：

若其中一个子主题对应的消息堆积量等于0，则对所述第一拉取比例进行调整，以得到所述多个子主题各自分配的第二拉取比例。

5.根据权利要求1所述的方法，其中，所述方法还包括：

基于所述预设的额定拉取量以及所述第一拉取比例，确定所述多个子主题各自对应的预设配额；

将所述多个子主题中每一子主题所拉取消息的实际拉取量与每一子主题对应的预设配额进行比较；

若所述多个子主题中存在实际拉取量小于预设配额的至少一个子主题，则确定所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量。

6.根据权利要求5所述的方法，其中，所述对所述第一拉取比例进行调整，包括：

利用预设削减模式对所述多个子主题中待削减子主题对应的预设配额进行削减，并将得到的削减量分配给下一优先级参数对应的子主题，以实现对所述第一拉取比例的调整；其中，所述待削减子主题表示所述多个子主题中所存在的实际拉取量小于预设配额的子主题。

7.根据权利要求6所述的方法，其中，所述利用预设削减模式对所述多个子主题中待削减子主题对应的预设配额进行削减，并将得到的削减量分配给下一优先级参数对应的子主题，包括：

若所述多个子主题中其中一个子主题对应的实际拉取量小于预设配额，则将所述其中一个子主题作为待削减子主题，并对所述待削减子主题对应的预设配额进行削减，得到剩余预设配额；

当所述剩余预设配额不低于预设最低配额时，计算所述待削减子主题对应的预设配额与剩余预设配额之间的差值，得到可用配额；

顺序降低优先级参数，将降低后的优先级参数对应的子主题作为第一子主题；

判断所述第一子主题所对应的预设配额是否大于最大配额阈值且所述第一子主题是否处于全速处理状态；

当所述第一子主题对应的预设配额不大于最大配额阈值且所述第一子主题处于全速处理状态时，将所述可用配额分配给所述第一子主题，并更新所述第一子主题对应的预设配额；

当所述第一子主题对应的预设配额大于最大配额阈值且所述第一子主题处于非全速处理状态时，继续执行所述顺序降低优先级参数，将降低后的优先级参数对应的子主题作为第一子主题的步骤，直至将所述可用配额分配至最低优先级参数对应的子主题，以实现对所述第一拉取比例的调整。

8.根据权利要求5所述的方法，其中，所述对所述第一拉取比例进行调整，包括：

利用预设征集模式对所述多个子主题对应的预设配额进行征集，并将得到的征集量分配给待扩充子主题，以实现对所述第一拉取比例的调整；其中，所述待扩充子主题表示所述多个子主题中所存在的实际拉取量等于预设配额的子主题。

9.根据权利要求8所述的方法，其中，所述利用预设征集模式对所述多个子主题对应的预设配额进行征集，并将得到的征集量分配给待扩充子主题，包括：

若所述多个子主题中其中一个子主题对应的实际拉取量等于预设配额，则将所述其中一个子主题作为待扩充子主题，按照预设增加量增加所述待扩充子主题对应的预设配额；

针对所述预设增加量，将最低优先级对应的子主题作为第二子主题；

判断所述第二子主题是否处于全速处理状态；

当所述第二子主题处于全速处理状态时，从所述第二子主题进行配额征集；

若所征集的配额量小于所述预设增加量，计算所述预设增加量与所征集的配额量之间的差值；

针对所计算的差值，顺序升高优先级参数，将升高后的优先级参数对应的子主题作为第二子主题，继续执行所述判断所述第二子主题是否处于全速处理状态的步骤，直至所征集得到的配额量等于所述预设增加量，以实现对所述第一拉取比例的调整。

10.根据权利要求9所述的方法，其中，在所述判断所述第二子主题是否处于全速处理状态之后，所述方法还包括：

当所述第二子主题处于非全速处理状态时，顺序升高优先级参数，将升高后的优先级参数对应的子主题作为第二子主题，继续执行所述判断所述第二子主题是否处于全速处理状态的步骤。

11.一种消息拉取装置，所述消息拉取装置包括确定单元、调整单元和拉取单元，其中，

所述确定单元，配置为确定待消费主题所包括的多个子主题以及各自分配的第一拉取比例；其中，不同的子主题具有不同的优先级参数；

所述确定单元，还配置为根据所述第一拉取比例，确定所述待消费主题所拉取消息的实际拉取量；

所述调整单元，配置为若所述待消费主题所拉取消息的实际拉取量小于预设的额定拉取量，则对所述第一拉取比例进行调整，得到所述多个子主题各自分配的第二拉取比例；

所述拉取单元，配置为根据所述第二拉取比例，对所述待消费主题进行消息拉取。

12.一种消息拉取装置，所述消息拉取装置包括存储器和处理器，其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如权利要求1至10任一项所述的方法。

13.一种计算机存储介质，其中，所述计算机存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如权利要求1至10任一项所述的方法。