CN116132289A - 信息配置方法、装置、设备和介质 - Google Patents

Abstract

本申请提供一种信息配置方法、装置、设备和介质，该方法包括：检测分布式发布订阅消息系统集群的第一目录是否存在新增节点，第一目录还包括有初始节点，初始节点为至少一个；若第一目录存在新增节点，则获取初始节点的当前配置信息，初始节点的当前配置信息位于分布式发布订阅消息系统集群的第二目录中，初始节点的当前配置信息为在新增节点之前对初始节点的配置信息进行动态调整后的信息；根据初始节点的当前配置信息，对新增节点的当前配置信息进行更新，新增节点的当前配置信息为预设初始配置信息，新增节点更新后的配置信息对应的存储于第二目录中。该技术可以实现分布式发布订阅消息系统集群在扩容时，自动配置新增节点的配置信息。

Description

信息配置方法、装置、设备和介质

技术领域

本申请涉及分布式系统技术领域，尤其涉及一种信息配置方法、装置、设备和介质。

背景技术

随着互联网技术的高速发展，终端设备的应用间通常需要使用消息队列中间件实现消息传递，消息队列中间件集群通常包括有多个节点，每个节点都需要进行信息配置，例如配置生产消息大小、网络操作线程等。如果消息队列中间件集群需要新增节点，则也需要再对该新增节点进行信息配置。

现有技术中，在消息队列中间件集群新增节点时，通常都是由技术开发人员自己手动配置新增节点的配置信息。

但是，现有技术的这种方式由于是人工操作，非常的费时费力，效率低。

发明内容

本申请提供一种信息配置方法、装置、设备和介质，用于解决现有消息队列中间件集群在扩容时，新增节点的配置信息配置效率低的问题。

第一方面，本申请实施例提供一种信息配置方法，包括：

检测分布式发布订阅消息系统集群的第一目录是否存在新增节点，所述第一目录还包括有初始节点，所述初始节点为至少一个；

若所述第一目录存在新增节点，则获取所述初始节点的当前配置信息，所述初始节点的当前配置信息位于所述分布式发布订阅消息系统集群的第二目录中，所述初始节点的当前配置信息为在新增节点之前对所述初始节点的配置信息进行动态调整后的信息；

根据所述初始节点的当前配置信息，对所述新增节点的当前配置信息进行更新，所述新增节点的当前配置信息为预设初始配置信息，所述新增节点更新后的配置信息对应的存储于所述第二目录中。

第二方面，本申请实施例提供一种信息配置装置，包括：

节点检测模块，用于检测分布式发布订阅消息系统集群的第一目录是否存在新增节点，所述第一目录还包括有初始节点，所述初始节点为至少一个；

信息获取模块，用于若所述第一目录存在新增节点，则获取所述初始节点的当前配置信息，所述初始节点的当前配置信息位于所述分布式发布订阅消息系统集群的第二目录中，所述初始节点的当前配置信息为在新增节点之前对所述初始节点的配置信息进行动态调整后的信息；

信息配置模块，用于根据所述初始节点的当前配置信息，对所述新增节点的当前配置信息进行更新，所述新增节点的当前配置信息为预设初始配置信息，所述新增节点更新后的配置信息对应的存储于所述第二目录中。

第三方面，本申请实施例提供一种计算机设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现上述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现上述的方法。

本申请实施例提供的信息配置方法、装置、设备和介质，通过监听是否存在新增节点，当出现新增节点时，可以读取其它节点的配置内容，然后基于这些配置内容，自动完成对新增节点的配置，不需要人工介入，提高配置效率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理；

图1为本申请实施例提供的分布式发布订阅消息系统集群的场景示意图；

图2为本申请实施例提供的信息配置方法的流程示意图；

图3为本申请实施例提供的Kafka集群的框架示意图；

图4为本申请实施例提供的信息配置的框架流程示意图；

图5为本申请另一实施例提供的信息配置方法的流程示意图；

图6为本申请又一实施例提供的信息配置方法的流程示意图；

图7为本申请实施例提供的信息配置装置的结构示意图；

图8为本申请实施例提供的计算机设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

首先对本申请所涉及的名词进行解释：

分布式发布订阅消息系统：它可以处理消息消费者在网站中的所有动作流数据，例如Kafka就是一种高吞吐量的分布式发布订阅消息系统，其作为消息队列中间件，支持以发布/订阅的方式在应用间传递消息。

动物园管理员(ZooKeeper)：是指一个开放源码的分布式应用程序协调服务，在本申请中其是存储kafka相关的元数据信息以及配置信息的组件。

