CN113703866A - 配置中心信息同步方法及系统 - Google Patents

Abstract

本申请公开了一种配置中心信息同步方法，该方法包括：在所述配置中心每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表；所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送‑拉取‑拉取模式交换配置信息，以更新所述第二信息表。本申请还公开了一种配置中心系统、配置中心信息同步系统、电子装置和计算机可读存储介质。由此，能够解决配置中心服务端对第三方中间件强依赖的问题。

Description

配置中心信息同步方法及系统

技术领域

本申请涉及配置中心技术领域，尤其涉及一种配置中心信息同步方法、系统、电子装置及计算机可读存储介质。

背景技术

在分布式微服务的开发中，很多项目都需要对其中的服务启动配置、业务逻辑配置和灰度配置等进行统一的管理，从而引入了分布式配置中心系统。目前对于配置中心的服务发现主要是通过以下两种方式实现的：

第一种是注册中心(服务发现中间件)，即配置中心服务端在启动时主动将自身服务器的地址信息注册到服务发现中间件上，该中间件和服务端保持心跳机制来校验服务端是否还存活着，服务端通过该中间件获取到其他存活着的服务器的路由地址等信息。

另一种是Nginx代理服务器，用户需要将配置中心服务端部署的所有服务器地址手动维护到Nginx代理服务器中，服务端通过Nginx代理服务器获取到其他所有服务器的路由地址等信息。

但是，这两种方式均存在缺点：

在第一种实现方式下，配置中心需要强依赖注册中心，一旦注册中心出现事故，配置中心服务端也会无法感知到当前有哪些服务器还在线或者离线，造成配置中心出现不可用或者数据不一致的情况。另外部分的注册中心(例如zookeeper)也有可能发生网络分区故障，造成服务不可用。

在第二种实现方式下，也会对Nginx代理服务器进行强依赖，一旦Nginx代理服务器不可用则无法感知到当前哪些服务器还在线或者离线。并且，Nginx代理服务器对于服务端的服务器地址的管理需要用户自己去维护，每次如果有新增、更新或者删除服务器节点则需要对Nginx代理服务器进行配置和重新加载，对于服务端机器的扩展不是很友好。

需要说明的是，上述内容并不用于限制申请保护范围。

发明内容

本申请的主要目的在于提出一种配置中心信息同步方法、系统、电子装置及计算机可读存储介质，旨在解决配置中心服务端对第三方中间件强依赖的问题。

为实现上述目的，本申请实施例提供了一种配置中心信息同步方法，所述方法包括：

在所述配置中心每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表；

所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表，包括：

第一节点发送本地最新的第一配置信息至第二节点；

所述第二节点比较本地数据与所述第一配置信息，并将比所述第一配置信息更加新的第二配置信息返回至所述第一节点；

所述第一节点比较本地数据与所述第二配置信息，更新所述第二配置信息到本地，并将比所述第二配置信息更加新的第三配置信息返回至所述第二节点；

所述第二节点更新所述第三配置信息到本地。

可选地，所述方法还包括：当所述配置中心新增服务器节点时，通过UDP协议通知所述配置中心每个服务器节点，并更新所述第二信息表。

可选地，所述当所述配置中心新增服务器节点时，通过UDP协议通知所述配置中心每个服务器节点，并更新所述第二信息表包括：

当所述当前服务器节点新增至所述配置中心时，遍历所述配置中心的服务器地址列表，通过UDP协议向所述服务器地址列表中的所有其他服务器节点发送新增通知；

所述当前服务器节点和每个所述其他服务器节点之间相互配对，通过所述推送-拉取-拉取模式交换配置信息，并将对方的配置信息更新至所述第二信息表。

可选地，所述当所述配置中心新增服务器节点时，通过UDP协议通知所述配置中心每个服务器节点，并更新所述第二信息表包括：

当所述当前服务器节点接收到第一服务器节点通过UDP协议发送的所述新增通知时，与所述第一服务器节点之间相互配对，通过所述推送-拉取-拉取模式交换配置信息，并将对方的配置信息更新至所述第二信息表。

可选地，所述方法还包括：

通过失效检测器计算所述服务器节点之间心跳间隔的平均时间，当检测到第二服务器节点的最后在线时间和系统时间之差超过所述平均时间时，判断所述第二服务器节点已经下线，将所述第二服务器节点从所述第二信息表中移除。

可选地，所述方法还包括：

当第三服务器节点上线时，从所述配置中心中随机选择多个其他服务器节点进行配对，并且每对服务器节点之间通过所述推送-拉取-拉取模式交换配置信息，直至所有服务器节点中的信息一致。

可选地，所述方法还包括：

当所述配置中心任意一个服务器节点接收到用户更新配置信息的通知后，通过UDP协议通知所述配置中心其他服务器节点进行更新。

