CN115914221A - 一种分布式集群选主方法及服务器 - Google Patents

Abstract

本申请涉及计算机技术领域，具体涉及一种分布式集群选主方法及服务器。该方法包括：第一主控节点监控第一主控节点和每个业务节点之间的链路；当第一主控节点和所有业务节点中的至少P个业务节点之间的链路发生异常时，第一主控节点触发选主流程，选主流程用于从多个控制节点中重新选择一个控制节点作为第二主控节点，第二主控节点用于代替第一主控节点，控制业务节点执行业务，其中P为大于等于1的整数。该方法可以提高业务节点执行业务的稳定性。

Description

一种分布式集群选主方法及服务器

技术领域

本申请涉及计算机技术领域，特别涉及一种分布式集群选主方法及服务器。

背景技术

随着计算机技术以及通信技术的发展，很多业务系统采用分布式集群(distributed cluster)架构，以实现更好的负载均衡等，从而能够更好地为用户提供相关服务。在分布式集群架构中，不同功能分布在集群中不同节点(node)上，这些节点共同实现业务。通常，分布式集群包括由多个控制节点组成的控制子集群、由多个业务节点组成的业务子集群。其中，业务子集群中的业务节点用于执行业务。控制子集群中的控制节点用于控制业务节点，例如，将业务请求分配给哪些业务节点，以便这些业务节点处理该业务请求。

控制子集群中一个控制节点作为主控节点(master)，其他控制节点作为从节点(slave)。其中，主控节点用于控制业务节点。当主控节点的状态异常时，需要从控制子集群中重新选择主控节点。目前，主控节点的状态由从节点监控。因此，可能出现从节点对主控节点的监控结果显示主控节点的状态正常，而主控节点和业务节点之间的链路异常的情况，在这种情况下，主控节点不能有效控制业务节点，并且控制子集群也不能重新选举主控节点，从而导致业务子集群难以提供服务。

发明内容

本申请实施例提供了一种分布式集群选主方法及服务器，可以提高业务节点执行业务的稳定性。

第一方面，提供了一种分布式集群选主方法，所述分布式集群包括多个控制节点和多个业务节点，其中，所述多个控制节点中的一个控制节点作为第一主控节点，用于控制所述业务节点执行业务；所述方法包括：所述第一主控节点监控所述第一主控节点和每个所述业务节点之间的链路；当所述第一主控节点和所有所述业务节点中的至少P个业务节点之间的链路发生异常时，所述第一主控节点触发选主流程，所述选主流程用于从所述多个控制节点中重新选择一个控制节点作为第二主控节点，所述第二主控节点用于代替所述第一主控节点，控制所述业务节点执行业务，其中P为大于等于1的整数。

该方法通过监控主控节点和业务节点之间的链路，来判断是否触发选主流程，从而可以在主控节点和业务节点之间的链路异常时，可以重新选择或选举主控节点，从而保障了业务节点可以得到主控节点的有效控制，提高了业务执行的稳定性。

在一种可能的实施方式中，所述第一主控节点通过所述第一主控节点和所述业务节点之间的心跳报文，感知所述第一主控节点和所述业务节点之间的链路的状态；所述第一主控节点监控所述第一主控节点和每个所述业务节点之间的链路包括：所述第一主控节点统计在预设时长的时间段内所述第一主控节点和所述业务节点之间的丢失心跳报文的数量；当所述第一主控节点和所述业务节点之间的丢失心跳报文的数量不小于第一阈值时，确认所述第一主控节点和所述业务节点之间的链路发生异常。

在一种可能的实施方式中，在所述多个控制节点通过投票选举主控节点的情况下，所述方法还包括：所述第一主控节点不投票给所述第一主控节点；或者，所述分布式集群还包括控制器，所述方法还包括：延迟所述第一主控节点尝试在所述控制器路径下创建临时节点的开始时刻；或者，所述分布式集群还包括哨兵，所述方法还包括：所述哨兵从其他控制节点中选择第二主控节点，所述其他控制节点为所述多个控制节点中除所述第一主控节点之外的节点。

该实施方式可以降低原主控节点再次称为主控节点的可能性，从而提高了新的主控节点和业务节点之间具有较好的链路的可能性。

在一种可能的实施方式中，所述第一主控节点触发选主流程包括：所述第一主控节点指示所述多个控制节点中的每个控制节点进入所述选主流程。

在一种可能的实施方式中，所述多个控制节点包括至少一个第一控制节点和至少两个第二控制节点，所述第一主控节点属于所述第二控制节点，所述第一主控节点触发选主流程包括：所述第一主控节点通知所述第一控制节点；所述第一控制节点指示所述至少两个第二控制节点中每个控制节点进入所述选主流程，或者所述第一控制节点指定所述至少两个第二控制节点中的一个控制节点作为第二主控节点。

在一种可能的实施方式中，所述方法还包括：所述多个控制节点中每个控制节点，监控所述第一主控节点的状态，并在监控到所述第一主控节点的状态发生异常时，进入所述选主流程。

该实施方式可以与现有的选主流程触发机制兼容，从而保障了可在多种情况下触发选主流程。

第二方面，提供了一种第一服务器，所述第一服务器与多个第二服务器通信连接，所述第一服务器包括处理器以及与所述处理器耦合的接收端口；其中，所述接收端口用于接收每个所述第二服务器的心跳报文；所述处理器用于基于所述第二服务器的心跳报文，监控所述第一服务器和所述第二服务器之间的链路；以及，用于在所述第一服务器和所有所述第二服务器中至少P个第二服务器之间的链路发生异常时，触发选主流程，所述选主流程用于从多个控制服务器中重新选择一个服务器作为主控服务器，所述主控服务器用于代替所述第一服务器，控制所述第二服务器执行业务，其中P为大于等于1的整数。