图1为本申请实施例提供的分布式发布订阅消息系统集群的场景示意图，如图1所示，以Kafka集群作为分布式发布订阅消息系统集群为例，Kafka包括有多个节点brokers(例如节点A-节点X)，这些节点brokers可以视为Kafka集群包括含的一个或多个服务器，节点brokers在Zookeeper上进行注册，同时ZooKeeper存储这些节点brokers的元数据信息以及配置信息等，通过Kafka集群的这些节点brokers实现将消息生产者(Producers)的消息传递至消息消费者(consumers)。其中，消息生产者和消息消费者均可以是终端设备中的应用。

随着互联网的高速发展，各类终端设备中的应用也在不断的上新迭代中，而为了实现这些应用之间的通信，可以使用kafka来实现应用间的异步消息传递。在kafka的使用期间，会涉存在有kafka集群中节点的配置项内容变更的需求，以此来适应快速迭代上新的各类应用的各种使用需求。具体的，kafka可动态变更其节点的部分配置项内容，例如可动态变更节点的配置项内容有生产消息的大小(message.max.bytes)和网络操作线程(num.network.threads)等，kafka节点中的这类配置项内容变更后无需重新启动Kafka集群，就可以直接生效、作用到Kafka集群。但是动态变更之后的配置项内容只会保留在当前Kafka集群下的节点组，而当对Kafka集群进行节点扩容时，之前动态配置的配置项内容并不会重新设置到扩容的新增节点上面，从而导致在扩容后，Kafka集群下面的各个节点的配置信息出现不一致的情况，如此可能会导致Kafka集群在某些特定的情况下出现无法服务的情况，最终造成应用无法正常使用kafka集群。针对上述问题，目前的处理方式主要包括有如下两种：(1)通过人工自主的逐一确认每个节点的动态配置项内容，从而找出动态配置项内容不一致的节点，并手动进行调整以保持各个节点的动态配置内容一致。这种方式严重依赖运维人员，需要费时费力的找出动态配置项内容不一致的节点，效率低。(2)直接更新集群的配置文件，然后重启集群，让其所有的节点的动态配置项内容实现配置一致。这种方式是需要重启集群来达成配置一致，无法在kafka集群使用过程中进行配置变更。

针对上述问题，本申请实施例提供的信息配置方法、装置、设备和介质，为了提高对Kafka集群中新增节点broker的内容配置效率，需要实现新增节点broker的内容自动化配置。具体的，通过设置监听组件监听Zookeeper存储的节点列表brokers/id的变更，当节点列表brokers/id中出现新增节点broker时，可以读取Zookeeper的config/brokers下存储的所有节点的配置内容，然后基于这些配置内容，自动完成对新增节点broker的配置，不需要人工介入，提高配置效率。

下面，通过具体实施例对本申请的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请实施例提供的信息配置方法的流程示意图，该方法可以应用于服务器，且该服务器搭载有监听组件，通过监听组件来执行本方法步骤。

如图2所示，该方法具体可以包括如下步骤：

步骤S201，检测分布式发布订阅消息系统集群的第一目录是否存在新增节点，第一目录还包括有初始节点，初始节点为至少一个。

在本实施例中，以Kafka集群作为分布式发布订阅消息系统集群为例，Kafka集群包括有至少一个初始节点，初始节点需要在Zookeeper上完成注册，同时Zookeeper上存储有这些初始节点的相关信息，例如Zookeeper的文件目录brokers/ids(即第一目录)下存储有当前Kafka集群下所有的节点broker的id。Zookeeper的文件目录config/brokers下存储有当前Kafka集群中通过动态配置设置的broker列表及其对应的配置项内容。

其中，通过监听组件对Zookeeper的文件目录brokers/ids进行实时监听，如果当前Kafka集群存在新增节点，则文件目录brokers/ids会发生信息变更。

示例性的，图3为本申请实施例提供的Kafka集群的框架示意图，如图3所示，Kafka集群中包括有三个初始节点(即图3中的节点A、节点B和节点C)，三个初始节点的id记录在动物管理员ZooKeeper的第一目录brokers/ids下，三个初始节点对应的配置项内容则记录在动物管理员ZooKeeper的第二目录config/brokers下。当运维人员在Kafka集群中新增节点时，需要先在ZooKeeper上注册，此时ZooKeeper的第一目录brokers/ids下出现一个新增节点(即图3中的节点D)，但是在新增节点时，之前对节点A、节点B和节点C动态设置的配置项内容不会重新设置到新增节点D上，即ZooKeeper的第二目录config/brokers下不会作为新增节点D的配置信息，新增节点D还是用的初始配置信息(初始配置信息即未动态设置过的配置项内容)，为预设初始配置信息。

