CN114584625A - 一种消息处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开涉及一种消息处理方法、装置、电子设备及存储介质，该方法包括：当确定进入重新分配分区状态时，更新客户端群组信息；客户端群组信息包括多个客户端标识；获取每个客户端标识对应的客户端的当前分区信息；基于每个客户端的当前分区信息，执行预设分配策略，得到每个客户端的重分配分区信息；根据每个客户端的重分配分区信息确定多个客户端中的待调整客户端，向待调整客户端发送提示信息；提示信息指示待调整客户端发起同步分区请求；当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息。本公开基于服务端实现分区的重新分配，可以大幅缩小重分配分区的时间，可以降低重分配分区对客户端的影响。

Description

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

技术领域

本公开涉及互联网技术领域，尤其涉及一种消息处理方法、装置、电子设备及存储介质。

背景技术

在消息队列系统中，主要有生产者、消费者和主题三个主要角色。其中，生产者向主题中写入消息进行生产，而消费者从主题中拉取消息进行消费。在消息队列如Kafka中，消费者们被划分为一个个消费者组，每一个消费者组可以订阅若干个主题，而对于被订阅主题中的每个分区，只能由当前消费者组中的一个消费者来消费。

重平衡(Rebalance)是消费者消费时发生的一个重要动作，其具体发生在：1、客户端群组内的消费者个数发生增加或减少；2、客户端群组订阅的主题个数发生增加或减少；3、客户端群组所订阅的主题中分区个数增加或减少；在发生了以上情况时，客户端群组需要进行重新分配分区，以确保客户端群组内的分配情况符合预期，避免有消费者消费不到消息，或有分区未被消费等的情况。

发明内容

本公开提供一种消息处理方法、装置、电子设备及存储介质，本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种消息处理方法，包括：

当确定进入重新分配分区状态时，更新客户端群组信息；客户端群组信息包括多个客户端标识；

获取每个客户端标识对应的客户端的当前分区信息；

基于每个客户端的当前分区信息，执行预设分配策略，得到每个客户端的重分配分区信息；

根据每个客户端的重分配分区信息确定多个客户端中的待调整客户端，向待调整客户端发送提示信息；提示信息指示待调整客户端发起同步分区请求；

当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息。

在一些可能的实施例中，获取每个客户端标识对应的客户端的当前分区信息，包括：

向每个客户端标识对应的客户端发送第一心跳包；第一心跳包指示客户端上报客户端的当前分区信息；

接收客户端发送的第一心跳响应包；第一心跳响应包携带有客户端的当前分区信息。

在一些可能的实施例中，根据每个客户端的重分配分区信息确定多个客户端中的待调整客户端，包括：

针对每个客户端：若客户端的重新分配分区信息与客户端的当前分区信息不一致，则将客户端确定为待调整客户端。

在一些可能的实施例中，向待调整客户端发送提示信息，包括：

当接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包；第二心跳响应包携带提示信息。

在一些可能的实施例中，将客户端确定为待调整客户端之后，还包括：

将待调整客户端的状态标记为第一调整状态；

当接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包；第二心跳响应包指示待调整客户端当前处于第一调整状态，需发起重新入组请求；

当接收到待调整客户端发送的重新入组请求时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息；入组请求反馈信息指示待调整客户端当前处于第二调整状态。

在一些可能的实施例中，当接收到待调整客户端发送的重新入组请求时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息，包括：

当接收到待调整客户端发送的重新入组请求时，确定待调整客户端的当前分区信息与重新入组请求中携带的分区信息的匹配程度值；

在匹配程度值大于等于预设值时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息。

在一些可能的实施例中，向待调整客户端发送提示信息之后，当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息之前，还包括：

向待调整客户端发送预警信息；预警信息指示待调整客户端在预设时间内发起同步分区请求。

在一些可能的实施例中，预设分配策略包括循环分配策略、粘性分配策略和范围分配策略中的任一种。

在一些可能的实施例中，方法还包括：

当接收到入组请求时，确定进入重新分配分区状态；入组请求是请求加入客户端群组的新客户端发送的，入组请求携带新客户端的标识；

更新客户端群组信息，包括：

获取当前客户端群组信息；当前客户端群组信息包括当前客户端信息；

将新客户端的标识添加至当前客户端信息中，得到更新后的客户端群组信息；多个客户端标识中包括新客户端的标识。

在一些可能的实施例中，方法还包括：