在一种可能的实施方式中，所述处理器还用于：统计在预设时长的时间段内所述第一服务器和所述第二服务器之间的丢失心跳报文的数量；当所述第一服务器和所述第二服务器之间的丢失心跳报文的数量不小于第一阈值时，确认所述第一服务器和所述第二服务器之间的链路发生异常。

在一种可能的实施方式中，所述处理器还用于：指示所述多个控制服务器中每个服务器进入所述选主流程。

在一种可能的实施方式中，所述第一服务器还与管理服务器通信连接，所述处理器还用于通知所述管理服务器，以使所述管理服务器指示每个所述控服务器进行选主流程或者指定所述多个控制服务器中的一个服务器作为主控服务器。

第三方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面提供的方法。

第四方面，本申请实施例提供一种计算机程序产品，所述计算机程序产品存储有指令，所述指令在由计算机执行时，使得所述计算机实施第一方面提供的方法。

附图说明

图1为本申请实施例提供的一种分布式集群的结构示意图；

图2为本申请实施例提供的一种分布式集群的结构示意图；

图3为本申请实施例提供的一种分布式集群的结构示意图；

图4为本申请实施例提供的一种分布式集群的结构示意图；

图5为本申请实施例提供的一种分布式集群选主方法的流程图；

图6为本申请实施例提供的一种分布式集群选主方法的流程图；

图7A为本申请实施例提供的一种心跳报文统计结果的示意图；

图7B为本申请实施例提供的一种心跳报文统计结果的示意图；

图7C为本申请实施例提供的一种心跳报文统计结果的示意图；

图7D为本申请实施例提供的一种心跳报文统计结果的示意图；

图8为本申请实施例提供的一种丢失报文统计结果的示意图；

图9A为本申请实施例提供的一种分布式集群切换主控节点的结构示意图；

图9B为本申请实施例提供的一种分布式集群切换主控节点的结构示意图；

图9C为本申请实施例提供的一种分布式集群切换主控节点的结构示意图；

图10为本申请实施例提供的一种服务器的示意性框图。。

具体实施方式

下面将结合附图，对本申请实施例中的技术方案进行描述。显然，所描述的实施例仅是本申请实施例一部分实施例，而不是全部的实施例。

在本申请实施例的描述中“一个实施例”或“一些实施例”等意味着在本申请实施例的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本申请实施例中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。

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

在本申请实施例的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

分布式集群由多个节点组成。这些节点可以包括多个控制节点以及多个业务节点。其中，多个控制节点可以包括主控节点和从节点。主控节点也可以称为集群主、领导者(leader)，用于控制业务节点执行业务，例如分配业务请求、以及监控业务节点是否能够正常工作等。从节点也可以称为集群备、备份节点、跟随者(follower)。从节点作为主控节点的备份，用于在主控节点异常时，取代异常的主控节点，成为新的主控节点。业务节点也可称为观察者(observer)、集群成员(member)，受主控节点的控制，提供具体业务服务。

以提供数据存储服务的分布式存储集群(distributed storage cluster)为例，主控节点可以记录业务节点和数据的映射关系表。其中，映射关系表包括多条映射关系，其中，映射关系表明业务节点存储映射了到该业务节点的数据。主控节点在接收到访问请求时，可以在映射关系表中，查询访问请求所请求访问的数据对应的业务节点，进而将访问请求转发到该业务节点。

主控节点对分布式集群的业务实现至关重要，当主控节点出现异常时，需要尽快替换，以保障集群业务可以正常实现。

可以通过选主流程，从分布式集群的多个控制节点中选择一个控制节点作为主控节点。其中，常见的选主流程有动物园管理员(zookeeper)投票机制下的选主流程、卡夫卡(kafka)控制器(controller)选举机制下的选主流程以及redis哨兵(sentinel)指定机制下的选主流程。其中，zookeeper为一种分布式协调服务，可用于服务发现、分布式锁、分布式主控节点选举、配置管理等。

其中，触发zookeeper投票机制下的选主流程的场景有2个，分别为：分布式集群启动节点，以及主控节点在分布式集群运行期间发生异常。这两个场景中的选主流程的具体过程基本一致，下面以主控节点在分布式集群运行期间发生异常的场景为例，对选主流程进行说明。

分布式集群中每个控制节点均检测主控节点的状态。其中，备份节点通过监控主控节点向该备份节点发送的心跳报文，来监控主控节点的状态。当心跳报文超时时，备份节点可以确认主控节点发生异常。其中，心跳报文超时是指连续N个心跳报文丢失。其中，N为大于1的整数，N的值具体可以由开发者自由设置。对应备份节点而言，主控节点的心跳报文超时可以表明主控节点的心跳断开，即备份节点检测不到主控节点心跳。

当备份节点确认主控节点发生异常时，该备份节点可以进入选举状态。其中，选举状态也可以称为看(looking)状态，是一种选举主控节点的状态。主控节点可以通过监控自身的进程，来监控自身的状态，从而可以发现主控节点的状态是否异常。当主控节点发现自身异常时，主控节点也进入选举状态。