在本实施例中，以Kafka集群包括有三个初始节点(例如节点A、节点B和节点C)为例，在没有进行动态调整之前，三个初始节点的配置信息可以是预设初始配置信息(预设初始配置信息可以存储在一个备份目录下，其不会发生变更)，随后工作人员可以发起配置调整请求，动态调整每个初始节点的配置信息，进行动态调整完之后的初始节点的当前配置信息不再与原预设初始配置信息相同，并且也不会存储到备份目录下，这就导致了在新增节点时，新增节点只能够使用备份目录下的预设初始配置信息，从而造成了新增节点与初始节点的配置信息不一致的情况，由此就需要对新增节点的配置信息进行重新配置。

步骤S202，若第一目录存在新增节点，则获取初始节点的当前配置信息，初始节点的当前配置信息位于分布式发布订阅消息系统集群的第二目录中，初始节点的当前配置信息为在新增节点之前对初始节点的配置信息进行动态调整后的信息。

在本实施例中，初始节点的当前配置信息是指上文提到的初始节点的配置项内容，其中包括有在Kafka集群启动之后动态调整的配置信息。例如在未发生动态调整之前，初始节点的配置信息为预设初始配置信息，具体示例为“num.network.threads”：“X1”，“message.max.bytes”：“X2”，在Kafka集群启动之后，对“message.max.bytes”进行了动态调整，动态调整之后的当前配置信息为“num.network.threads”：“X1”，“message.max.bytes”："10000120"。

其中，当Kafka集群出现新增节点(例如图3中的节点D)时，新增节点使用的是备份目录下的预设初始配置信息，初始节点中动态调整后的当前配置信息不会自动重新设置到新增节点上面，从而导致了新增节点的配置信息实际上是与初始节点A、初始节点B和初始节点C的配置信息不一致。如此就可能导致Kafka集群在某些特定的情况下出现无法服务的情况，从而导致应用无法正常使用kafka集群。

步骤S203，根据初始节点的当前配置信息，对新增节点的当前配置信息进行更新，新增节点的当前配置信息为预设初始配置信息，新增节点更新后的配置信息对应的存储于第二目录中。

在本实施例中，当新增节点之后，由于备份目录下备份的是预设初始配置信息，导致新增节点的当前配置信息会被自动配置为该预设初始配置信息，不会与初始节点的当前配置信息相同。

在本实施例中，在正常情况下，各个初始节点的配置信息通常是一致的，即任一个初始节点的配置信息均可以作为该新增节点的当前配置信息。在另一些非正常情况下，如果在多个初始节点中存在有配置信息不一致的初始节点，则这些初始节点可以称为异常节点，异常节点的配置信息不能够作为该新增节点的配置信息，非异常节点的配置信息才可以作为该新增节点的配置信息。

示例性的，以初始节点包括broker1至broker3为例，如果broker1的配置信息与broker2、broker3的配置信息均不一致，且broker2和broker3的配置信息一致，则broker1为异常节点，broker2和broker3为非异常节点。

需要说明的，在本实施例中，新增节点的当前配置信息更新完毕之后，新增节点就可以被视为初始节点，即初始节点的数量是可以发生变化的。示例性的，以在不同时期分别新增了第一新增节点和第二新增节点为例，第一新增节点的当前配置信息更新完毕之后，可以视为初始节点，在后续新增第二新增节点时，第一新增节点更新完毕之后的当前配置信息可以视为初始节点的当前配置信息。

本申请实施例通过监听Zookeeper的brokers/id目录下的节点列表，当出现新增broker节点时，可以读取Zookeeper的config/brokers下所有节点的配置内容，然后基于这些配置内容，自动完成对新增节点的配置，不需要人工介入，提高配置效率。

进一步的，在一些实施例中，上述步骤S201具体可以通过如下步骤实现：获取第一目录中包含的所有节点的总数量；确定总数量与初始节点的数量是否相同；若不相同，则确定分布式发布订阅消息系统集群存在新增节点。

在本实施例中，以Kafka集群作为分布式发布订阅消息系统集群为例，Kafka集群中每个节点都会在Zookeeper中注册，Zookeeper的brokers/ids目录下会存储一个节点列表，该节点列表中包括有每一个注册完成的节点的id。

示例性的，以Kafka集群包括有broker1、broker2和broker3三个初始节点为例，则在Zookeeper的brokers/ids目录下的节点列表中，包括有broker1、broker2和broker3三个初始节点的id。当用户发起集群扩容请求时，Kafka集群响应于用户发起的集群扩容请求，会在Zookeeper的brokers/ids下面的节点列表中创建出一个新增节点broker4，表示集群增加了一个broker实例，如此就导致了初始节点的数量与第一目录中包含的所有节点的总数量不相同。