可选地，所述接收到用户更新配置信息的通知包括接收到配置中心管理端发送的用户在配置中心管理页面更新配置信息的通知或者接收到客户端发送的用户更新配置信息的请求。

可选地，所述配置中心管理端或所述客户端将所述通知或所述请求发送至所述配置中心的任意一个种子服务器节点，所述种子服务器节点将更新通知通过UDP协议发送至所述配置中心其他服务器。

可选地，所述当所述配置中心任意一个服务器节点接收到用户更新配置信息的通知后，通过UDP协议通知所述配置中心其他服务器节点进行更新包括：

当所述当前服务器节点接收到用户更新配置信息的通知后，与所述本地文件中缓存的配置信息进行对比；

当对比结果不一致时，将更新的配置信息保存至配置中心数据库中，并更新所述本地文件；

遍历所述配置中心的服务器地址列表，向所述服务器地址列表中的其他服务器节点发送更新通知，以使所述其他服务器节点通过访问所述配置中心数据库获取所述更新的配置信息。

可选地，所述当所述配置中心任意一个服务器节点接收到用户更新配置信息的通知后，通过UDP协议通知所述配置中心其他服务器节点进行更新包括：

当所述当前服务器节点接收到所述其他服务器节点发送的所述更新通知时，访问所述配置中心数据库，从所述配置中心数据库中获取所述更新通知对应的所述更新的配置信息。

此外，为实现上述目的，本申请实施例还提供一种配置中心系统，所述系统包括：

管理端，用于接收用户在配置中心管理页面设置或更新的配置信息，并将更新通知发送至所述配置中心的任意一个种子服务器节点；

数据库，用于保存所述设置或更新的配置信息；

服务端，包括多个服务器节点，每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表；

所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表，包括：

第一节点发送本地最新的第一配置信息至第二节点；

所述第二节点比较本地数据与所述第一配置信息，并将比所述第一配置信息更加新的第二配置信息返回至所述第一节点；

所述第一节点比较本地数据与所述第二配置信息，更新所述第二配置信息到本地，并将比所述第二配置信息更加新的第三配置信息返回至所述第二节点；

所述第二节点更新所述第三配置信息到本地。

为实现上述目的，本申请实施例还提供一种配置中心信息同步系统，所述系统包括：

设置模块，用于在本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表；

交互模块，用于与其他服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表，包括：

第一节点发送本地最新的第一配置信息至第二节点；

所述第二节点比较本地数据与所述第一配置信息，并将比所述第一配置信息更加新的第二配置信息返回至所述第一节点；

所述第一节点比较本地数据与所述第二配置信息，更新所述第二配置信息到本地，并将比所述第二配置信息更加新的第三配置信息返回至所述第二节点；

所述第二节点更新所述第三配置信息到本地。

为实现上述目的，本申请实施例还提供一种电子装置，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的配置中心信息同步程序，所述配置中心信息同步程序被所述处理器执行时实现如上述的配置中心信息同步方法。

为实现上述目的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有配置中心信息同步程序，所述配置中心信息同步程序被处理器执行时实现如上述的配置中心信息同步方法。

本申请实施例提出的配置中心信息同步方法、系统、电子装置及计算机可读存储介质，能够实现服务端各个服务器节点之间自己管理服务器信息，解决了配置中心服务端对第三方中间件(服务发现中间件或Nginx代理服务器)强依赖的问题，对服务端进行去中心化，降低了服务的复杂度，并且保证了配置中心服务端的最终数据一致性，防止第三方中间件的故障对配置中心造成影响。

附图说明

图1为本申请第一实施例提出的一种配置中心系统的应用环境架构图；

图2为本申请第二实施例提出的一种配置中心信息同步方法的流程图；

图3为本申请中推送-拉取-拉取模式的信息交换示意图；

图4为本申请第三实施例提出的一种配置中心信息同步方法的流程图；

图5为图4中步骤S204的第一种细化流程示意图；

图6为图4中步骤S204的第二种细化流程示意图；

图7为本申请第四实施例提出的一种配置中心信息同步方法的流程图；

图8为本申请第五实施例提出的一种配置中心信息同步方法的流程图；

图9为图8中步骤S410的第一种细化流程示意图；

图10为图8中步骤S410的第二种细化流程示意图；

图11为本申请第六实施例提出的一种电子装置的硬件架构示意图；

图12为本申请第七实施例提出的一种配置中心信息同步系统的模块示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

实施例一

请参阅图1，图1为本申请第一实施例提出的一种配置中心系统的应用环境架构图。本申请可应用于包括，但不仅限于下配置中心服务端2、客户端4、配置中心管理端6、配置中心数据库8的应用环境中。

其中，所述配置中心服务端2可以包括多个服务器节点，用于为所述客户端2提供配置信息。所述服务器可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等计算设备，可以是独立的服务器，也可以是多个服务器所组成的服务器集群。