当客户端群组所订阅的主题的数量增加或者减少时，确定进入重新分配分区状态；

更新客户端群组信息，包括：

获取当前客户端群组信息；当前客户端群组信息包括当前订阅主题信息；

向当前订阅主题信息中新增主题信息，得到更新后的客户端群组信息；

或者；

删除当前订阅主题信息中的主题信息，得到更新后的客户端群组信息。

在一些可能的实施例中，方法还包括：

当客户端群组所订阅主题的分区的数量增加或者减少时，确定进入重新分配分区状态；

更新客户端群组信息，包括：

获取当前客户端群组信息；当前客户端群组信息包括当前订阅主题的分区信息；

向当前订阅主题的分区信息中新增分区信息，得到更新后的客户端群组信息；

或者；

删除当前订阅主题的分区信息中的分区信息，得到更新后的客户端群组信息。

根据本公开实施例的第二方面，提供一种消息处理装置，应用于消息队列系统中的服务端，包括：

更新模块，被配置为执行当确定进入重新分配分区状态时，更新客户端群组信息；客户端群组信息包括多个客户端标识；

获取模块，被配置为执行获取每个客户端标识对应的客户端的当前分区信息；

分配模块，被配置为执行基于每个客户端的当前分区信息，执行预设分配策略，得到每个客户端的重分配分区信息；

发送模块，被配置为执行根据每个客户端的重分配分区信息确定多个客户端中的待调整客户端，向待调整客户端发送提示信息；提示信息指示待调整客户端发起同步分区请求；

发送模块，还被配置为执行当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息。

在一些可能的实施例中，获取模块，被配置为执行向每个客户端标识对应的客户端发送第一心跳包；第一心跳包指示客户端上报客户端的当前分区信息；接收客户端发送的第一心跳响应包；第一心跳响应包携带有客户端的当前分区信息。

在一些可能的实施例中，还包括：

第一确定模块，被配置为执行针对每个客户端：若客户端的重新分配分区信息与客户端的当前分区信息不一致，则将客户端确定为待调整客户端。

在一些可能的实施例中，发送模块，还被配置为执行当接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包；第二心跳响应包携带提示信息。

在一些可能的实施例中，发送模块，还被配置为执行将待调整客户端的状态标记为第一调整状态；当接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包；第二心跳响应包指示待调整客户端当前处于第一调整状态，需发起重新入组请求；当接收到待调整客户端发送的重新入组请求时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息；入组请求反馈信息指示待调整客户端当前处于第二调整状态。

在一些可能的实施例中，发送模块，还被配置为执行当接收到待调整客户端发送的重新入组请求时，确定待调整客户端的当前分区信息与重新入组请求中携带的分区信息的匹配程度值；在匹配程度值大于等于预设值时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息。

在一些可能的实施例中，发送模块，还被配置为执行向待调整客户端发送预警信息；预警信息指示待调整客户端在预设时间内发起同步分区请求。

在一些可能的实施例中，预设分配策略包括循环分配策略、粘性分配策略和范围分配策略中的任一种。

在一些可能的实施例中，还包括：

第二确定模块，被配置为执行当接收到入组请求时，确定进入重新分配分区状态；入组请求是请求加入客户端群组的新客户端发送的，入组请求携带新客户端的标识；

更新模块，还被配置为执行获取当前客户端群组信息；当前客户端群组信息包括当前客户端信息；将新客户端的标识添加至当前客户端信息中，得到更新后的客户端群组信息；多个客户端标识中包括新客户端的标识。

在一些可能的实施例中，还包括：

第二确定模块，被配置为执行当客户端群组所订阅的主题的数量增加或者减少时，确定进入重新分配分区状态；

更新模块，还被配置为执行获取当前客户端群组信息；当前客户端群组信息包括当前订阅主题信息；向当前订阅主题信息中新增主题信息，得到更新后的客户端群组信息；或者；删除当前订阅主题信息中的主题信息，得到更新后的客户端群组信息。

在一些可能的实施例中，还包括：

第二确定模块，被配置为执行当客户端群组所订阅主题的分区的数量增加或者减少时，确定进入重新分配分区状态；

更新模块，还被配置为执行获取当前客户端群组信息；当前客户端群组信息包括当前订阅主题的分区信息；向当前订阅主题的分区信息中新增分区信息，得到更新后的客户端群组信息；或者；删除当前订阅主题的分区信息中的分区信息，得到更新后的客户端群组信息。