其中，在用户发起集群扩容请求之前，用户还可以发起配置调整请求，Kafka集群响应于用户发起的配置调整请求，会在Zookeeper的config/brokers目标下面写入对应的动态变更后的配置信息，即动态的调整broker1、broker2和broker3这三个初始节点的配置信息。而如果在用户发起配置调整请求之后，又发起了集群扩容请求，则新增节点broker4的配置信息使用的还是备份目录下的预设初始配置信息，不会与发生了配置调整的broker1、broker2和broker3这三个初始节点的配置信息保持一致。如此就容易造成Kafka集群在某些特定的情况下出现无法服务的情况，从而导致应用无法正常使用Kafka集群。

图4为本申请实施例提供的信息配置的框架流程示意图，如图4所示，其包括有步骤S401至步骤S401。其利用监听组件实现对新增节点的检测以及新增节点的信息配置。其中，步骤S401，确定节点列表是否变更；步骤S402，若节点列表发生变更，则读取第二目录下所有节点的配置信息。步骤S403，从所有节点的配置信息中找到最新的配置信息，作为新增节点的配置信息。步骤S404，若节点列表未变更，则忽略。

在本实施例中，第一目录记录的是kafka的所有节点(例如kafka有节点A、节点B和节点C)；第二目录记录的是kafka的每个节点对应的配置信息；备份目录可以备份一个最初始V1版本的预设初始配置信息，在没有发生配置信息的动态调整之前，在第二目录中记录的每个节点(包括图4中节点A、节点B和节点C)的配置信息都可以是V1版本的预设初始配置信息。如果工作人员发起了动态配置调整请求，则第二目录中的节点broker1-3的配置信息可能会更新为当前配置信息，即v2版本的配置信息，但是备份目录中备份的还是最原始V1版本的预设初始配置信息，这个最原始V1版本相当于是一个基础版本，不会随便变更；然后，在kafka扩容新增节点broker4之后，现有技术中broker4只会从备份目录中找到最原始的V1版本的预设初始配置信息，并配置到第二目录的broker4下，作为节点broker4的当前配置信息，这就导致了第二目录中broker4的当前配置信息与动态调整后的broker1-3的当前配置信息不相同；故而需要监听组件来监听新增节点，并实现第二目录中kafka所有节点的配置信息的一致性。

本申请实施例通过增加监听组件对节点列表的变更进行实时监听，当Kafka集群存在集群扩容时，就会触发节点列表中节点数量的变更，从而可以自动触发后续为新增节点自动配置其配置信息，避免人工逐一查找新增节点，并手动配置新增节点的配置信息，提高效率。

进一步的，基于上图4，在另一些实施例中，上述步骤S203具体可以通过如下步骤实现：在初始节点中选取出目标节点，并从第二目录中获取目标节点的当前配置信息；在第二目录中将新增节点的当前配置信息更新为目标节点的当前配置信息。

在本实施例中，目标节点可以是配置信息最新的一个初始节点。每一次在动态调整初始节点的配置信息时，均可以对应的记录一个版本号，通过版本号来确定在这些初始节点中，哪个初始节点的配置信息最新。

示例性的，以初始节点A、初始节点B和初始节点C为例，在Kafka集群启动之前，初始节点A、初始节点B和初始节点C的配置信息均为预设初始配置信息(对应的版本号可以为V1)。当Kafka集群启动之后，用户可以发起配置调整请求，以此动态的调整初始节点A、初始节点B和初始节点C的配置信息。此时，初始节点A、初始节点B和初始节点C的配置信息发生了变更(即不再为原初始配置信息，且版本号升级为V2)。此时用户再发起集群扩容请求，新增了一个节点D，此时如果没有配置监听组件，则节点D使用的是原预设初始配置信息，如此就会造成各个节点的配置信息不一致(即新增节点D与初始节点A、初始节点B和初始节点C的配置信息不一致)。故而需要启动监听组件，由监听组件从初始节点A、初始节点B和初始节点C中选取出一个目标节点，然后将目标节点的当前配置信息作为新增节点D的当前配置信息(即将目标节点的配置信息写入到第二目录下的新增节点D对应的配置信息中)。

本申请实施例通过在初始节点中找到配置信息最新的目标节点，然后以目标节点的当前配置信息作为新增节点的当前配置信息，如此能够保证新增节点的当前配置信息也是最新的，实现Kafka集群中所有节点的配置信息一致，提高Kafka集群的稳定性，避免Kafka集群下面的各个节点的配置信息出现不一致的情况，导致Kafka集群在某些特定的情况下出现无法服务的情况。

进一步的，在另一些实施例中，初始节点的数量可能会对新增节点的配置信息产生影响。具体的，在确定目标节点时，需要先确定分布式发布订阅消息系统集群的第一目录中初始节点的数量；在分布式发布订阅消息系统集群的第一目录中初始节点的数量为1个时，选取该初始节点作为目标节点。