每个控制节点在进入选举状态后，会为自己称为主控节点投选票，然后将所投选票广播至其他控制节点。每个控制节点接收到其他控制节点发送的选票，并进行合法性校验。其中，合法性校验包括对选票所在的选举轮次进行校验，以及对发送选票的控制节点的状态进行校验。

控制节点比较投给自身的选票以及投给其他控制节点的选票，比较规则具体为：比较比较控制节点的事物标识(ZXID)，大者获胜；然后，若选票的事物标识相同，则比较控制节点的自身事物标识(MYID)，大者获胜。其中，失败者的控制节点将选票投给获胜者；然后，失败者以及获胜者各自将各自更新后的选票广播至其他控制节点。若有的节点的选票数量超过分布式集群中控制节点总数的一半时，该控制节点被选举为新的主控节点。若没有，则进行下一轮比较和投票。其中，在选举主控节点时，首先比较控制节点的事物标识，可以保障新的主控节点的数据是最新的。另外，采用zookeeper投票机制的分布式集群中控制节点的个数为奇数，以避免选票数量不超过半数的情况出现。

新的主控节点将自己的身份标识更新为领导者(leader)，其他控制节点的身份标识更新为或者继续保持为跟随者(follower)。

在kafka控制器选举机制中，分布式集群中的控制节点可以分为高级控制节点和低级控制节点，其中，高级控制节点有至少一个，低级控制节点有多个。其中，低级控制节点也可以称为缓存代理(broker)。kafka控制器选举机制下的选主流程为，高级控制节点用于从低级控制节点中选择主控节点，具体流程如下。

一个高级控制节点可以为控制器。多个低级控制节点采取竞争机制在控制器路径下创建临时节点。成功创建临时节点的低级控制节点称为主控节点。控制器可以监控其路径下的临时节点的状态。当临时节点的状态异常时，控制器将该临时节点删除，并通知所有低级控制节点采取竞争机制，重新在路径下创建临时节点，从而选择出新的主控节点。

采用redis哨兵(sentinel)指定机制的分布式集群中的控制节点可以分为哨兵和普通控制节点。其中，哨兵也可以理解为高级控制节点，普通控制节点也可以理解为低级控制节点。其中，哨兵有至少一个，普通控制节点有多个。哨兵指定机制下的选主流程为：哨兵从多个普通控制节点中指定主控节点，并监控主控节点和备份节点。当主控节点的状态异常(哨兵接收主控节点发送的心跳报文超时)时，哨兵可以再次从多个普通控制节点中指定新的主控节点。

在上述机制中，只有当备份节点或者高级控制节点发现到主控节点的状态发生异常时，才触发选主流程。特别是，在zookeeper投票机制以及哨兵指定机制中，需要备份节点或者哨兵监控到主控节点的心跳断开(即心跳报文超时)，才能确认主控节点的状态异常，进而触发选主流程。现实中一种常见的情况为，备份节点或者高级控制节点未发现主控节点异常，而由于业务节点和主控节点之间的链路或者说网络不稳定(例如拥塞、丢包)等因素，导致主控节点和业务节点之间无法正常通信，进而影响业务的执行。

本申请实施例提供了一种分布式集群选主方法，可以监控主控节点和业务节点之间的链路，并在主控节点和业务节点之间的链路发生异常时，触发选主流程，从而选择出新的主控节点，来控制业务节点执行业务，从而保障了业务能够正常执行。

接下来，对本申请实施例提供的分布式集群选主方法进行具体介绍。

首先，介绍本申请实施例提供的分布式集群选主方法可应用的系统架构。

图1示出了本申请实施例提供的一种分布式集群100的结构示意图。分布式集群100包括：控制节点111、控制节点112、控制节点113等多个控制节点，以及业务节点121、业务节点122、业务节点123、业务节点124、业务节点125、业务节点126等多个业务节点。其中，多个控制节点可以通过zookeeper投票机制，选举出主控节点。例如，选举控制节点111用作主控节点。主控节点可以控制该多个业务节点中每个业务节点执行业务。在选举出主控节点后，主控节点可以和所述多个业务节点中每个业务节点建立通信链路，以通过通信链路和业务节点进行信息交互，从而控制业务节点执行业务。其中，主控节点也和其他控制节点建立通信链路，使得其他控制节点可以通过通信链路监控主控节点的状态。

图2示出了本申请实施例提供的另一个分布式集群200的结构示意图。分布式集群200包括：一级控制节点211、一级控制节点212、一级控制节点213等多个一级控制节点，以及业务节点221、业务节点222、业务节点223等多个由一级控制节点控制的业务节点。其中，多个一级控制节点可以通过zookeeper投票机制，选举出一级主控节点。例如，选举一级控制节点211用作主控节点。其中，一级主控节点可以控制业务节点221、业务节点222、业务节点223等多个由一级控制节点控制的业务节点执行业务。在选举出一级主控节点后，一级主控节点可以和多个由一级控制节点控制的业务节点中每个业务节点建立通信链路，以通过通信链路和业务节点进行信息交互，从而控制业务节点执行业务。其中，一级主控节点也和其他一级控制节点建立通信链路，使得其他一级控制节点可以通过通信链路监控一级主控节点的状态。

分布式集群200还可以包括：二级控制节点231、二级控制节点232、二级控制节点233等多个二级控制节点，以及业务节点241、业务节点242、业务节点243等多个由二级控制节点控制的业务节点。