根据本公开实施例的第三方面，提供一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，处理器被配置为执行指令，以实现本公开实施例第一方面提供的消息处理方法。

根据本公开实施例的第四方面，提供一种计算机可读存储介质，当计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行本公开实施例第一方面提供的消息处理方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，计算机程序产品包括计算机程序，计算机程序存储在可读存储介质中，计算机设备的至少一个处理器从可读存储介质读取并执行计算机程序，使得计算机设备执行本公开实施例第一方面提供的消息处理方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

通过当确定进入重新分配分区状态时，更新客户端群组信息；客户端群组信息包括多个客户端标识；获取每个客户端标识对应的客户端的当前分区信息；基于每个客户端的当前分区信息，执行预设分配策略，得到每个客户端的重分配分区信息；根据每个客户端的重分配分区信息确定多个客户端中的待调整客户端，向待调整客户端发送提示信息；提示信息指示待调整客户端发起同步分区请求；当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息。本公开基于服务端实现分区的重新分配，可以大幅缩小重分配分区的时间，可以降低重分配分区对客户端的影响。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种应用环境的示意图；

图2是根据一示例性实施例示出的一种消息处理方法的流程图；

图3是根据一示例性实施例示出的一种获取每个客户端标识对应的客户端的当前分区信息方法的流程图；

图4是根据一示例性实施例示出的一种多端交互的示意图；

图5是根据一示例性实施例示出的一种消息处理方法的流程图；

图6是根据一示例性实施例示出的一种消息处理装置的框图；

图7是根据一示例性实施例示出的一种用于消息处理的电子设备的框图。

具体实施方式

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

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

需要说明的是，本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)，均为经用户授权或者经过各方充分授权的信息。

首先，对kafka消息订阅架构中的相关术语进行解释：

Producer:消息生产者，就是向kafka broker发送消息的客户端。

Consumer:消息消费者，向kafka broker拉取消息的客户端。

Consumer Group(CG):消费者组，由多个consumer组成；消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

Broker:一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

Topic:主题，可以理解为一个队列，生产者和消费者面向的都是一个topic。

Partition:分区，为了实现扩展性，一个非常大的topic可以分布到多个broker(即服务器)上，一个topic可以分为多个partition，每个partition是一个有序的队列。

通常，每个Consumer Group都会选择一个broker作为自己的Group Coordinator，Group Coordinator负责监控整个消费者组里的各个分区的心跳，以及判断是否宕机，和开启Rebalance(重平衡)的。相关技术中，在触发Rebalance时，Group Coordinator需要等待所有Consumer客户端发送JoinGroup请求后才进行下一步的分配工作，这对于Consumer较多的消费者组而言可能需要一个较长的等待时间；且若出现消费者假死或网络波动，则可能出现频繁的Rebalance行为。

为了解决现有的Rebalance效率低下的问题，本公开实施例提供一种消息处理方法，基于服务端实现分区的分配，可以大幅缩小rebalance时间，可以降低rebalance对客户端的影响。

请参阅图1，图1是根据一示例性实施例示出的一种消息处理方法的应用环境的示意图，如图1所示，该应用环境可以包括消息队列系统，消息队列系统包括服务端01和多个客户端02，多个客户端02属于同一个消费者组，服务端01用于管理该多个客户端02，并在需要重新分配分区时，对多个分区进行重新分配(即rebalance)。

在一些可能的实施例中，当确定进入重新分配分区状态时，服务端01更新客户端群组信息；客户端群组信息包括多个客户端02的标识；服务端01获取每个客户端标识对应的客户端02的当前分区信息；基于每个客户端02的当前分区信息，执行预设分配策略，得到每个客户端02的重分配分区信息；根据每个客户端02的重分配分区信息确定多个客户端02中的待调整客户端，向待调整客户端发送提示信息；提示信息指示待调整客户端发起同步分区请求；当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息。