在本实施例中，依旧以Kafka集群作为分布式发布订阅消息系统集群为例，Kafka集群的初始节点的数量可能只有一个，例如只有初始节点A，此时无论对初始节点A的配置信息做何种动态调整，其当前配置信息都是整个Kafka集群中最新的，即初始节点A的当前配置信息直接可以作为新增节点的当前配置信息。

本申请实施例通过确定Kafka集群的初始节点的数量，基于Kafka集群的初始节点的数量来选取出目标节点，当节点数量之后1个时，则直接将这一个初始节点作为目标节点，可以快速的完成对新增节点的当前配置信息的配置，进一步提高信息配置效率。

图5为本申请另一实施例提供的信息配置方法的流程示意图，如图5所示，其具体包括如下步骤：步骤S501，在分布式发布订阅消息系统集群的第一目录中初始节点数量为多个时，确定各个初始节点在第二目录中对应的配置信息是否相同。步骤S502，若第一目录中存在配置信息不相同的初始节点，则将第一目录中配置信息互不相同的初始节点划分至不同的节点集合。步骤S503，在至少一个节点集合中确定出目标节点集合。步骤S504，选取目标节点集合中的任一初始节点，作为目标节点。其中，每个节点集合中包括有至少一个初始节点且每个节点集合中的初始节点的配置信息相同。

在本实施例中，依旧以Kafka集群作为分布式发布订阅消息系统集群为例，Kafka集群的初始节点的数量可能有多个。示例性的，以Kafka集群的初始节点的数量为三个，即包括上文的初始节点A、初始节点B和初始节点C为例，初始节点A对应有一个第一配置信息，初始节点B对应有一个第二配置信息，初始节点C的当前配置信息与初始节点B的当前配置信息相同(即初始节点C的当前配置信息对应为第二配置信息)，即初始节点A的当前配置信息与初始节点B、初始节点C的当前配置信息不相同。如此初始节点A被划分到一个节点集合中，初始节点B和初始节点C被划分到另外一个节点集合中。示例性的，可以找当前配置信息最新的初始节点的节点集合作为目标节点集合。

本申请实施例通过将初始节点划分到不同的节点集合中，可以快速的掌握Kafka集群中存在有哪些配置信息不一致的节点以及哪些配置信息一致的节点，从而从中找到配置信息最新的初始节点，并将该初始节点的配置信息作为新增节点的配置信息，避免使用旧的配置信息作为新增节点的配置信息，提高了信息配置过程中的准确性。

进一步的，在另一些实施例中，在分布式发布订阅消息系统集群的第一目录中初始节点数量为多个时，若各个初始节点在第二目录中的配置信息均相同，则从第一目录中的多个初始节点中选取出任一个初始节点作为目标节点。

在本实施例中，Kafka集群的初始节点的数量可能有多个，例如初始节点A、初始节点B和初始节点C。其中，初始节点A、初始节点B和初始节点C的配置信息可以都是相同的，此时无论选取哪一个初始节点的配置信息来作为新增节点的配置信息，都可以保证整个Kafka集群中所有节点的配置信息均一致。

本申请实施例通过在配置信息相同的初始节点中选取出任一个初始节点作为目标节点，并将该目标节点的配置信息作为新增节点的配置信息，能够保证整个Kafka集群中所有节点的配置信息的一致，可以在提供Kafka集群的稳定性的同时，减少对Kafka集群中节点的配置信息的维护工作，不需要用户时刻关注Kafka集群中节点的配置信息是否一致。

进一步的，在上述实施例的基础上，在确定目标节点集合时，可以确定每个节点集合中包括的初始节点的数量；在所有节点集合中选取出包括的初始节点的数量最大的节点集合，作为目标节点集合。

在本实施例中，继续以上文提到的初始节点A被划分到一个节点集合U1中，初始节点B和初始节点C被划分到另一个节点集合U2中为例，此时节点集合U2中由于包括有两个初始节点(即初始节点B和初始节点C)，其初始节点的数量大于节点集合U1中包括的初始节点数量，故而初始节点U2作为目标节点集合。

本申请实施例通过选取所包含的初始节点的数量最大的节点集合作为目标节点集合，从目标节点集合中选取任一初始节点的配置信息作为新增节点的配置信息，保证了整个Kafka集群中节点的配置信息趋向于一致，避免Kafka集群中各个节点的配置信息出现多元化，以提高Kafka集群的稳定性。

图6为本申请又一实施例提供的信息配置方法的流程示意图，上述方法除了包括步骤S201至步骤S203之外，还包括步骤601：检测分布式发布订阅消息系统集群的第一目录中是否包括有异常节点。其中，第一目录中除异常节点外的其它节点的配置信息均相同，异常节点的配置信息与分布式发布订阅消息系统集群中异常节点之外的其它节点的配置信息不相同，异常节点之外的其它节点的配置信息均相同。步骤S602，若存在有异常节点，则将异常节点在第二目录中的配置信息更新为与其它节点的配置信息相同。