在一些实施例中，一级控制节点的权限大于二级控制节点权限。也就是说，相对于二级控制节点，一级控制节点为高级控制节点。或者说，相对于一级控制节点，二级控制节点为低级控制节点。一级控制节点的权限大于二级控制节点权限具体体现为：从多个一级控制节点选举出的一级主控节点可以管理或控制二级控制节点，例如，从多个二级控制节点中，直接指定主控节点。

在一些实施例中，多个二级控制节点可以通过zookeeper投票机制，选举出二级主控节点。例如，选举二级控制节点311用作主控节点。其中，二级主控节点可以控制业务节点241、业务节点242、业务节点243等多个由二级控制节点控制的业务节点执行业务。

在选举出二级主控节点后，二级主控节点可以和多个由二级控制节点控制的业务节点中每个业务节点建立通信链路，以通过通信链路和业务节点进行信息交互，从而控制业务节点执行业务。其中，二级主控节点也和其他二级控制节点建立通信链路，使得其他二级控制节点可以通过通信链路监控二级主控节点的状态。

图3示出了本申请实施例提供的又一个分布式集群300的结构示意图。分布式集群300包括：高级控制节点311、高级控制节点312、高级控制节点313等多个高级控制节点，低级控制节点321、低级控制节点322、低级控制节点323等多个低级控制节点，以及业务节点331、业务节点332、业务节点333、业务节点334、业务节点335、业务节点336等业务节点。

其中，该多个高级控制节点可以通过zookeeper投票机制，选举出高级主控节点，例如选举高级控制节点311作为高级主控节点。其中，高级主控节点用作kafka控制器选举机制中的控制器，多个低级控制节点采取竞争机制在控制器路径下创建临时节点。成功创建临时节点的低级控制节点作为低级主控节点。低级主控节点用于控制集群300中的多个业务节点执行业务。

高级主控节点和其他高级控制节点可以建立通信链路，以便其他高级控制节点可以监控高级主控节点的状态。并且，高级主控节点和每个低级控制节点可以建立通信链路，以便低级控制节点可以在高级主控节点路径下创建临时节点。

低级主控节点和每个业务节点可以建立通信链路，以便低级主控节点可以控制业务节点执行业务。并且，低级主控节点和其他低级控制节点可以建立通信链路，以便其他低级控制节点可以监控低级主控节点的状态。

图4示出了本申请实施例提供的又一个分布式集群400的结构示意图。分布式集群400包括：控制节点411、控制节点421、控制节点422、控制节点423等多个控制节点，以及业务节点431、业务节点432、业务节点433、业务节点434、业务节点435、业务节点436等业务节点。

其中，分布式集群400可以采用redis哨兵指定机制，选择主控节点。其中，控制节点411可以作为哨兵，其他的控制节点作为普通控制节点。哨兵可以从多个普通控制节点中，指定主控节点。主控节点用于控制集群400中的多个业务节点执行业务。

哨兵以及控制节点423、控制节点422连接到主控节点421，以便监控主控节点421的状态。并且，每个业务节点连接到主控节点421，以便主控节点421可以控制业务节点执行业务。

上文示例介绍了可以用于实施本申请实施例提供的分布式集群选主方法的系统架构，并非穷尽。本申请实施例提供的分布式集群选主方法还可以在采用其他架构的分布式集群中实施，在此不再一一列举。

在本申请实施例中，当对控制节点、业务节点以及高级控制节点、低级控制节点、哨兵不做特别区分时，它们可以被简称为节点。

在一些实施例中，节点可以通过硬件方式实现。例如，执节点可以为计算设备，例如服务器。再例如，节点可以为芯片、处理器或者多核处理器上的一个或多个计算核心。在一些实施例中，节点可以通过软件实现。例如，节点可以为应用程序(application，APP)。再例如节点可以为一个或多个进程(process)。再例如，节点可以为一个或多个线程(thread)。本申请实施例对节点的具体实现形式不再具体限定。

上文示例介绍了分布式集群的系统架构以及节点的实现形式。接下来，以在图1-图4所示的分布式集群中的应用为例，介绍本申请实施例提供的分布式集群选主方法的执行流程。

参阅图5，该方法包括如下步骤。

步骤501，第一主控节点监控所述第一主控节点和每个所述业务节点之间的链路。

第一主控节点是指分布式集群的当前主控节点。以图1所示的架构为例，第一主控节点是指用作主控节点的控制节点111，以图2所示的架构为例，第一主控节点是指一级控制节点211或者二级控制节点231。以图3所示的架构为例，第一主控节点是指低级控制节点321。以图4所示的架构为例，第一主控节点是指控制节点421。

其中，主控节点和业务节点之间的链路是指主控节点和业务节点进行信息交互的网络通道。例如，主控节点可以通过该链路将业务请求，转发至业务节点。

在步骤501中，第一主控节点或者说当前主控节点，可以监控它和每个业务节点之间的链路是否异常。

在一些实施例中，第一主控节点可以通过第一主控节点和每个业务节点之间的心跳报文，感知第一主控节点和该业务节点之间的链路的状态。以图1所示架构中的主控节点111和业务节点121为例。业务节点121可以向主控节点111发送心跳报文，以使主控节点111能够感知业务节点121的存在。业务节点121向主控节点111发送的心跳报文能否正常达到主控节点111，受限于主控节点111和业务节点121之间的链路A1的状态。因此，主控节点111可以利用接收业务节点121发送的心跳报文的情况，得知或者判断主控节点111和业务节点121之间的链路A1的状态。其中，链路A的状态可以分为正常状态和异常状态。具体如下。