所述客户端4为SDK客户端，用于向配置中心服务端2获取配置的更新情况。所述客户端2可以为PC(Personal Computer，个人电脑)、手机、平板电脑、便携计算机、可穿戴设备等终端设备。

所述配置中心管理端6用于向用户提供配置中心管理页面，用户登录所述配置中心管理页面后，可以设置各个配置的关键字(Key)及配置内容(Value)，以及更新Value的值。所述Value可以是所述配置的MD5信息。当用户新建Key或Value或者更新Value之后，所述配置中心管理端6将更新通知(包括更新信息)发送至所述配置中心服务端2中任意一个种子服务器节点。所述配置中心数据库8(Mysql数据库)用于保存各个配置的Key和Value。

另外，用户也可以通过所述客户端4对配置中心指定Key的Value进行修改。所述客户端4还用于接收所述修改后，向所述配置中心服务端2中任意一个服务器发送更新请求。

所述配置中心服务端2的每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表。两个服务器节点之间相互配对，每对服务器节点之间通过Pull-Push-Push(推送-拉取-拉取)模式交换配置信息，直至所有服务器节点中的信息一致，将所述配置中心的完整配置信息记录到所述第二信息表中。

所述配置中心服务端2、客户端4、配置中心管理端6、配置中心数据库8之间通过网络进行通信连接，以进行数据传输和交互。所述网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，GSM)、宽带码分多址(Wideband Code Division Multiple Access，WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

实施例二

如图2所示，为本申请第二实施例提出的一种配置中心信息同步方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以所述配置中心服务端2作为执行主体对该方法进行说明。

该方法包括以下步骤：

S100，在所述配置中心每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表。

在本实施例中，通过Gossip协议实现服务端的服务器节点之间自己管理服务器地址信息，移除了对注册中心的依赖，降低了服务的复杂度。在Gossip协议中，每个服务器节点维护一个记录自己的配置信息的第一信息表<key,(value,version)>，包括关键字、配置内容以及版本号；和一个记录其他配置中心其他服务器节点的配置信息的第二信息表<node,<key,(value,version)>>，包括节点信息、关键字、配置内容以及版本号。

Gossip协议是一个通信协议，也叫流行病协议，是一种传播消息的方式。Gossip协议的交互过程是由种子节点发起，当一个种子节点有状态需要更新到网络中的其他节点时，它会随机的选择周围几个节点散播消息，收到消息的节点也会重复该过程，直至最终网络中所有的节点都收到了消息。这个过程可能需要一定的时间，由于不能保证某个时刻所有节点都收到消息，但是理论上最终所有节点都会收到消息，因此它是一个最终一致性协议。

另外，Gossip协议是基于SWIM协议实现的，SWIM协议是一种无中心的分布式协议，各个节点之间通过P2P实现信息交流同步各节点状态。该协议通过失效检测器和传播组件来完成工作，失效检测器会检测失效的节点并将失效节点的更新信息发送给传播组件，传播组件通过多播的形式将失效信息传播给组内的其他成员，所以SWIM协议具有可扩展性，新成员的加入和退出都以同样的方式进行多播通信。

S102，所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表。

在本实施例中，每个服务器节点和所述配置中心的某个其他服务器节点之间相互配对。一般情况下，服务器节点之间的信息交换方式主要有三种，分别Pull(推送)模式、Push(拉取)模式以及Pull-Push-Push(推送-拉取-拉取)模式。三种交互方式相比之下Push模式网络通信消耗最低，而Pull-Push-Push模式虽然通信消耗最高，但的信息交互示意图集群交互收敛性更强，理论上一次通信就可以使两个服务器节点的状态完全一致。

本实施例主要采用Pull-Push-Push模式进行服务器节点之间的信息交换。例如，当第一节点和第二节点配对时，所述Pull-Push-Push模式的信息交换过程具体包括：

(1)第一节点发送本地最新的第一配置信息至第二节点。

(2)第二节点比较本地数据(第一信息表和第二信息表中的配置信息)与所述第一配置信息，并将比所述第一配置信息更加新的第二配置信息返回至第一节点。

(3)第一节点比较本地数据(第一信息表和第二信息表中的配置信息)与所述第二配置信息，更新所述第二配置信息到本地(第二信息表)，并将比所述第二配置信息更加新的第三配置信息返回至第二节点。

(4)第二节点更新所述第三配置信息到本地(第二信息表)。

如图3所示，为Pull-Push-Push模式的信息交换示意图。在图3中，服务器节点A首先发送该节点的所有最新的数据A给服务器节点B；节点B比较本地数据与节点A发送的数据A，并将比数据A更加新的数据B返回给节点A；节点A更新数据B到本地，并且返回比数据B更加新的数据A’至节点B；节点B更新数据A’到本地。

本实施例中，所述配置中心两个服务器节点之间相互配对后，每对服务器节点之间通过Pull-Push-Push模式交换配置信息，直至所有服务器节点中的信息一致。并且，服务器节点之间的交互模式是通过反熵模式(Anti-entropy)。在反熵模式下，一个节点会定期将所有的数据都与其他节点共享，以便消除节点之间数据的任何不一致，它可以保证最终完全的一致，这种方式集群收敛速度很快。

本实施例提出的配置中心信息同步方法，可以通过Gossip协议实现服务端各个服务器节点之间自己管理服务器信息，解决了配置中心服务端对第三方中间件(服务发现中间件或Nginx代理服务器)强依赖的问题，对服务端进行去中心化，降低了服务的复杂度，并且保证了配置中心服务端的最终数据一致性，防止第三方中间件的故障对配置中心造成影响。

实施例三

如图4所示，为本申请第三实施例提出的一种配置中心信息同步方法的流程图。在第三实施例中，所述配置中心信息同步方法在上述第二实施例的基础上，还包括步骤S204。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S200，在所述配置中心每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表。

在本实施例中，通过Gossip协议实现服务端的服务器节点之间自己管理服务器地址信息，移除了对注册中心的依赖，降低了服务的复杂度。在Gossip协议中，每个服务器节点维护一个记录自己的配置信息的第一信息表<key,(value,version)>，包括关键字、配置内容以及版本号；和一个记录其他配置中心其他服务器节点的配置信息的第二信息表<node,<key,(value,version)>>，包括节点信息、关键字、配置内容以及版本号。

S202，所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表。

在本实施例中，每个服务器节点和所述配置中心的某个其他服务器节点之间相互配对。本实施例主要采用Pull-Push-Push模式进行服务器节点之间的信息交换。例如，当第一节点和第二节点配对时，所述Pull-Push-Push模式的信息交换过程具体包括：

(1)第一节点发送本地最新的第一配置信息至第二节点。

(2)第二节点比较本地数据(第一信息表和第二信息表中的配置信息)与所述第一配置信息，并将比所述第一配置信息更加新的第二配置信息返回至第一节点。

(3)第一节点比较本地数据(第一信息表和第二信息表中的配置信息)与所述第二配置信息，更新所述第二配置信息到本地(第二信息表)，并将比所述第二配置信息更加新的第三配置信息返回至第二节点。

(4)第二节点更新所述第三配置信息到本地(第二信息表)。

本实施例中，所述配置中心两个服务器节点之间相互配对后，每对服务器节点之间通过Pull-Push-Push模式交换配置信息，直至所有服务器节点中的信息一致。并且，服务器节点之间的交互模式是通过反熵模式。在反熵模式下，一个节点会定期将所有的数据都与其他节点共享，以便消除节点之间数据的任何不一致，它可以保证最终完全的一致，这种方式集群收敛速度很快。

S204，当所述配置中心新增服务器节点时，通过UDP(User Datagram Protocol，用户数据报协议)协议通知所述配置中心每个服务器节点，并更新所述第二信息表。

UDP协议是一个简单的面向数据报的通信协议，只提供数据的不可靠传递，一旦将应用程序发给网络层的数据发送出去，就不保留数据备份。在本实施例中，该步骤有两种情况，一种是当前服务器节点为新增服务器节点，还有一种是当前服务器节点不是新增服务器节点，而是收到其他服务器节点的新增通知。

具体而言，进一步参阅图5，为上述步骤S204的第一种细化流程示意图(对应上述第一种情况)。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤S204具体包括：

S2040，当所述当前服务器节点新增至所述配置中心时，遍历所述配置中心的服务器地址列表，通过UDP协议向所述服务器地址列表中的所有其他服务器节点发送新增通知。

值得注意的是，所述服务器地址列表为种子服务器节点的地址列表。种子服务器节点与普通服务器节点的区别在于种子服务器节点需要在普通服务器节点启动之前先被启动，因为普通服务器节点需要依赖种子服务器节点的认证和传播来帮助普通服务器节点加入集群。在新增服务器节点时，首先要保证种子服务器节点是全部存活的，并且种子服务器节点的服务器地址信息是固定的。

当新增的所述当前服务器节点启动之后，会遍历种子服务器节点的地址列表，通过UDP协议通知种子服务器节点，该新增服务器节点将要加入到集群中。

S2042，所述当前服务器节点和每个所述其他服务器节点之间相互配对，通过推送-拉取-拉取模式交换配置信息，并将对方的配置信息更新至所述第二信息表。

当种子服务器节点接收到所述新增通知后，所述当前服务器节点和每个种子服务器节点之间相互配对，再通过Pull-Push-Push模式，所述当前服务器节点和种子服务器节点分别将对方的配置信息更新到本地文件的第二信息表中。当然，其他未与所述当前服务器节点配对的服务器节点也可以通过与某个种子服务器节点之间的交互得到新增的所述当前服务器节点的配置信息。

进一步参阅图6，为上述步骤S204的第二种细化流程示意图(对应上述第二种情况)。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤S204具体包括：

S2044，当所述当前服务器节点接收到第一服务器节点通过UDP协议发送的所述新增通知时，与所述第一服务器节点之间相互配对。

若新增至所述配置中心的服务器节点为第一服务器节点时，所述第一服务器节点遍历所述配置中心的服务器地址列表，通过UDP协议向所述服务器地址列表中的所有服务器节点发送新增通知。当所述当前服务器节点接收到所述第一服务器节点发送的所述新增通知时，与所述第一服务器节点之间相互配对。

S2046，所述当前服务器节点与所述第一服务器节点通过推送-拉取-拉取模式交换配置信息，并将对方的配置信息更新至所述第二信息表。

本实施例提出的配置中心信息同步方法，可以通过Gossip协议实现服务端各个服务器节点之间自己管理服务器信息，解决了配置中心服务端对第三方中间件(服务发现中间件或Nginx代理服务器)强依赖的问题，对服务端进行去中心化，降低了服务的复杂度，并且保证了配置中心服务端的最终数据一致性，防止第三方中间件的故障对配置中心造成影响。并且，本方法优化了新增服务器节点加入集群的交互，新增服务器节点在加入集群时会向每个种子节点发送新增通知，提高其加入集群的成功率和之后交互的传播率。

实施例四

如图7所示，为本申请第四实施例提出的一种配置中心信息同步方法的流程图。在第四实施例中，所述配置中心信息同步方法在上述第三实施例的基础上，还包括步骤S306-S308。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S300，在所述配置中心每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表。

在本实施例中，通过Gossip协议实现服务端的服务器节点之间自己管理服务器地址信息，移除了对注册中心的依赖，降低了服务的复杂度。在Gossip协议中，每个服务器节点维护一个记录自己的配置信息的第一信息表<key,(value,version)>，包括关键字、配置内容以及版本号；和一个记录其他配置中心其他服务器节点的配置信息的第二信息表<node,<key,(value,version)>>，包括节点信息、关键字、配置内容以及版本号。

S302，所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表。

在本实施例中，每个服务器节点和所述配置中心的某个其他服务器节点之间相互配对，每对服务器节点之间通过Pull-Push-Push模式交换配置信息，直至所有服务器节点中的信息一致。并且，服务器节点之间的交互模式是通过反熵模式。信息交换的具体过程参阅第二实施例中的说明，在此不再赘述。

S304，当所述配置中心新增服务器节点时，通过UDP协议通知所述配置中心每个服务器节点，并更新所述第二信息表。

在本实施例中，该步骤有两种情况，一种是当前服务器节点为新增服务器节点，还有一种是当前服务器节点不是新增服务器节点，而是收到其他服务器节点的新增通知。这两种情况的具体细化流程参阅第三实施例中的说明，在此不再赘述。

S306，通过失效检测器计算服务器节点之间心跳间隔的平均时间，当检测到第二服务器节点的最后在线时间和系统时间之差超过所述平均时间时，判断所述第二服务器节点已经下线，从所述第二信息表中移除。

当所述配置中心的服务器节点中有一台服务器(第二服务器节点)下线后，其他在线的服务器节点就会无法和第二服务器节点进行交互，之后第二服务器节点在其他服务器节点上的“最后在线时间”会随着时间距离当前系统时间越来越长。而失效检测器会计算出以往服务器节点之间心跳间隔的平均时间，并在检测到该第二服务器节点的最后在线时间和系统时间之差超过所述平均时间时，其他服务器节点将会认为第二服务器已经下线，将其从所述第二信息表中移除。

S308，当第三服务器节点上线时，从所述配置中心中随机选择多个其他服务器节点进行配对，并且每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，直至所有服务器节点中的信息一致。

当有服务器节点更新(例如第三服务器节点上线)时，本实施例默认每个服务器节点随机选择n个其他服务器节点进行Pull-Push-Push模式同步数据，通过几次交互后，使集群达到数据最终一致。也就是说，所述第三服务器节点从所述配置中心中随机选择n个其他服务器节点进行配对，并且每对服务器节点之间通过Pull-Push-Push模式交换配置信息，直至所有服务器节点中的信息一致。

本实施例提出的配置中心信息同步方法，可以通过Gossip协议实现服务端各个服务器节点之间自己管理服务器信息，解决了配置中心服务端对第三方中间件(服务发现中间件或Nginx代理服务器)强依赖的问题，对服务端进行去中心化，降低了服务的复杂度，并且保证了配置中心服务端的最终数据一致性，防止第三方中间件的故障对配置中心造成影响。并且，本方法优化了新增服务器节点加入集群的交互，新增服务器节点在加入集群时会向每个种子节点发送新增通知，提高其加入集群的成功率和之后交互的传播率。另外，当有服务器节点下线或上线时，也能使其他服务器节点快速同步到相关信息，提高了整个配置中心的信息一致性和可用性。

实施例五

如图8所示，为本申请第五实施例提出的一种配置中心信息同步方法的流程图。在第五实施例中，所述配置中心信息同步方法在上述第四实施例的基础上，还包括步骤S410。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。

该方法包括以下步骤：

S400，在所述配置中心每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表。

在本实施例中，通过Gossip协议实现服务端的服务器节点之间自己管理服务器地址信息，移除了对注册中心的依赖，降低了服务的复杂度。在Gossip协议中，每个服务器节点维护一个记录自己的配置信息的第一信息表<key,(value,version)>，包括关键字、配置内容以及版本号；和一个记录其他配置中心其他服务器节点的配置信息的第二信息表<node,<key,(value,version)>>，包括节点信息、关键字、配置内容以及版本号。

S402，所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表。

在本实施例中，每个服务器节点和所述配置中心的某个其他服务器节点之间相互配对，每对服务器节点之间通过Pull-Push-Push模式交换配置信息，直至所有服务器节点中的信息一致。并且，服务器节点之间的交互模式是通过反熵模式。信息交换的具体过程参阅第二实施例中的说明，在此不再赘述。

S404，当所述配置中心新增服务器节点时，通过UDP协议通知所述配置中心每个服务器节点，并更新所述第二信息表。

在本实施例中，该步骤有两种情况，一种是当前服务器节点为新增服务器节点，还有一种是当前服务器节点不是新增服务器节点，而是收到其他服务器节点的新增通知。这两种情况的具体细化流程参阅第三实施例中的说明，在此不再赘述。

S406，通过失效检测器计算服务器节点之间心跳间隔的平均时间，当检测到第二服务器节点的最后在线时间和系统时间之差超过所述平均时间时，判断所述第二服务器节点已经下线，从所述第二信息表中移除。

当所述配置中心的服务器节点中有一台服务器(第二服务器节点)下线后，其他在线的服务器节点就会无法和第二服务器节点进行交互，之后第二服务器节点在其他服务器节点上的“最后在线时间”会随着时间距离当前系统时间越来越长。而失效检测器会计算出以往服务器节点之间心跳间隔的平均时间，并在检测到该第二服务器节点的最后在线时间和系统时间之差超过所述平均时间时，其他服务器节点将会认为第二服务器已经下线，将其从所述第二信息表中移除。

S408，当第三服务器节点上线时，从所述配置中心中随机选择多个其他服务器节点进行配对，并且每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，直至所有服务器节点中的信息一致。

当有服务器节点更新(例如第三服务器节点上线)时，本实施例默认每个服务器随机选择n个其他服务器节点进行Pull-Push-Push模式同步数据，通过几次交互后，使集群达到数据最终一致。也就是说，所述第三服务器节点从所述配置中心中随机选择n个其他服务器节点进行配对，并且每对服务器节点之间通过Pull-Push-Push模式交换配置信息，直至所有服务器节点中的信息一致。

S410，当所述配置中心任意一个服务器节点接收到用户更新配置信息的通知后，通过UDP协议通知所述配置中心其他服务器节点进行更新。

在本实施例中，用户可以通过配置中心管理端提供的配置中心管理页面设置Key或Value，更新Value的值。然后配置中心管理端将用户更新配置信息的通知(包括更新的配置信息)发送至所述配置中心的任意一个种子服务器节点。

另外，用户还可以通过SDK客户端对所述配置中心中指定Key的Value进行修改。所述客户端会随机向任意一个种子服务器节点发送更新配置信息的请求(包括更新的配置信息)。

当所述任意一个种子服务器节点接收到所述配置中心管理端发送的用户更新配置信息的通知或者接收到所述客户端用户更新配置信息的请求后，将更新通知通过UDP协议发送至所述配置中心其他服务器节点。

在本实施例中，该步骤也有两种情况，一种是当前服务器节点为所述任意一个种子服务器节点，还有一种是当前服务器节点不是所述任意一个种子服务器节点，而是收到该种子服务器节点发送的更新通知。

具体而言，进一步参阅图9，为上述步骤S410的第一种细化流程示意图(对应上述第一种情况)。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤S410具体包括：

S4100，当所述当前服务器节点接收到用户更新配置信息的通知后，与所述本地文件中缓存的配置信息进行对比。

若当前服务器节点即为所述配置中心管理端或所述客户端选中的种子服务器节点，则所述当前服务器节点会接收到所述配置中心管理端发送的用户更新配置信息的通知或者接收到所述客户端用户更新配置信息的请求。然后所述当前服务器节点先对比本地文件中的Value值和用户更新后的Value值是否一致。

S4102，当对比结果不一致时，将更新的配置信息保存至配置中心数据库中，并更新所述本地文件。

当对比之后发现本地文件中的Value值和用户更新后的Value值不一致时，所述当前服务器节点将用户更新后的Value值保存到配置中心数据库(Mysql数据库)中，并根据所述用户更新后的Value值更新本地文件缓存。

S4104，遍历所述配置中心的服务器地址列表，向所述服务器地址列表中的其他服务器节点发送更新通知，以使所述其他服务器节点通过访问所述配置中心数据库获取所述更新的配置信息。

所述当前服务器节点在更新完本地文件之后，通过遍历所述配置中心的服务器地址列表，向这些服务器节点发送更新通知，这些服务器节点收到所述更新通知后再去访问所述配置中心数据库，从而拉取最新的value值更新到它们的本地文件进行缓存。

进一步参阅图10，为上述步骤S410的第二种细化流程示意图(对应上述第二种情况)。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤S410具体包括：

S4106，当所述当前服务器节点接收到所述其他服务器节点发送的所述更新通知时，访问所述配置中心数据库。

若所述当前服务器节点不是所述配置中心管理端或所述客户端选中的种子服务器节点，则所述当前服务器节点会接收到该种子服务器节点发送的所述更新通知。

S4108，从所述配置中心数据库中获取所述更新通知对应的所述更新的配置信息。

所述当前服务器节点访问所述配置中心数据库后，根据所述更新通知中的Key从所述配置中心数据库中拉取该Key对应的更新后的Value值，然后将该更新后的Value值更新到本地文件中进行缓存。

本实施例提出的配置中心信息同步方法，可以在用户通过配置中心管理端或客户端更新配置信息时，使所述配置中心的所有服务器节点都快速同步到更新后的配置信息，提高了配置信息的准确性和更新过程的及时性。

实施例六

如图11所示，为本申请第六实施例提出一种电子装置20的硬件架构示意图。本实施例中，所述电子装置20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图11仅示出了具有组件21-23的电子装置20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述电子装置20可以是所述配置中心服务端2或所述配置中心服务端2中的服务器。

所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述电子装置20的内部存储单元，例如该电子装置20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述电子装置20的外部存储设备，例如该电子装置20上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器21还可以既包括所述电子装置20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述电子装置20的操作系统和各类应用软件，例如配置中心信息同步系统60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述电子装置20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述配置中心信息同步系统60等。

所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述电子装置20与其他电子设备之间建立通信连接。

实施例七

如图12所示，为本申请第七实施例提出一种配置中心信息同步系统60的模块示意图。所述配置中心信息同步系统60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。

在本实施例中，所述配置中心信息同步系统60包括：

设置模块600，用于在本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表。

交互模块602，用于与其他服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表。

上述各个模块的具体功能及实现过程参阅前面各个实施例的说明，在此不再赘述。

本实施例提出的配置中心信息同步系统，可以通过Gossip协议实现服务端各个服务器节点之间自己管理服务器信息，解决了配置中心服务端对第三方中间件(服务发现中间件或Nginx代理服务器)强依赖的问题，对服务端进行去中心化，降低了服务的复杂度，并且保证了配置中心服务端的最终数据一致性，防止第三方中间件的故障对配置中心造成影响。

实施例八

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有配置中心信息同步程序，所述配置中心信息同步程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的配置中心信息同步方法的步骤。

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

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

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请实施例的优选实施例，并非因此限制本申请实施例的专利范围，凡是利用本申请实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请实施例的专利保护范围内。

Claims (15)

1.一种配置中心信息同步方法，其特征在于，所述方法包括：

在所述配置中心每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表；

所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表，包括：

第一节点发送本地最新的第一配置信息至第二节点；

所述第二节点比较本地数据与所述第一配置信息，并将比所述第一配置信息更加新的第二配置信息返回至所述第一节点；

所述第一节点比较本地数据与所述第二配置信息，更新所述第二配置信息到本地，并将比所述第二配置信息更加新的第三配置信息返回至所述第二节点；

所述第二节点更新所述第三配置信息到本地。

2.根据权利要求1所述的配置中心信息同步方法，其特征在于，所述方法还包括：

当所述配置中心新增服务器节点时，通过UDP协议通知所述配置中心每个服务器节点，并更新所述第二信息表。

3.根据权利要求2所述的配置中心信息同步方法，其特征在于，所述当所述配置中心新增服务器节点时，通过UDP协议通知所述配置中心每个服务器节点，并更新所述第二信息表包括：

当所述当前服务器节点新增至所述配置中心时，遍历所述配置中心的服务器地址列表，通过UDP协议向所述服务器地址列表中的所有其他服务器节点发送新增通知；

所述当前服务器节点和每个所述其他服务器节点之间相互配对，通过所述推送-拉取-拉取模式交换配置信息，并将对方的配置信息更新至所述第二信息表。

4.根据权利要求2或3所述的配置中心信息同步方法，其特征在于，所述当所述配置中心新增服务器节点时，通过UDP协议通知所述配置中心每个服务器节点，并更新所述第二信息表包括：

当所述当前服务器节点接收到第一服务器节点通过UDP协议发送的新增通知时，与所述第一服务器节点之间相互配对，通过所述推送-拉取-拉取模式交换配置信息，并将对方的配置信息更新至所述第二信息表。

5.根据权利要求1至4任一项所述的配置中心信息同步方法，其特征在于，所述方法还包括：

通过失效检测器计算所述服务器节点之间心跳间隔的平均时间，当检测到第二服务器节点的最后在线时间和系统时间之差超过所述平均时间时，判断所述第二服务器节点已经下线，将所述第二服务器节点从所述第二信息表中移除。

6.根据权利要求1至5任一项所述的配置中心信息同步方法，其特征在于，所述方法还包括：

当第三服务器节点上线时，从所述配置中心中随机选择多个其他服务器节点进行配对，并且每对服务器节点之间通过所述推送-拉取-拉取模式交换配置信息，直至所有服务器节点中的信息一致。

7.根据权利要求1至6任一项所述的配置中心信息同步方法，其特征在于，所述方法还包括：

当所述配置中心任意一个服务器节点接收到用户更新配置信息的通知后，通过UDP协议通知所述配置中心其他服务器节点进行更新。

8.根据权利要求7所述的配置中心信息同步方法，其特征在于，所述接收到用户更新配置信息的通知包括接收到配置中心管理端发送的用户在配置中心管理页面更新配置信息的通知或者接收到客户端发送的用户更新配置信息的请求。

9.根据权利要求8所述的配置中心信息同步方法，其特征在于，所述配置中心管理端或所述客户端将所述通知或所述请求发送至所述配置中心的任意一个种子服务器节点，所述种子服务器节点将更新通知通过UDP协议发送至所述配置中心其他服务器。

10.根据权利要求7至9任一项所述的配置中心信息同步方法，其特征在于，所述当所述配置中心任意一个服务器节点接收到用户更新配置信息的通知后，通过UDP协议通知所述配置中心其他服务器节点进行更新包括：

当所述当前服务器节点接收到用户更新配置信息的通知后，与所述本地文件中缓存的配置信息进行对比；

当对比结果不一致时，将更新的配置信息保存至配置中心数据库中，并更新所述本地文件；

遍历所述配置中心的服务器地址列表，向所述服务器地址列表中的其他服务器节点发送更新通知，以使所述其他服务器节点通过访问所述配置中心数据库获取所述更新的配置信息。

11.根据权利要求7或10所述的配置中心信息同步方法，其特征在于，所述当所述配置中心任意一个服务器节点接收到用户更新配置信息的通知后，通过UDP协议通知所述配置中心其他服务器节点进行更新包括：

当所述当前服务器节点接收到所述其他服务器节点发送的所述更新通知时，访问所述配置中心数据库，从所述配置中心数据库中获取所述更新通知对应的所述更新的配置信息。

12.一种配置中心系统，其特征在于，所述系统包括：

管理端，用于接收用户在配置中心管理页面设置或更新的配置信息，并将更新通知发送至所述配置中心的任意一个种子服务器节点；

数据库，用于保存所述设置或更新的配置信息；

服务端，包括多个服务器节点，每个服务器节点的本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表；

所述配置中心两个服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表，包括：

第一节点发送本地最新的第一配置信息至第二节点；

所述第二节点比较本地数据与所述第一配置信息，并将比所述第一配置信息更加新的第二配置信息返回至所述第一节点；

所述第一节点比较本地数据与所述第二配置信息，更新所述第二配置信息到本地，并将比所述第二配置信息更加新的第三配置信息返回至所述第二节点；

所述第二节点更新所述第三配置信息到本地。

13.一种配置中心信息同步系统，其特征在于，所述系统包括：

设置模块，用于在本地文件中设置记录当前服务器节点配置信息的第一信息表和记录配置中心其他服务器节点的配置信息的第二信息表；

交互模块，用于与其他服务器节点之间相互配对，每对服务器节点之间通过推送-拉取-拉取模式交换配置信息，以更新所述第二信息表，包括：

第一节点发送本地最新的第一配置信息至第二节点；

所述第二节点比较本地数据与所述第一配置信息，并将比所述第一配置信息更加新的第二配置信息返回至所述第一节点；

所述第一节点比较本地数据与所述第二配置信息，更新所述第二配置信息到本地，并将比所述第二配置信息更加新的第三配置信息返回至所述第二节点；

所述第二节点更新所述第三配置信息到本地。

14.一种电子装置，其特征在于，所述电子装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的配置中心信息同步程序，所述配置中心信息同步程序被所述处理器执行时实现如权利要求1至11中任一项所述的配置中心信息同步方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有配置中心信息同步程序，所述配置中心信息同步程序被处理器执行时实现如权利要求1至11中任一项所述的配置中心信息同步方法。

Images