在本实施例中，依旧以Kafka集群作为分布式发布订阅消息系统集群为例，Kafka集群的节点数量有多个，例如既有新增节点，又有初始节点。其中，Kafka集群中大部分的节点的配置信息是一致的，如果存在有小部分的节点的配置信息与大部分的节点的配置信息不一致的情况，则可以将这一小部分的节点视为异常节点。此时为了保证整个Kafka集群中所有节点的配置信息一致，需要将这些异常节点的配置信息同化为大部分的节点的配置信息。

示例性的，以Kafka集群包括有初始节点A、初始节点B、初始节点C和新增节点D为例，Kafka集群中初始节点B、初始节点C和新增节点D的配置信息一致，而初始节点A的配置信息与初始节点B、初始节点C和新增节点D的配置信息不一致，则初始节点A视为小部分的异常节点，其配置信息会被同化为与初始节点B、初始节点C和新增节点D的配置信息一致。

本申请实施例通过将异常节点的配置信息同化为与其他非异常节点的配置信息相同，保证了Kafka集群中所有节点信息的一致性，使得Kafka集群可以稳定运行，并且也不需要再使用人工逐一确认每个节点的配置信息，找出不一致的节点然后手动的进行调整，减少了Kafka集群的维护成本。

在一些实施例中，上述方法还包括：响应于用户发起的配置信息动态调整请求，获取配置信息动态调整请求中的动态调整信息和待调整节点的节点信息；在分布式发布订阅消息系统集群的第二目录中，将待调整节点的配置信息更新为动态调整信息，其中，待调整节点为第一目录中的初始节点和/或新增节点。

在本实施例中，配置信息动态调整请求可以是上文的配置调整请求，用户可以根据需要发起配置信息动态调整请求，其中包含有用户对Kafka集群中某一个节点或两个以上的节点所期望调整的配置信息、节点信息，其中，节点信息可以是节点标识(例如broker1、broker2和broker3等)。示例性的，以Kafka集群包括有三个初始节点broker1至broker3，需要扩容一个新增节点broker4为例，正常的Kafka集群，用户通过发起配置调整请求调整broker1至broker3这三个初始节点为其所期望的最新的配置内容(如：“message.max.bytes”＝“10000120”)。当接收到配置调整请求后，Kafka集群会获取当前Kafka集群下的broker组(也就是broker1，broker2，broker3)，然后将最新的配置内容逐个写到Zookeeper的config/brokers目录下面(此时broker1-broker3的配置内容为用户所期望的最新的配置内容，即{“config”：{“message.max.bytes”：“10000120”}})。然后用户再发起集群扩容请求，对Kafka集群的broker组进行扩容，新增一个节点broker4，这个时候，Kafka集群会将broker4写到Zookeeper的brokers/ids目录下。但是Kafka集群默认不会处理Zookeeper的config/brokers目录下面的配置，所以此时Zookeeper的config/brokers目录下面的配置依旧只有broker1-broker3的配置项内容。

其中，当Kafka集群将新增的broker4写到Zookeeper的brokers/ids目录下时，监听组件就发现了这个变更信息，并能拿到最新的broker组(即broker1-broke4)，然后通过读取Zookeeper的config/brokers目录下面的节点以及配置项内容，就能获取到broker1-broker3的配置项内容，即({“config”：{“message.max.bytes”：“10000120”}})，另外通过多数派选择出来的配置也是这个内容。读取Zookeeper的config/brokers目录下只能获取到broker1-broker3的配置项内容，而broker组这个时候包含broker1-broker4，说明broker4目前配置没有得到设置，这个时候监听组件可以使用broker1-broker3中处理得到的内容即({“config”：{“message.max.bytes”：“10000120”}})，将其写到config/brokers下作为broker4的配置信息，最终也就是能从Zookeeper的config/brokers目录下看到broker1-4的配置项。至此，扩展集群broker4后的配置自动处理已经完成，而这时也能在Zookeeper的config/brokers目录下看到最终的broker1-broker4的节点配置变更内容。