业务节点121可以按照预设的发送周期，向主控节点111发送心跳报文。即每间隔时间段t1，向主控节点111发送一个心跳报文。时间段t1为发送周期的周期长度。其中，时间段t1的时长可以预先设定，并且，主控节点111可以获取时间段t1。

主控节点111可以统计时间段T1内的主控节点111和业务节点121之间的丢失报文的数量。其中，时间段T1的时长为时间段t1的M倍。即在时间段T1内，业务节点121向主控节点111发送M个心跳报文。其中，M为大于1的整数。其中，丢失报文是指发送端发出的，接收端没收到的报文。主控节点111和业务节点121之间的丢失报文是指业务节点121向主控节点111发送的，主控节点111没有接收到的报文。具体而言，在时间段T1内，主控节点111总共接收到了(M-N)个来自业务节点121的心跳报文。而如上所述，在一个时间段T1内，业务节点121向主控节点发送了M个心跳报文。那么丢失报文的数量＝M-(M-N)＝N个。其中，N为小于M，且大于或等于0的整数。

其中，N个丢失报文可能是连续丢失的N个心跳报文，或者说，丢失的N个心跳报文的发送时间是依次相邻的。也就是说，主控节点111在N个连续的时间段t1内，均没有收到业务节点121发送的心跳报文。其中，连续丢失的心跳报文可以称为连续丢失报文。在一个例子中，如图7A所示，可以设定时间段t1的时长为1秒(s)，在第4秒、第5秒以及第6秒，均没有收到业务节点121发送的心跳报文，则主控节点111和业务节点121之间具有连续丢失的3个心跳报文。在另一个例子中，如图7B所示，可以设定时间段t1的时长为1秒，在第10秒、第11秒以及第12秒，均没有收到业务节点121发送的心跳报文，则主控节点111和业务节点121之间具有连续丢失的3个心跳报文。

N个丢失报文可能是间隔丢失的N个心跳报文，即该N个丢失报文的发送时间不是依次相邻。间隔丢失的心跳报文可以称为间隔丢失报文。在一个例子中，如图7C所示，以设定时间段t1的时长为1秒，在第1秒、第3秒以、第4秒、第6秒以及第8秒，均没有收到业务节点121发送的心跳报文，则主控节点111和业务节点121之间具有间隔丢失的5个心跳报文。在另一个例子中，如图7D所示，以设定时间段t1的时长为1秒，在第6秒、第8秒以、第9秒、第11秒以及第13秒，均没有收到业务节点121发送的心跳报文，则主控节点111和业务节点121之间具有间隔丢失的5个心跳报文。

在一些实施例中，如图7A-图7D所示，可以采用滑动窗口统计机制，以时间段T1为时间窗口，以时间段t的时长为步长(即一个时间窗口的开始时间和上一个时间窗口的开始时间相差一个时间段t，即相差一个心跳报文发送间隔)，依次统计每个时间窗口中的丢失报文的数量。

在一些实施例中，时间段T1的时长小于主控节点和控制层面上的监控节点之间的心跳超时的时长。其中，主控节点的控制层面上的监控节点是指该主控节点对应的备份节点或者哨兵。以图1所示的架构为例，主控节点111的控制层面上的监控节点是指控制节点112和控制节点113。以图4所示的架构为例，主控节点4211的控制层面上的监控节点是指控制节点411。如此，可以能够在主控节点和控制层面上的监控节点之间的心跳还未超时时，可以监控到主控节点和业务节点之间的链路异常，进而触发选主流程。

回到图5，本申请实施例提供的分布式集群选主方法还包括：步骤502，当所述第一主控节点和所有业务节点中的至少P个所述业务节点之间的链路发生异常时，所述第一主控节点触发选主流程，所述选主流程用于从所述多个控制节点中重新选择一个控制节点作为第二主控节点，所述第二主控节点用于代替所述第一主控节点，控制所述业务节点执行业务。其中，所有业务节点是指分布式集群中所有由第一主控节点控制的业务节点。

P为大于或等于1的整数，且P小于或等于由第一主控节点控制的业务节点的数量。示例性的，P为预设值，可以被自由配置，例如，P为3、5或7等。示例性的，P的大小与由第一主控节点控制的业务节点的数量M1正相关。其中，P与M1的比值小于或等于1。在一个例子中，P与M1的比值等于1/3。在另一个例子中，P与M1的比值等于1/2。等等，此处不再一一列举。

在步骤502，第一主控节点可以根据步骤501的监控结果，得到或判断第一主控节点和业务之间的链路的状态，并在第一主控节点和P个业务节点之间的链路的状态为异常状态时，第一主控节点触发选主流程。

接下来，仍以主控节点111为例，示例介绍触发选主流程的具体过程。其中，为方便描述，可以将与主控节点之间链路的状态为异常状态的业务节点称为异常节点。

参阅图6，主控节点111可以在步骤601，可以确定异常节点，以及统计异常节点的数量。

以确定业务节点121是否为异常节点为例，可以通过方式1判断业务节点是否为异常节点，方式1为：判断时间段T1内，控制节点111和业务节点121之间的丢失报文的数量是否不小于阈值Y1。其中，阈值Y1为预设值，在时间段的时长为时间段t1的M倍时，阈值Y1为小于或等于M，且大于或等于1的整数。其中，当时间段T1内丢失报文的数量不小于阈值Y1时，可以确认链路A1的状态为异常状态。当时间段T1内丢失报文的数量小于阈值Y1时，可以确认链路A1的状态为正常状态，即没有发生异常。