在一些可能的实施例中，服务端01可以包括是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(ContentDelivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。服务器上运行的操作系统可以包括但不限于安卓系统、IOS系统、linux、windows、Unix等。

在一些可能的实施例中，上述的客户端02可以包括但不限于智能手机、台式计算机、平板电脑、笔记本电脑、智能音箱、数字助理、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、智能可穿戴设备等类型的客户端。也可以为运行于上述客户端的软体，例如应用程序、小程序等。可选的，客户端上运行的操作系统可以包括但不限于安卓系统、IOS系统、linux、windows、Unix等。

此外，需要说明的是，图1所示的仅仅是本公开提供的消息处理方法的一种应用环境，在实际应用中，还可以包括其他应用环境。

图2是根据一示例性实施例示出的一种消息处理方法的流程图，如图2所示，消息处理方法可以应用于消息队列系统中的服务端，包括以下步骤：

在步骤S201中，当确定进入重新分配分区状态时，更新客户端群组信息；客户端群组信息包括多个客户端标识。

本公开实施例中，在消息队列系统中，如Kafka，通过多个分区存储消息；消息队列系统中的服务端负责客户端群组的管理，在客户端群组所订阅的主题、分区或群组成员发生变更时，服务端通过重新分配分区来维持消费平衡。服务端可以通过确定是否发生上述变更事件，来确定是否进入重新分配分区状态。

在一些可能的实施例中，消息处理方法还包括：当接收到入组请求(JoinGroup)时，确定进入重新分配分区状态；入组请求是请求加入客户端群组的新客户端发送的，入组请求携带新客户端的标识；

相应的，上述更新客户端群组信息，可以包括：获取当前客户端群组信息；当前客户端群组信息包括当前客户端信息；将新客户端的标识添加至当前客户端信息中，得到更新后的客户端群组信息；多个客户端标识中包括新客户端的标识。

比如，当前客户端群组信息中当前客户端信息包括两个客户端标识：C0和C1，此时，接收到来自新客户端发送的入组请求，该入组请求携带新客户端的标识C2，该入组请求指示新客户端想要加入当前客户端群组，服务端若同意其入组请求，则将该新客户端的标识添加至当前客户端信息，从而，更新后的客户端群组信息中多个客户端标识包括：C0、C1和C2。

在一些可能的实施例中，服务端若确定客户端群组中的客户端离开群组时，确定进入重新分配分区状态。

在一些可能的实施例中，消息处理方法还包括：当客户端群组所订阅的主题的数量增加或者减少时，确定进入重新分配分区状态；

相应的，上述更新客户端群组信息，可以包括：获取当前客户端群组信息；当前客户端群组信息包括当前订阅主题信息；向当前订阅主题信息中新增主题信息，得到更新后的客户端群组信息；或者；删除当前订阅主题信息中的主题信息，得到更新后的客户端群组信息。

比如，当前客户端群组信息包括三个客户端标识：C0、C1和C2，该客户端群组的当前订阅主题信息包括4个主题：t0、t1、t2、t3；服务端若确定存在新增主题行为，则向该当前订阅主题信息中添加新的主题信息；同样地，服务端若确定存在删除主题行为，则从该当前订阅的4个主题中删除对应的主题，得到更新后的客户端群组信息。

在一些可能的实施例中，消息处理方法还包括：当客户端群组所订阅主题的分区的数量增加或者减少时，确定进入重新分配分区状态；

相应的，上述更新客户端群组信息，可以包括：获取当前客户端群组信息；当前客户端群组信息包括当前订阅主题的分区信息；向当前订阅主题的分区信息中新增分区信息，得到更新后的客户端群组信息；或者；删除当前订阅主题的分区信息中的分区信息，得到更新后的客户端群组信息。

比如，当前客户端群组信息包括三个客户端标识：C0、C1和C2，该客户端群组的当前订阅主题信息包括4个主题：t0、t1、t2、t3，并且每个主题有2个分区，也就是说整个客户端群组订阅了t0p0、t0p1、t1p0、t1p1、t2p0、t2p1、t3p0、t3p1这8个分区。服务端若确定存在新增分区行为，则向该当前订阅主题的分区信息中添加新的分区信息；同样地，服务端若确定存在删除分区行为，则从该8个分区中删除对应的分区，得到更新后的客户端群组信息。

在一些可能的实施例中，若变更事件触发了传统的Rebalance协议，则可以通过以下步骤，切换至本公开实施例的Server Rebalance协议，如此，可以在下一次确定进入重新分配分区状态时，执行后续步骤S203～S209，切换步骤可以包括：

在服务端处理当前重新分配分区任务时，确定是否满足切换条件；在满足切换条件时，统计每个客户端标识对应的客户端是否已发送三轮及三轮以上心跳包；在确定每个客户端均已发送三轮及三轮以上心跳包时，且切换至Server Rebalance协议。

在一个具体的实施例中，切换条件包括：前一次Rebalance已结束，服务端开启了Server Rebalance功能，客户端未自定义分区器(PartitionAssignor)；如果满足切换条件，则调用进行切换前的准备，例如初始化心跳计时器等；服务器按当前分配分区方案继续处理心跳，同时判断处理过程中是否再次触发Rebalance，以及客户端群组内的每个客户端是否都发送了三轮及三轮以上心跳包；若服务端判断处理过程中没有再次触发Rebalance，以及客户端群组内的每个客户端都发送了三轮及三轮以上心跳包，则初始化客户端群组的元数据信息，并正式切换为至Server Rebalance协议。

上述实施例中，可以兼容采用传统Rebalance的服务端，根据实际需求随时可以从传统rebalance协议切换至server rebalance协议，可以提高服务端处理消息的灵活性。

在步骤S203中，获取每个客户端标识对应的客户端的当前分区信息。

本公开实施例中，服务端获取每个客户端标识对应的客户端的当前分区信息，以在服务端完成分区的分配。

在一些可能的实施例中，上述获取每个客户端标识对应的客户端的当前分区信息，可以包括如图3所示的以下步骤：

在步骤S301中，向每个客户端标识对应的客户端发送第一心跳包；第一心跳包指示客户端上报客户端的当前分区信息。

在步骤S303中，接收客户端发送的第一心跳响应包；第一心跳响应包携带有客户端的当前分区信息。

下面通过一个具体的例子，对服务端重新分配分区的过程进行说明。假设该例子中，是因为新客户端的加入，导致服务端需要重新分配分区，在重新分配分区的过程中，客户端群组中原客户端与服务端之间的交互是相同的，因此，仅用一个原客户端示例性的展示其与服务端之间的交互。

请参阅图4，图4是根据一示例性实施例示出的一种多端交互的示意图。如图4所示，假设原客户端群组中包括三个客户端：C0、C1和C2，服务端在确定客户端C0、C1和C2均发送了三轮心跳后，切换至服务端rebalance协议，图中仅以客户端C0作为示例；服务端在接收到新客户端(C3)发送的入组请求后，更新客户端群组信息，即新增该新客户端的标识；然后，服务端向客户端C0发送第一心跳包，接收客户端C0返回的第一心跳响应包，该第一心跳响应包中携带有客户端C0的当前分区信息，比如[t0p0]；同理，服务器获取的客户端C1的当前分区信息假设为[t1p0],客户端C2的当前分区信息假设为[t1p1、t2p0、t2p1、t2p2]；也就是说，原客户端群组共订阅了3个主题：t0、t1、t2，这3个主题分别有1、2、3个分区；同样的，服务端也向客户端发送第一心跳包，以获得客户端C3想要订阅的主题和分区；在客户端C3加入后，服务端基于各客户端的当前分区信息，向4个客户端重新分配这6个分区，以尽量保证每个客户端都有分区消费信息；

可选的，由于每次客户端群组进行rebalance之后，群组的generation id都会加1，表示客户端群组进入到了一个新的版本，因此，在服务端向客户端C0发送第一心跳包时，同时可以携带新的generation id，图中示例性的用generation 2来表示；且在对新客户端C3的入组请求响应中也携带generation 2；服务端在后续分配过程中，对于接受到的消息，需要检查发送该消息的客户端的generation id是否与该新的generation id一致，以确保当前分配过程的顺利执行，进而保证当前客户端群组中各客户端可以获得新的分区。

在步骤S205中，基于每个客户端的当前分区信息，执行预设分配策略，得到每个客户端的重分配分区信息。

本公开实施例中，服务端根据每个客户端的当前分区信息，执行预设分配策略，对分区进行重新分配，得到每个客户端的重分配分区信息。

在一些可能的实施例中，预设分配策略包括循环分配策略、粘性分配策略和范围分配策略中的任一种。优选的，预设分配策略采用粘性分配策略(StickyAssignor)，它主要有两个目的：分区的分配要尽可能的均匀；分区的分配尽可能的与上次分配的保持相同。当两者发生冲突时，第一个目标优先于第二个目标。使用粘性分配策略的好处是，让分配策略具备一定的“粘性”，尽可能地让前后两次分配相同，进而减少服务端资源的损耗以及其它异常情况的发生。

在一个具体的例子中，如前文所述，服务端需要将6个分区重新向当前客户端群组中4个客户端进行分配，实际应用中，可以采取粘性分配策略得到分区结果。

在步骤S207中，根据每个客户端的重分配分区信息确定多个客户端中的待调整客户端，向待调整客户端发送提示信息；提示信息指示待调整客户端发起同步分区请求。

本公开实施例中，服务端可以根据每个客户端的重分配分区信息，确定多个客户端中的待调整客户端，待调整客户端指的是其当前分区信息发生了变化，需要调整至服务器为其重新分配的分区，重新分配的分区可以通过发起同步分区请求(SyncGroup)来获取。

在一些可能的实施例中，上述根据每个客户端的重分配分区信息确定多个客户端中的待调整客户端，可以包括：针对每个客户端：若客户端的重新分配分区信息与客户端的当前分区信息不一致，则将客户端确定为待调整客户端。

在一个具体的例子中，如前文所述，服务端使用粘性分配策略得到客户端(C0～C3)的重新分配分区信息，假设客户端C0的重新分配分区为[t0p0、t2p2]，则确定客户端C0为待调整客户端；假设客户端C1的重新分配分区为[t1p0]，则其分区未发生变化，其并不需要进行调整；同时，客户端C3是第一次被分配分区，其默认为待调整客户端。

在一些可能的实施例中，上述向待调整客户端发送提示信息，可以包括：当接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包；第二心跳响应包携带提示信息。

由于客户端会定时向服务端发送第二心跳包，则服务端可以在接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包，第二心跳响应包指示待调整客户端发起同步分区请求。

在一些可能的实施例中，在上述将客户端确定为待调整客户端之后，消息处理方法还可以包括如图5所示的以下步骤：

在步骤S501中，将待调整客户端的状态标记为第一调整状态。

在步骤S503中，当接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包；第二心跳响应包指示待调整客户端当前处于第一调整状态，需发起重新入组请求。

如图4所示，将客户端C0和C3的状态标记为第一调整状态(PreparedRebalance)；并在客户端C0和C3各自的第二心跳响应包中指示当前处于PreparedRebalance，需发起重新入组请求。

在步骤S505中，当接收到待调整客户端发送的重新入组请求时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息；入组请求反馈信息指示待调整客户端当前处于第二调整状态。

如图4所示，服务端在接收到客户端C0和C3各自发送的重新入组请求时，将其状态从PreparedRebalance调整为AwaitingSync。

在一些可能的实施例中，上述当接收到待调整客户端发送的重新入组请求时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息，可以包括以下步骤：

当接收到待调整客户端发送的重新入组请求时，确定待调整客户端的当前分区信息与重新入组请求中携带的分区信息的匹配程度值；

在匹配程度值大于等于预设值时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息。

其中，预设值可以是1。一般情况下，待调整客户端发送的重新入组请求中携带的订阅主题和分区信息与步骤S203中服务端获取的当前分区信息是一致的，此时，待调整客户端的当前分区信息与重新入组请求中携带的分区信息的匹配程度值为1，则可以执行将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息的步骤，直至完成当前分配过程；但考虑到特殊情况下，待调整客户端的订阅主题或分区发生新的变化，则，当前分配过程停止，回到步骤S201重新触发一轮新的重分配过程。

在步骤S209中，当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息。

本公开实施例中，服务端在接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息，以使得待调整客户端可以从重分配分区拉取消息。

在一些可能的实施例中，上述向待调整客户端发送提示信息之后，当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息之前，消息处理方法还包括：向待调整客户端发送预警信息；预警信息指示待调整客户端在预设时间内发起同步分区请求。

其中，预警信息可以以心跳包形式发送。如图4所示，服务端在向客户端C0和C3分别发送各自的入组请求响应后，对各客户端单独调度了一个心跳，并指示客户端C0和C3在预设时间内发起同步分区请求。

本公开实施例提供的一种消息处理方法，基于服务端完成rebalance过程，无需客户端群组内所有客户端都确认即可进行下一步具体分区方案的分配，可以大幅减少整体Rebalance的耗时，将客户端耗时从最长的数十秒提升至五秒之内，普遍有十倍以上的性能提升；且通过单独通知客户端重分配分区信息，使得客户端感知减小，对于单个客户端而言，原先普遍耗时2-3s进行Rebalance操作，使用本公开实施例的方案后，对于客户端群组内大多无需调整原有分区方案的客户端而言，对整个Rebalance的感知耗时仅在2-3ms左右，极大减少了Rebalance对于客户端的影响。

图6是根据一示例性实施例示出的一种消息处理装置框图，消息处理装置应用于消息队列系统中的服务端，参照图6，该装置包括更新模块601、获取模块602、分配模块603和发送模块604；

更新模块601，被配置为执行当确定进入重新分配分区状态时，更新客户端群组信息；客户端群组信息包括多个客户端标识；

获取模块602，被配置为执行获取每个客户端标识对应的客户端的当前分区信息；

分配模块603，被配置为执行基于每个客户端的当前分区信息，执行预设分配策略，得到每个客户端的重分配分区信息；

发送模块604，被配置为执行根据每个客户端的重分配分区信息确定多个客户端中的待调整客户端，向待调整客户端发送提示信息；提示信息指示待调整客户端发起同步分区请求；

发送模块604，还被配置为执行当接收到待调整客户端的同步分区请求时，向待调整客户端发送对应的重分配分区信息。

在一些可能的实施例中，获取模块602，被配置为执行向每个客户端标识对应的客户端发送第一心跳包；第一心跳包指示客户端上报客户端的当前分区信息；接收客户端发送的第一心跳响应包；第一心跳响应包携带有客户端的当前分区信息。

在一些可能的实施例中，还包括：

第一确定模块，被配置为执行针对每个客户端：若客户端的重新分配分区信息与客户端的当前分区信息不一致，则将客户端确定为待调整客户端。

在一些可能的实施例中，发送模块604，还被配置为执行当接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包；第二心跳响应包携带提示信息。

在一些可能的实施例中，发送模块604，还被配置为执行将待调整客户端的状态标记为第一调整状态；当接收到待调整客户端发送的第二心跳包时，向待调整客户端发送第二心跳响应包；第二心跳响应包指示待调整客户端当前处于第一调整状态，需发起重新入组请求；当接收到待调整客户端发送的重新入组请求时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息；入组请求反馈信息指示待调整客户端当前处于第二调整状态。

在一些可能的实施例中，发送模块604，还被配置为执行当接收到待调整客户端发送的重新入组请求时，确定待调整客户端的当前分区信息与重新入组请求中携带的分区信息的匹配程度值；在匹配程度值大于等于预设值时，将第一调整状态更新为第二调整状态，向待调整客户端发送入组请求反馈信息。

在一些可能的实施例中，发送模块604，还被配置为执行向待调整客户端发送预警信息；预警信息指示待调整客户端在预设时间内发起同步分区请求。

在一些可能的实施例中，预设分配策略包括循环分配策略、粘性分配策略和范围分配策略中的任一种。

在一些可能的实施例中，还包括：

第二确定模块，被配置为执行当接收到入组请求时，确定进入重新分配分区状态；入组请求是请求加入客户端群组的新客户端发送的，入组请求携带新客户端的标识；

更新模块601，还被配置为执行获取当前客户端群组信息；当前客户端群组信息包括当前客户端信息；将新客户端的标识添加至当前客户端信息中，得到更新后的客户端群组信息；多个客户端标识中包括新客户端的标识。

在一些可能的实施例中，还包括：

第二确定模块，被配置为执行当客户端群组所订阅的主题的数量增加或者减少时，确定进入重新分配分区状态；

更新模块601，还被配置为执行获取当前客户端群组信息；当前客户端群组信息包括当前订阅主题信息；向当前订阅主题信息中新增主题信息，得到更新后的客户端群组信息；或者；删除当前订阅主题信息中的主题信息，得到更新后的客户端群组信息。

在一些可能的实施例中，还包括：

第二确定模块，被配置为执行当客户端群组所订阅主题的分区的数量增加或者减少时，确定进入重新分配分区状态；

更新模块601，还被配置为执行获取当前客户端群组信息；当前客户端群组信息包括当前订阅主题的分区信息；向当前订阅主题的分区信息中新增分区信息，得到更新后的客户端群组信息；或者；删除当前订阅主题的分区信息中的分区信息，得到更新后的客户端群组信息。

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

图7是根据一示例性实施例示出的一种用于消息处理的电子设备的框图。

该电子设备可以是服务器，还可以是终端设备，其内部结构图可以如图7所示。该电子设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种消息处理方法。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本公开方案相关的部分结构的框图，并不构成对本公开方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在示例性实施例中，还提供了一种电子设备，包括：处理器；用于存储该处理器可执行指令的存储器；其中，该处理器被配置为执行该指令，以实现如本公开实施例中的消息处理方法。

在示例性实施例中，还提供了一种计算机可读存储介质，当该计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行本公开实施例中的消息处理方法。

在示例性实施例中，还提供了一种计算机程序产品，计算机程序产品包括计算机程序，计算机程序存储在可读存储介质中，计算机设备的至少一个处理器从可读存储介质读取并执行计算机程序，使得计算机设备执行本公开实施例的消息处理方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

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

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

Claims (10)

1.一种消息处理方法，其特征在于，应用于消息队列系统中的服务端，包括：

当确定进入重新分配分区状态时，更新客户端群组信息；所述客户端群组信息包括多个客户端标识；

获取每个客户端标识对应的客户端的当前分区信息；

基于所述每个客户端的当前分区信息，执行预设分配策略，得到所述每个客户端的重分配分区信息；

根据所述每个客户端的重分配分区信息确定多个客户端中的待调整客户端，向所述待调整客户端发送提示信息；所述提示信息指示所述待调整客户端发起同步分区请求；

当接收到所述待调整客户端的同步分区请求时，向所述待调整客户端发送对应的重分配分区信息。

2.根据权利要求1所述的消息处理方法，其特征在于，所述获取每个客户端标识对应的客户端的当前分区信息，包括：

向所述每个客户端标识对应的客户端发送第一心跳包；所述第一心跳包指示所述客户端上报所述客户端的当前分区信息；

接收所述客户端发送的第一心跳响应包；所述第一心跳响应包携带有所述客户端的当前分区信息。

3.根据权利要求1所述的消息处理方法，其特征在于，所述根据所述每个客户端的重分配分区信息确定多个客户端中的待调整客户端，包括：

针对所述每个客户端：若所述客户端的重新分配分区信息与所述客户端的当前分区信息不一致，则将所述客户端确定为所述待调整客户端。

4.根据权利要求3所述的消息处理方法，其特征在于，所述向所述待调整客户端发送提示信息，包括：

当接收到所述待调整客户端发送的第二心跳包时，向所述待调整客户端发送第二心跳响应包；所述第二心跳响应包携带所述提示信息。

5.根据权利要求3所述的消息处理方法，其特征在于，所述将所述客户端确定为所述待调整客户端之后，还包括：

将所述待调整客户端的状态标记为第一调整状态；

当接收到所述待调整客户端发送的第二心跳包时，向所述待调整客户端发送第二心跳响应包；所述第二心跳响应包指示所述待调整客户端当前处于所述第一调整状态，需发起重新入组请求；

当接收到所述待调整客户端发送的重新入组请求时，将所述第一调整状态更新为第二调整状态，向所述待调整客户端发送入组请求反馈信息；所述入组请求反馈信息指示所述待调整客户端当前处于所述第二调整状态。

6.根据权利要求5所述的消息处理方法，其特征在于，所述当接收到所述待调整客户端发送的重新入组请求时，将所述第一调整状态更新为第二调整状态，向所述待调整客户端发送入组请求反馈信息，包括：

当接收到所述待调整客户端发送的重新入组请求时，确定所述待调整客户端的当前分区信息与所述重新入组请求中携带的分区信息的匹配程度值；

在所述匹配程度值大于等于预设值时，将所述第一调整状态更新为第二调整状态，向所述待调整客户端发送入组请求反馈信息。

7.一种消息处理装置，其特征在于，应用于消息队列系统中的服务端，包括：

更新模块，被配置为执行当确定进入重新分配分区状态时，更新客户端群组信息；所述客户端群组信息包括多个客户端标识；

获取模块，被配置为执行获取每个客户端标识对应的客户端的当前分区信息；

分配模块，被配置为执行基于所述每个客户端的当前分区信息，执行预设分配策略，得到所述每个客户端的重分配分区信息；

发送模块，被配置为执行根据所述每个客户端的重分配分区信息确定多个客户端中的待调整客户端，向所述待调整客户端发送提示信息；所述提示信息指示所述待调整客户端发起同步分区请求；

所述发送模块，还被配置为执行当接收到所述待调整客户端的同步分区请求时，向所述待调整客户端发送对应的重分配分区信息。

8.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至6中任一项所述的消息处理方法。

9.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至6中任一项所述的消息处理方法。

10.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，所述计算机程序存储在可读存储介质中，计算机设备的至少一个处理器从所述可读存储介质读取并执行所述计算机程序，使得所述计算机设备执行如权利要求1至6中任一项所述的消息处理方法。

Images