本申请实施例通过对Zookeeper特定目录(configs/ids)的监听，发现Kafka集群broker的变更时，能及时的将扩展新增的broker的配置参数与旧的broker的配置参数进行比较、设置，最终达到新增的broker的配置与旧的broker的配置一致，来避免因动态配置的不一致，而出现kafka集群无法对外提供服务的问题，同时通过自动化的方式发现并重新设置配置，减少了人为的配置筛查及操作，降低了运维过程中的风险的同时，也降低了人力成本。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图7为本申请实施例提供的信息配置装置的结构示意图，该信息配置装置可以集成在服务器上，也可以独立于服务器且与服务器协同实现本方案。如图7所示，该信息配置装置700具体可以包括有节点检测模块710、信息获取模块720以及信息配置模块730。其中，节点检测模块710用于检测分布式发布订阅消息系统集群的第一目录是否存在新增节点，第一目录还包括有初始节点，初始节点为至少一个。信息获取模块720用于若第一目录存在新增节点，则获取初始节点的当前配置信息，初始节点的当前配置信息位于分布式发布订阅消息系统集群的第二目录中，初始节点的当前配置信息为在新增节点之前对初始节点的配置信息进行动态调整后的信息。信息配置模块730用于根据初始节点的当前配置信息，对新增节点的当前配置信息进行更新，新增节点的当前配置信息为预设初始配置信息，新增节点更新后的配置信息对应的存储于第二目录中。

可选地，节点检测模块在检测分布式发布订阅消息系统集群当前是否存在新增节点时，具体可以用于：获取第一目录中包含的所有节点的总数量；确定总数量与初始节点的数量是否相同；若不相同，则确定分布式发布订阅消息系统集群存在新增节点。

可选地，信息配置模块在根据初始节点的当前配置信息，对新增节点的当前配置信息进行更新时，具体用于：在初始节点中选取出目标节点，并从第二目录中获取目标节点的当前配置信息；在第二目录中将新增节点的当前配置信息更新为目标节点的当前配置信息。

可选地，信息配置模块在选取目标节点时，具体用于：确定分布式发布订阅消息系统集群的第一目录中初始节点的数量；在分布式发布订阅消息系统集群的第一目录中初始节点的数量为1时，选取初始节点作为目标节点。

可选地，信息配置模块在选取目标节点时，具体用于：在分布式发布订阅消息系统集群的第一目录中初始节点数量为多个时，确定第二目录中各个初始节点的配置信息是否相同；若第二目录中存在配置信息不相同的初始节点，则将第一目录中配置信息互不相同的初始节点划分至不同的节点集合，每个节点集合中包括有至少一个初始节点且每个节点集合中的初始节点的配置信息相同；在至少一个节点集合中确定出目标节点集合；选取目标节点集合中的任一初始节点，作为目标节点。

可选地，信息配置模块在确定目标节点集合时，具体用于：确定每个节点集合中包括的初始节点的数量；在所有节点集合中选取出包括的初始节点的数量最大的节点集合，作为目标节点集合。

可选地，信息配置模块在选取目标节点时，具体用于：在分布式发布订阅消息系统集群的第一目录中初始节点数量为多个时，若第二目录中各个初始节点的配置信息均相同，则从第一目录中的多个初始节点中选取出任一个初始节点作为目标节点。

可选的，上述信息配置装置还包括有信息更新模块，用于检测分布式发布订阅消息系统集群的第一目录中是否包括有异常节点，第一目录中除异常节点外的其它节点的配置信息均相同；若存在有异常节点，则将第二目录中异常节点的配置信息更新为与其它节点的配置信息相同。

可选的，上述信息配置装置还包括信息调整模块，用于响应于用户发起的配置信息动态调整请求，获取配置信息动态调整请求中的动态调整信息和待调整节点的节点信息，待调整节点为第一目录中的初始节点和/或新增节点；在分布式发布订阅消息系统集群的第二目录中，将待调整节点的配置信息更新为动态调整信息。

本申请实施例提供的装置，可用于执行上述所示实施例中的方法，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，节点检测模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上节点检测模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

图8为本申请实施例提供的计算机设备的结构示意图。如图8所示，该计算机设备800包括：至少一个处理器810、存储器820、总线830及通信接口840。其中：处理器810、通信接口840以及存储器820通过总线830完成相互间的通信。通信接口840用于与其它设备进行通信。该通信接口包括用于进行数据传输的通信接口以及用于进行人机交互的显示界面或者操作界面等。处理器810，用于执行存储器820中存储的计算机执行指令，具体可以执行上述实施例中所描述的方法中的相关步骤。处理器可能是中央处理器，或者是特定集成电路(Application Specific Integrated Circuit，ASIC)，或者是被配置成实施本发明实施例的一个或多个集成电路。计算机设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。存储器，用于存放计算机执行指令。存储器可能包含高速RAM存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。

本实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机指令，当计算机设备的至少一个处理器执行该计算机指令时，计算机设备执行上述的各种实施方式提供的信息配置方法。

本实施例还提供一种程序产品，该程序产品包括计算机指令，该计算机指令存储在可读存储介质中。计算机设备的至少一个处理器可以从可读存储介质读取该计算机指令，至少一个处理器执行该计算机指令使得计算机设备实施上述的各种实施方式提供的信息配置方法。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中，a，b，c可以是单个，也可以是多个。