在一些实施例中，还可以通过方式2判断业务节点是否为异常节点。如上所述，丢失报文可以为连续丢失报文和间隔丢失报文，相应地，阈值Y1可以分为阈值Y11和阈值Y12，其中，阈值Y11小于阈值Y12。其中，连续丢失报文的数量较多时，反映了链路可能中断了。因此，可以根据连续丢失报文的数量判断链路的状态(方式21)。间隔丢失报文的数量，反映了链路的丢包率。因此，可以根据间隔丢失报文的数量(方式22)判断链路的状态。只要方式21或方式22任一种方式确定业务节点为异常节点，则该业务节点就为异常节点。通过两种方式共同判断业务节点是否异常能够保证业务节点状态判断的准确性。

在其他实施例中，还可以仅通过方式1或方式2确定业务节点是否为异常节点，或者，仅通过方式21或方式22确定业务节点是否为异常节点。该方案能在一定程度上减小计算负担。

当统计得到的时间段T1内丢失报文的数量为连续丢失报文的数量时，判断连续丢失报文的数量是否不小于阈值Y11。当连续丢失报文的数量不小于阈值Y11时，可以确认链路A1的状态为异常状态。在一个例子中，如图7A所示，在起始时间为第0秒、终止时间为第10秒这一时间段T1中，主控节点111和业务节点121之间具有连续丢失的3个心跳报文，在阈值Y11为3的情况下，即连续丢失的报文的数量不小于阈值Y11，可以确认链路A1发生了异常，即链路A1的状态为异常状态。在另一个例子中，如图7B所示，在起始时间为第2秒、终止时间为第12秒这一时间段T1中，主控节点111和业务节点121之间具有连续丢失的3个心跳报文，在阈值Y11为3的情况下，即连续丢失的报文的数量不小于阈值Y11，可以确认链路A1发生了异常。

当统计得到的时间段T1内丢失报文的数量为间隔丢失报文的数量时，判断间隔丢失报文的数量是否不小于阈值Y12。当间隔丢失报文的数量不小于阈值Y12时，可以确认链路A1的状态为异常状态。其中，在一个例子中，如图7C所示，在起始时间为第0秒、终止时间为第10秒这一时间段T1中，主控节点111和业务节点121之间具有间隔丢失的5个心跳报文，在阈值Y12为5的情况下，即间隔丢失的报文的数量不小于阈值Y12，可以确认链路A1发生了异常。在另一个例子中，如图7D所示，在起始时间为第3秒、终止时间为第13秒这一时间段T1中，主控节点111和业务节点121之间具有间隔丢失的5个心跳报文，在阈值Y12为5的情况下，即间隔丢失的报文的数量不小于阈值Y12，可以确认链路A1发生了异常。

在一些实施例中，如上所述，采用滑动窗口统计机制，以时间段T1为时间窗口，以时间段t的时长为步长(相差一个心跳报文发送间隔)，依次统计每个时间窗口中的丢失报文的数量。如此，可以每当统计到Y1个丢失报文，且Y1个丢失报文中第一个丢失报文和最后一个丢失报文之间的时间间隔不大于时间段T1的时长时，即可确认一个时间段T1的丢失报文的数量不小于阈值Y1，从而可以确认链路发生了异常。

若主控节点111和业务节点121之间的链路发生了异常，可以确定业务节点121为异常节点。若主控节点111和业务节点121之间的链路没有发生异常，可以确定业务节点121不为异常节点。

如此，参考主控节点111确定业务节点111是否为异常节点的方式，主控节点111确定节点其他业务节点(例如业务节点122)是否为异常节点，在此不再一一赘述。

然后，主控节点111可以统计异常节点的数量。

继续参阅图6，主控节点111可以判断异常节点的数量是否大于或等于P。若异常节点的数量大于或等于P，则主控节点111触发选主流程。其中，P的值具体参考上文介绍，在此不再赘述。另外，在本申请实施例中，“大于或等于”可以理解为“不小于”。

在一些实施例中，在图1或图2所示的架构中，在即分布式集群采用zookeeper投票机制的场景中，当异常节点的数量大于或等于P时，第一主控节点可以通过杀死主进程的方式，指示备份节点进入选主流程，进而触发选主流程。其中，主进程的功能包括向备份节点发送心跳报文。主进程被杀死后，第一主控节点不再向备份节点发送心跳报文。如此，当备份节点在心跳报文超时时，可以进入选举状态，进而可以进入选主流程。其中，当第一主控节点为控制节点111时，备份节点是控制节点112和控制节点113。

在一些实施例中，在图1或图2所示的架构中，在即分布式集群采用zookeeper投票机制的场景中，当异常节点的数量大于或等于P时，第一主控节点可以通知各个备份节点进入选举状态，从而进入选主流程。

在一些实施例中，在图1或图2所示的架构中，在即分布式集群采用zookeeper投票机制的场景中，当异常节点的数量大于或等于P时，第一主控节点可以通过停发心跳报文的方式，指示备份节点进入选主流程，从而触发选主流程。其中，停发心跳报文是指不再向备份节点发送心跳报文。如此，当备份节点在心跳报文超时时，可以进行选举状态，进而可以进入选主流程。

其中，在图1或图2所示的架构中，当第一主控节点为一级控制节点211时，备份节点为一级控制节点212和一级控制节点213。当第一主控节点为二级控制节点231时，备份节点为二级控制节点232和二级控制节点233。另外，第一主控节点可以主动进入选举状态，以进入选主流程。即第一主控节点可以指示自身进入选主流程。

在一些实施例中，在图2所示的架构中，当异常节点的数量大于或等于P时，且第一主控节点为二级主控节点231时，第一主控节点(即二级主控节点231)可以向一级主控节点211发送请求消息，该请求信息用于请求一级主控节点重新指定二级主控节点，从而触发选主流程。

在一些实施例中，在图3所示的架构中，即在分布式集群采用kafka控制器选举机制的场景下，当异常节点的数量大于或等于P异常时，第一主控节点(即低级主控节点321)可以高级主控节点(即高级控制节点311)发送请求信息，该请求信息用于请求高级主控节点将控制器路径下的临时节点删除，从而可以触发或指示每个备份节点(低级控制节点322、低级控制节点323、以及低级控制节点321)进入选主流程。

在一些实施例中，在图4所示的架构中，即在分布式集群采用redis哨兵指定机制的场景下，当异常节点的数量大于或等于P时，第一主控节点(即主控节点421)可以向哨兵(即高级控制节点411)发送请求信息，该请求信息用于请求哨兵重新选择主控节点，从而触发选主流程。

其中，选主流程用于从多个控制节点中重新选择一个控制节点作为第二主控节点，第二主控节点用于代替第一主控节点，控制业务节点执行业务。具体如下，

在一些实施例中，在选主流程触发后，可以按照现有的zookeeper投票机制、kafka控制器选举机制或者redis哨兵指定机制中规定的选主流程，选择新的主控节点。具体可以参考上文介绍，在此不再赘述。

在一些实施例中，第一主控节点成为第二主控节点的可能性小于其他控制节点成为第二主控节点的可能性，其他控制节点为多个控制节点中除第一主控节点之外的节点。也就是说，原主控节点成为新的主控节点的可能性小于其他控制节点成为新的主控节点的可能性。具体如下。

在图1或图2所示的架构中，参阅图6，进入选举状态的节点，在进行选主投票前，可以判断本节点是否原主控节点(例如主控节点111)。若不为原主控节点，则执行步骤6032a，按照现有的zookeeper投票机制，将选票投给自己。若为原主控节点，则执行步骤6032b不给自己投票，从而降低原主控节点成为新的主控节点的可能性。然后，比较，失败者将选票投给胜利者。之后，执行步骤6033，判断是否选举出新的主控节点，即是否有控制节点的选票数量超过控制节点总数的一半。若没有则进行下一轮比较和投票。直到选择出新的主控节点。当选出新的主控节点后，新的主控节点可以执行步骤6034，替代原主控节点，继续控制业务节点执行业务。

在一个例子中，参阅图9A，经过上述方案，可以选择控制节点112作为新的主控节点。控制节点112可以替代控制节点111，继续控制业务节点执行业务。

在图3所示的架构中，各低级控制节点通过竞争机制在控制器路径下创建临时节点时，相比其他低级控制节点，原主控节点在延长时间段T2后，才尝试在控制器路径下创建临时节点，从而降低原主控节点成为新的主控节点的可能性。

在一个例子中，参阅图9B，经过上述方案，可以选择低级控制节点322作为新的主控节点。低级控制节点322可以替代低级控制节点321，继续控制业务节点执行业务。

在图4所示的架构中，哨兵在指定新的主控节点时，不选择原主控节点，而是从备份节点中指定主控节点。

在一个例子中，参阅图9C，经过上述方案，可以选择控制节点422作为新的主控节点。控制节点422可以替代控制节点421，继续控制业务节点执行业务。

如上所述，本申请实施例提供的分布式集群选主方法与现有的选主流程触发机制(即zookeeper投票机制下的选主流程触发机制、卡夫卡控制器选举机制下的选主流程触发机制以及redis哨兵指定机制下的选主流程触发机制)不冲突。因此，本申请实施例提供的分布式集群选主方法可以与现有的选主流程触发机制兼容。

具体而言，在图1所示的架构中，控制节点112和控制节点113仍然可以监控主控节点111的状态，并在发现主控节点111的状态异常时，并且各控制节点没有处于选主流程中时，可以进入选举状态，开始重新选举主控节点。具体可以参考上文介绍。

在图3所示的架构中，控制器仍然可以监控其路径下的临时节点的状态。当临时节点的状态异常时，且各控制节点没有处于选择流程中时，控制器将该临时节点删除，并通知所有低级控制节点采取竞争机制，重新在路径下创建临时节点，从而选择出新的主控节点。

在图4所示架构中，哨兵仍然可以监控主控节点和备份节点。当主控节点的状态异常时，并且各普通控制节点没有处于选主流程中时，哨兵可以再次从多个普通控制节点中指定新的主控节点。

本申请实施例提供的分布式集群选主方法，可以在主控节点和业务节点之间的链路发生异常时，触发选主流程。该方法避免了备份节点或者高级控制节点未发现主控节点异常，而由于业务节点和主控节点之间的链路或者说网络不稳定(例如拥塞、丢包)等因素，导致主控节点和业务节点之间无法正常通信，进而影响业务的执行的问题。并且该方法可以降低原来的主控节点再次成为主控节点，从而保障了新的主控节点和业务节点之间具有较好的链路。