可以理解的是，在本申请实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (12)

1.一种信息配置方法，其特征在于，包括：

检测分布式发布订阅消息系统集群的第一目录是否存在新增节点，所述第一目录还包括有初始节点，所述初始节点为至少一个；

若所述第一目录存在新增节点，则获取所述初始节点的当前配置信息，所述初始节点的当前配置信息位于所述分布式发布订阅消息系统集群的第二目录中，所述初始节点的当前配置信息为在新增节点之前对所述初始节点的配置信息进行动态调整后的信息；

根据所述初始节点的当前配置信息，对所述新增节点的当前配置信息进行更新，所述新增节点的当前配置信息为预设初始配置信息，所述新增节点更新后的配置信息对应的存储于所述第二目录中。

2.根据权利要求1所述的方法，其特征在于，所述检测分布式发布订阅消息系统集群的第一目录是否存在新增节点，包括：

获取所述第一目录中包含的所有节点的总数量；

确定所述总数量与所述初始节点的数量是否相同；

若不相同，则确定所述分布式发布订阅消息系统集群存在新增节点。

3.根据权利要求1所述的方法，其特征在于，所述根据所述初始节点的当前配置信息，对所述新增节点的当前配置信息进行更新，包括：

在所述初始节点中选取出目标节点，并从所述第二目录中获取所述目标节点的当前配置信息；

在所述第二目录中将所述新增节点的当前配置信息更新为所述目标节点的当前配置信息。

4.根据权利要求3所述的方法，其特征在于，所述在所述初始节点中选取出目标节点，包括：

确定所述分布式发布订阅消息系统集群的第一目录中初始节点的数量；

在所述分布式发布订阅消息系统集群的第一目录中初始节点的数量为1时，选取所述初始节点作为所述目标节点。

5.根据权利要求3所述的方法，其特征在于，所述在所述初始节点中选取出目标节点，包括：

在所述分布式发布订阅消息系统集群的第一目录中初始节点数量为多个时，确定各个初始节点在所述第二目录中的配置信息是否相同；

若所述第一目录中存在配置信息不相同的初始节点，则将所述第一目录中配置信息互不相同的初始节点划分至不同的节点集合，每个节点集合中包括有至少一个初始节点且每个节点集合中的初始节点的配置信息相同；

在所述至少一个节点集合中确定出目标节点集合；

选取所述目标节点集合中的任一初始节点，作为所述目标节点。

6.根据权利要求5所述的方法，其特征在于，所述在所述至少一个节点集合中确定出目标节点集合，包括：

确定每个节点集合中包括的初始节点的数量；

在所有节点集合中选取出包括的初始节点的数量最大的节点集合，作为所述目标节点集合。

7.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在所述分布式发布订阅消息系统集群的第一目录中初始节点数量为多个时，若各个初始节点在所述第二目录中的配置信息均相同，则从第一目录中的多个初始节点中选取出任一个初始节点作为所述目标节点。

8.根据权利要求1-7任一项所述的方法，其特征在于，所述方法还包括：

检测所述分布式发布订阅消息系统集群的第一目录中是否包括有异常节点，所述第一目录中除所述异常节点外的其它节点的配置信息均相同；

若存在有所述异常节点，则将所述异常节点在所述第二目录中的配置信息更新为与所述其它节点的配置信息相同。

9.根据权利要求1-7任一项所述的方法，其特征在于，所述方法还包括：

响应于用户发起的配置信息动态调整请求，获取所述配置信息动态调整请求中的动态调整信息和待调整节点的节点信息，所述待调整节点为所述第一目录中的初始节点和/或新增节点；

在所述分布式发布订阅消息系统集群的第二目录中，将所述待调整节点的配置信息更新为所述动态调整信息。

10.一种信息配置装置，其特征在于，包括：

节点检测模块，用于检测分布式发布订阅消息系统集群的第一目录是否存在新增节点，所述第一目录还包括有初始节点，所述初始节点为至少一个；

信息获取模块，用于若所述第一目录存在新增节点，则获取所述初始节点的当前配置信息，所述初始节点的当前配置信息位于所述分布式发布订阅消息系统集群的第二目录中，所述初始节点的当前配置信息为在新增节点之前对所述初始节点的配置信息进行动态调整后的信息；

信息配置模块，用于根据所述初始节点的当前配置信息，对所述新增节点的当前配置信息进行更新，所述新增节点的当前配置信息为预设初始配置信息，所述新增节点更新后的配置信息对应的存储于所述第二目录中。

11.一种计算机设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1-9中任一项所述的方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现如权利要求1-9任一项所述的方法。

Images