本申请实施例还提供了一种服务器1000。其中，服务器1000可以为多个第二服务器通信连接。如图10所示，服务器100包括处理器1010，以及与处理器1010耦合的接收端口1020。其中，接收端口1020用于接收每个第二服务器的心跳报文；处理器1010用于基于所述第二服务器的心跳报文，监控所述第一服务器和所述第二服务器之间的链路；以及，用于在所述第一服务器和所有所述第二服务器中至少P个第二服务器之间的链路发生异常时，触发选主流程，所述选主流程用于从多个控制服务器中重新选择一个服务器作为主控服务器，所述主控服务器用于代替所述第一服务器，控制第二服务器节点执行业务，其中P为大于等于1的整数。接收端口1020以及处理器1010的功能可以参考上文对第一主控节点所执行操作的介绍实现，在此不再一一赘述。其中，第二服务器可以为上文所述的业务节点。控制服务器可以为上文所述的控制节点。在一个例子中，多个控制服务器可以为图1所示架构中的多个控制节点。在一个例子中，多个控制服务器可以为图2所示架构中的多个一级控制节点或多个二级控制节点。在一个例子中，多个控制服务器可以为图3所示架构中的多个低级控制节点。在一个例子中，多个控制服务器可以为图4所示架构中除控制节点111之外的其他控制节点。

本申请实施例中还提供了一种计算设备，该计算设备包括处理器，该处理器可以执行如图5所示的方法，并使得该计算设备具有上述保护的技术方案的技术效果。

本申请实施例中还提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行上述图5所示方的法。

本申请实施例中还提供了一种计算机程序产品，所述计算机程序产品存储有指令，所述指令在由计算机执行时，使得所述计算机实施上述图5所示的方法。

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

Claims (10)

1.一种分布式集群选主方法，其特征在于，所述分布式集群包括多个控制节点和多个业务节点，其中，所述多个控制节点中的一个控制节点作为第一主控节点，用于控制所述业务节点执行业务；所述方法包括：

所述第一主控节点监控所述第一主控节点和每个所述业务节点之间的链路；

当所述第一主控节点和所有所述业务节点中的至少P个业务节点之间的链路发生异常时，所述第一主控节点触发选主流程，所述选主流程用于从所述多个控制节点中重新选择一个控制节点作为第二主控节点，所述第二主控节点用于代替所述第一主控节点，控制所述业务节点执行业务，其中P为大于等于1的整数。

2.根据权利要求1所述的方法，其特征在于，所述第一主控节点通过所述第一主控节点和所述业务节点之间的心跳报文，感知所述第一主控节点和所述业务节点之间的链路的状态；

所述第一主控节点监控所述第一主控节点和每个所述业务节点之间的链路包括：

所述第一主控节点统计在预设时长的时间段内所述第一主控节点和所述业务节点之间的丢失心跳报文的数量；

当所述第一主控节点和所述业务节点之间的丢失心跳报文的数量不小于第一阈值时，确认所述第一主控节点和所述业务节点之间的链路发生异常。

3.根据权利要求1或2所述的方法，其特征在于，

在所述多个控制节点通过投票选举主控节点的情况下，所述方法还包括：所述第一主控节点不投票给所述第一主控节点；或者，

所述分布式集群还包括控制器，所述方法还包括：延迟所述第一主控节点尝试在所述控制器路径下创建临时节点的开始时刻；或者，

所述分布式集群还包括哨兵，所述方法还包括：所述哨兵从其他控制节中选择第二主控节点，所述其他控制节点为所述多个控制节点中除所述第一主控节点之外的节点。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述第一主控节点触发选主流程包括：

所述第一主控节点指示所述多个控制节点中的每个控制节点进入所述选主流程。

5.根据权利要求1-3中任一项所述的方法，其特征在于，所述多个控制节点包括至少一个第一控制节点和至少两个第二控制节点，所述第一主控节点属于所述第二控制节点，所述第一主控节点触发选主流程包括：

所述第一主控节点通知所述第一控制节点；

所述第一控制节点指示所述至少两个第二控制节点中每个控制节点进入所述选主流程，或者所述第一控制节点指定所述至少两个第二控制节点中的一个控制节点作为第二主控节点。

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

所述多个控制节点中每个控制节点，监控所述第一主控节点的状态，并在监控到所述第一主控节点的状态发生异常时，进入所述选主流程。

7.一种第一服务器，其特征在于，所述第一服务器与多个第二服务器通信连接，所述第一服务器包括处理器以及与所述处理器耦合的接收端口；其中，

所述接收端口用于接收每个所述第二服务器的心跳报文；

所述处理器用于基于所述第二服务器的心跳报文，监控所述第一服务器和所述第二服务器之间的链路；以及，用于在所述第一服务器和所有所述第二服务器中至少P个第二服务器之间的链路发生异常时，触发选主流程，所述选主流程用于从多个控制服务器中重新选择一个服务器作为主控服务器，所述主控服务器用于代替所述第一服务器，控制所述第二服务器执行业务，其中P为大于等于1的整数。

8.根据权利要求7所述的第一服务器，其特征在于，所述处理器还用于：

统计在预设时长的时间段内所述第一服务器和所述第二服务器之间的丢失心跳报文的数量；

当所述第一服务器和所述第二服务器之间的丢失心跳报文的数量不小于第一阈值时，确认所述第一服务器和所述第二服务器之间的链路发生异常。

9.根据权利要求7或8所述的第一服务器，其特征在于，所述处理器还用于：指示所述多个控制服务器中每个服务器进入所述选主流程。

10.根据权利要求7或8所述的第一服务器，其特征在于，所述第一服务器还与管理服务器通信连接，所述处理器还用于通知所述管理服务器，以使所述管理服务器指示每个所述控服务器进行选主流程或者指定所述多个控制服务器中的一个服务器作为主控服务器。

Images