CN115617509A - 一种分布式集群的节点部署方法、装置和电子设备 - Google Patents

Abstract

本公开提供了一种分布式集群的节点部署方法、装置和电子设备，涉及分布式集群技术领域，用于解决应用部署在分布式集群中出现无法使用的问题。该方法包括：接收部署请求；其中，部署请求中至少包括部署目标服务所需要的理论节点总数；根据部署请求，确定部署目标服务的每个节点之间的部署关系；其中，部署关系包括同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半；按照部署关系，在分布式集群中的服务器上部署目标服务的节点。

Description

一种分布式集群的节点部署方法、装置和电子设备

技术领域

本公开涉及分布式集群技术领域，尤其涉及一种分布式集群的节点部署方法、装置和电子设备。

背景技术

目前，在分布式集群技术领域，随着分布式集群的技术逐渐成熟，越来越多的用户选择将应用部署在分布式集群中。但是，很多用户对分布式集群不熟悉，导致将应用部署在分布式集群中时，会出现各种问题，如：分布式集群中的某个服务器不可用时，出现应用无法使用的情况。

因此，如何避免应用部署在分布式集群中出现无法使用的问题，成为了一个亟待解决的问题。

发明内容

为了解决上述技术问题，本公开提供了一种分布式集群的节点部署方法、装置和电子设备。

本公开的技术方案如下：

第一方面，本公开提供一种分布式集群的节点部署方法，包括：接收部署请求；其中，部署请求中至少包括部署目标服务所需要的理论节点总数；根据部署请求，确定部署目标服务的每个节点之间的部署关系；其中，部署关系包括同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半；按照部署关系，在分布式集群中的服务器上部署目标服务的节点。

第二方面，本公开提供一种分布式集群的节点部署装置，包括：接收单元，用于接收部署请求；其中，部署请求中至少包括部署目标服务所需要的理论节点总数；处理单元，用于根据接收单元接收的部署请求，确定部署目标服务的每个节点之间的部署关系；其中，部署关系包括同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半；处理单元，还用于按照部署关系，在分布式集群中的服务器上部署目标服务的节点。

第三方面，本公开提供一种电子设备，包括：存储器和处理器，存储器用于存储计算机程序；处理器用于在执行计算机程序时，使得电子设备实现如上述第一方面提供的任一项分布式集群的节点部署方法。

第四方面，本公开提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，当计算机程序被计算设备执行时，使得计算设备实现如上述第一方面提供的任一项分布式集群的节点部署方法。

第五方面，本发明提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如第一方面提供的任一项的分布式集群的节点部署方法。

需要说明的是，上述计算机指令可以全部或者部分存储在第一计算机可读存储介质上。其中，第一计算机可读存储介质可以与分布式集群的节点部署装置的处理器封装在一起的，也可以与分布式集群的节点部署装置的处理器单独封装，本公开对此不作限定。

本公开中第二方面、第三方面、第四方面以及第五方面的描述，可以参考第一方面的详细描述；并且，第二方面、第三方面、第四方面以及第五方面的描述的有益效果，可以参考第一方面的有益效果分析，此处不再赘述。

在本公开中，上述分布式集群的节点部署装置的名字对设备或功能模块本身不构成限定，在实际实现中，这些设备或功能模块可以以其他名称出现。只要各个设备或功能模块的功能和本公开类似，属于本公开权利要求及其等同技术的范围之内。

本公开的这些方面或其他方面在以下的描述中会更加简明易懂。

本公开提供的技术方案与现有技术相比具有如下优点：

通过设定同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半。这样，在接收到部署请求后，可以按照部署请求中包含的理论节点总数，使得确定的部署目标服务的每个节点之间的部署关系满足上述设定的条件，此时，在根据部署关系，在分布式集群中的服务器上部署目标服务的节点后，即使为该目标服务提供服务的任一个服务器发生故障时，由于同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半，因此其他的服务器还可以继续工作，保证目标服务的正常运行。

此外，当目标范围为应用时，此时采用本公开提供的分布式集群的节点部署方法部署该应用后，即使为该应用提供服务的任一个服务器发生故障时，由于同一个服务器中部署该应用的节点的实际节点总数小于理论节点总数的一半，因此其他的服务器还可以继续工作，保证该应用的正常运行，解决了应用部署在分布式集群中出现无法使用的问题。

附图说明

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

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的分布式集群的节点部署方法的流程示意图之一；

图2为本申请实施例提供的分布式集群的节点部署方法中显示设备的结构示意图之一；

图3为本申请实施例提供的分布式集群的节点部署方法中显示设备的结构示意图之二；

图4为本申请实施例提供的分布式集群的节点部署方法的流程示意图之一；

图5为本申请实施例提供的分布式集群的节点部署方法的流程示意图之二；

图6为本申请实施例提供的分布式集群的节点部署方法的流程示意图之三；

图7为本申请实施例提供的分布式集群的节点部署方法的流程示意图之四；

图8为本申请实施例提供的分布式集群的节点部署方法的Pod部署示意图；

图9为本申请实施例提供的服务器的结构示意图；

图10为本申请实施例提供的一种芯片系统的示意图之二。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

本公开实施例中的Redis Cluster是Redis的分布式解决方案，在Redis 3.0版本正式推出的，有效解决了Redis分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构达到负载均衡的目的。

本公开实施例中的ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

本公开实施例中的Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。

本公开实施例中的Pod是Kubernetes项目中创建和管理的、最小的可部署的计算单元。

图1为根据本申请一个或多个实施例的显示设备与控制装置之间操作场景的示意图，如图1所示，用户可通过移动终端300和控制装置100操作显示设备200。控制装置100可以是遥控器，遥控器和显示设备的通信包括红外协议通信、蓝牙协议通信，无线或其他有线方式来控制显示设备200。用户可以通过遥控器上按键，语音输入、控制面板输入等输入用户指令，来控制显示设备200。在一些实施例中，也可以使用移动终端、平板电脑、计算机、笔记本电脑、和其他智能设备以控制显示设备200。

在一些实施例中，移动终端300可与显示设备200安装软件应用，通过网络通信协议实现连接通信，实现一对一控制操作的和数据通信的目的。也可以将移动终端300上显示音视频内容传输到显示设备200上，实现同步显示功能显示设备200还与显示设备200通过多种通信方式进行数据通信。可允许显示设备200通过局域网(LAN)、无线局域网(WLAN)和其他网络进行通信连接。显示设备200可以向显示设备200提供各种内容和互动。显示设备200，可以液晶显示器、OLED显示器、投影显示设备。显示设备200除了提供广播接收电视功能之外，还可以附加提供计算机支持功能的智能网络电视功能。

在一些实施例中，服务器400中运行有用于管理分布式集群的分布式操作系统系统，本申请实施例提供电子设备可以为上述显示设备200。其中，运维人员需要将目标服务部署在分布式集群时，可以通过与服务器400建立通信连接的电子设备(如：个人计算机(Personal Computer，PC)或者手机等)，向服务器400发送部署请求。服务器400在接收到电子设备发送的部署请求后，根据部署请求，确定部署请求。这样，服务器400就可以根据部署关系，在服务器400上部署目标服务的节点。从而，显示设备200在于服务器400建立了通信连接后，显示设备200访问目标服务时，由于同一个服务器400中部署目标服务的节点的实际节点总数小于理论节点总数的一半，因此即使该目标服务提供服务的任一个服务器400发生故障时，也不会影响目标服务的正常运行，保证用户的体验。

图2示出了根据示例性实施例中显示设备200的硬件配置框图。如图2所示显示设备200包括调谐解调器210、通信器220、检测器230、外部装置接口240、控制器250、显示器260、音频输出接口270、存储器、供电电源、用户接口280中的至少一种。控制器包括中央处理器，视频处理器，音频处理器，图形处理器，RAM，ROM，用于输入/输出的第一接口至第n接口。显示器260可为具有触控功能的显示器，如触控显示器。调谐解调器210通过有线或无线接收方式接收广播电视信号，以及从多个无线或有线广播电视信号中解调出音视频信号，如以及EPG数据信号。检测器230用于采集外部环境或与外部交互的信号。控制器250和调谐解调器210可以位于不同的分体设备中，即调谐解调器210也可在控制器250所在的主体设备的外置设备中，如外置机顶盒等。

在一些实施例中，控制器250，通过存储在存储器上中各种软件控制程序，来控制显示设备的工作和响应用户的操作。控制器250控制显示设备200的整体操作。

在一些示例中，以申请一个或多个实施例的显示设备200为电视机1，并且电视机1的操作系统为Android系统为例，如图3所示，电视机1从逻辑上可以分为应用程序(Applications)层(简称“应用层”)21，应用程序框架(Application Framework)层(简称“框架层”)22，安卓运行时(Android runtime)和系统库层(简称“系统运行库层”)23，以及内核层24。

其中，应用层21包括一个或多个应用。应用可以为系统应用，也可以为第三方应用。如，应用层21包括第一应用，第一应用可以提供目标服务。框架层22为应用层21的应用程序提供应用编程接口(application programming interface，API)和编程框架。系统运行库层23为上层即框架层22提供支撑，当框架层22被使用时，安卓操作系统会运行系统运行库层23中包含的C/C++库以实现框架层22要实现的功能。内核层24作为硬件层和应用层21之间的软件中间件，用于管理和控制硬件与软件资源。

为了能够让电视机1能够通过第一应用向用户提供目标服务，运维人员可以将目标服务部署在分布式集群，如：运行有用于管理分布式集群的分布式操作系统的服务器400发送部署请求。服务器400的接收单元200在接收到电子设备(如：PC或者手机等)发送的部署请求后，服务器400的处理单元201根据接收单元200接收的部署请求，确定部署请求。这样，处理单元201就可以根据接收部署关系，在服务器400上部署目标服务的节点。从而，电视机1在安装第一应用后，便可以向用户提供目标服务。如：电视机1开机后，第一应用启动。之后，电视机1响应于对第一应用的选择操作，向服务器400发送目标服务请求。服务器400通过调用部署目标服务的节点，得到目标服务对应的业务数据。之后，服务器400的发送单元202将该业务数据发送至电视机1。电视机1在接收到服务器400发送的业务数据后，根据该业务数据显示相应的界面，以为用户提供目标服务，保证用户的体验。

具体的，服务器400中的存储单元203用于存储分布式操作系统，以及其它用于保证服务器400正常运行的数据。

具体的，本公开实施例提供的电子设备可以是上述服务器400，此处不做限定。

本申请所涉及的部署请求均可以为经用户授权或者经过各方充分授权的数据。

以下实施例中以执行本公开实施例提供的分布式集群的节点部署方法的执行主体为上述服务器400为例，对本申请实施例的方法进行说明。

本申请实施例提供一种分布式集群的节点部署方法，如图4所示，该分布式集群的节点部署方法可以包括S11-S13。

S11、接收部署请求。其中，部署请求中至少包括部署目标服务所需要的理论节点总数。

在一些示例中，目标服务可以提供一个或者多个子服务，每个子服务对应一个节点(也可以称为Pod)，不同的子服务对应的理论运行参数不同。其中，理论运行参数至少包括中央处理器(central processing unit，CPU)占用率、内存(Memory)使用率等。因此，部署请求中还可以包括每个节点的运行参数。这样，在将目标服务的节点部署在服务器上时，还需要根据服务器的实际运行参数和理论运行参数，来确认该服务器是否合适部署该目标服务的节点。如：服务器400运行有管理分布式集群的分布式操作系统，该分布式集群包括至少两个服务器100。其中，分布式集群中包含的服务器100的总数大于或等于理论节点总数。

服务器400在将目标服务的节点部署在服务器100时，需要根据当前部署的节点对应的理论运行参数，在分布式集群中寻找满足该理论运行参数的服务器100，如：根据服务器100的实际运行参数和理论运行参数筛选服务器100，如：运行参数包括CPU占用率和内存使用率时，若理论运行参数中的CPU占用率要求小于30％，内存使用率要求小于60％时，此时可以根据理论运行参数，筛选出分布式集群中CPU占用率小于30％，且内存使用率要求小于60％的服务器100。进而在CPU占用率小于30％，且内存使用率要求小于60％的服务器100中选择一个服务器100部署该节点。如：不同的服务器100预先配置了不同的优先级，在得到CPU占用率小于30％，且内存使用率要求小于60％的服务器100后，对每个服务器100的优先级进行排序，选择优先级最高的服务器部署该节点。

或者，对CPU占用率小于30％，且内存使用率要求小于60％的服务器100后，对每个服务器100的CPU占用率按照从小到大的顺序进行排序，同时对内存使用率按照从小到大的顺序进行排序，从而得到占用率排序和使用率排序。之后，确定占用率排序中排名前N(如3)的服务器100，以及使用率序中排名前N(如3)的服务器100。若占用率排序中排名前N(如3)的服务器100和使用率序中排名前N(如3)的服务器100中同时包含一个服务器100时，将该节点部署在该服务器100上。

若用率排序中排名前N(如3)的服务器100和使用率序中排名前N(如3)的服务器100中同时包含两个或者三个服务器100时，随机在多个服务器100中选择一个服务器100部署该节点，或者对多个服务器100进行优先级排序，选择优先级最高的服务器100部署该节点，或者，根据多个服务器100中每个服务器100的消耗的虚拟资源进行排序，选择消耗虚拟资源最小的服务器100部署该节点。

若用率排序中排名前N(如3)的服务器100和使用率序中排名前N(如3)的服务器100中无相同的服务器100时，继续增大N的取值，直至寻找到有相同的服务器100的，停止寻找。

S12、根据部署请求，确定部署目标服务的每个节点之间的部署关系。其中，部署关系包括同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半。

在一些示例中，如：zookeeper如果有一半以上的节点正常工作，一少部分节点宕机，整个分布式集群可以正常工作。或者，redis-cluster中若Pod的主节点异常，有一半以上的主节点正常并投票给对应的从节点，使得可以进行正常的主从切换，整个分布式集群就可以正常工作。本公开实施例提供的分布式集群的节点部署方法，采用多数派(quorum)的原理，保证同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半。如：对目标服务的每个节点按照从小到大的顺序进行编号，如：(0，1，2，3，4，5等)。之后，为节点随机生成一个字符串作为该节点的目标标识，以防止一个服务器100中部署了多个节点时，可以根据该目标标识，区分不同的目标服务的节点。之后，通过对理论节点总数和目标阈值的大小关系，从而确定部署关系。或者，根据目标标识的排序，确定部署关系。

S13、按照部署关系，在分布式集群中的服务器上部署目标服务的节点。

在一些示例中，由于部署关系中已经规定了节点和节点之间部署的服务器的关系，如节点1和节点2部署在不同的服务器，或者，节点3部署的服务器与节点1和节点2部署的服务器均不相同，此时，服务器400就可以根据部署关系，部署该目标服务的节点。

在另一些示例中，结合S11给出的示例，服务器400在部署目标服务的节点时，还需根据节点的理论运行参数和服务器100的实际运行参数，确定能够部署该节点的服务器100。具体的，服务器400如何根据节点的理论运行参数和服务器100的实际运行参数，确定能够部署该节点的服务器100，与上述S11中给出的示例类似，此处不再赘述。

示例性的，分布式集群包括zookeeper、kafka、redis-cluser中的任一项。

示例性的，分布式集群中包含的服务器100的总数可以是4，以保证理论节点总数大于或等于5的目标服务，可以在4个服务器100中进行部署，同时可以保证同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半。

由上述可知，本公开实施例提供的分布式集群的节点部署方法，通过设定同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半。这样，在接收到部署请求后，可以按照部署请求中包含的理论节点总数，使得确定的部署目标服务的每个节点之间的部署关系满足上述设定的条件，此时，在根据部署关系，在分布式集群中的服务器上部署目标服务的节点后，即使为该目标服务提供服务的任一个服务器发生故障时，由于同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半，因此其他的服务器还可以继续工作，保证目标服务的正常运行。

在一些可实施的示例中，结合图4，如图5所示，上述S12具体可以通过下述S120和S121实现。

S120、根据理论节点总数，为每个节点分配一个目标标识。其中，一个节点对应一个目标标识。

在一些示例中，目标标识包括编号和字符串中的至少一项。如：目标标识包括编号时，服务器400根据理论节点总数，确定目标服务需要部署的节点总数。之后，服务器500从0开始为该目标范围的每个节点进行编号。然后，根据理论节点总数和目标阈值的大小关系，确定每个编号对应的节点所部署的服务器之间的关系。如：理论节点总数为2(分别为节点0和节点1)，目标阈值为4时，由于2＜4，若将节点0和节点1部署在一个服务器100上时，同一个服务器中部署的实际节点总数2，大于理论节点总数的一半(1)。因此，需要将节点0和节点1分别部署在不同的服务器100中。

或者，理论节点总数为3(分别为节点0、节点1和节点2)，目标阈值为4时，由于3＜4，若将节点0和节点1、或者节点0和节点2、或者节点1和节点2、或者节点0、节点1和节点2部署在一个服务器100上时，同一个服务器中部署的实际节点总数2或3，均大于理论节点总数的一半(1.5)。因，此需要将节点0、节点1和节点2分别部署在不同的服务器100中。

或者，理论节点总数为4(分别为节点0、节点1、节点2、节点3)，目标阈值为4时，由于4＝4，

若将节点0和节点1、或者节点0和节点2、或者节点0和节点3、或者节点1和节点2、或者节点1和节点3、或者节点2和节点3、或者节点0、节点1和节点2、或者节点0、节点1和节点3、或者节点1、节点2和节点3、或者节点0、节点1、节点2和节点3部署在一个服务器100上时，同一个服务器中部署的实际节点总数2或3或4，均大或等于理论节点总数的一半(2)。因此，需要将节点0、节点1、节点2和节点3分别部署在不同的服务器100中。

具体的，服务器400可以基于Pod的亲和性和反亲和性的特性来确定表示各个节点部署的服务器之间的关系。如：希望目标服务的不同Pod分布在不同服务器100(node节点)上时，可以采用反亲和性配置；希望目标服务在相同服务器100上，减少通信延迟，可以采用亲和性配置。通过设置不同节点之间的亲和性和反亲和性，实现不同的部署关系。

示例性的，以理论节点总数为2，目标阈值为4时，由于2＜4，同时同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半，因此可以将节点0和节点1分别部署在不同的服务器100中。此时，服务器400可以在分布式集群中选择一个可以部署节点0(选择的过程如上述S11给出的示例)。之后，设置节点1与节点0反亲和(即节点1和节点0不能部署在同一个服务器上)。从而，服务器可以根据各个节点之间的亲和关系，确定各个节点部署的服务器之间的关系。

需要说明的是，理论节点总数为3或者理论节点总数为4时，确定各个节点之间的亲和关系的过程，与理论节点总数为2时各个节点之间的亲和关系的过程的类似，此处不再赘述。

在另一些示例中，目标标识包括字符串时，服务器400根据理论节点总数，确定目标服务需要部署的节点总数。之后，服务器500为每个节点随机生成一个字符串。然后，根据理论节点总数和目标阈值的大小关系，确定每个字符串对应的节点所部署的服务器之间的关系。

具体的，服务器400根据理论节点总数和目标阈值的大小关系，确定每个字符串对应的节点所部署的服务器之间的关系的过程，与服务器400根据理论节点总数和目标阈值的大小关系，确定每个编码对应的节点所部署的服务器之间的关系的过程类似，此处不再赘述。

S121、在理论节点总数小于或等于目标阈值的情况下，将每个目标标识对应的节点分别部署在不同的服务器上。

在一些可实施的示例中，结合图4，如图5所示，本公开实施例提供的分布式集群的节点部署方法，还包括S122和S123。

S122、在理论节点总数大于目标阈值的情况下，选取目标阈值个目标标识，将选取的每个目标标识对应的节点分别部署在不同的服务器上。

在一些示例中，为了保证每个目标业务的节点能够在同一个服务器中部署所述目标服务的节点的实际节点总数小于所述理论节点总数的一半，需要在理论节点总数大于目标阈值的情况下，选取目标阈值个目标标识，将选取的每个目标标识对应的节点分别部署在不同的服务器上。如：理论节点总数为5(分别为节点0、节点1、节点2、节点3和节点4)，目标阈值为4时，如此时选择了节点0、节点1、节点2和节点3这4个节点，并将节点0、节点1、节点2和节点3分别部署在不同的服务器上。对于未选中的节点4，服务器400可以将节点4部署在节点0、节点1、节点2、节点3四者所部署的服务器中的任一个服务器上，也可以将节点4部署在除节点0、节点1、节点2、节点3四者所部署的服务器之外的服务器上。

或者，理论节点总数为6(分别为节点0、节点1、节点2、节点3、节点4和节点5)，目标阈值为4时，如此时选择了节点0、节点1、节点2、节点3这4个节点，并将节点0、节点1、节点2和节点3分别部署在不同的服务器上。对于未选中的节点4，服务器400可以将节点4部署在节点0、节点1、节点2、节点3四者所部署的服务器中的任一个服务器上，也可以将节点4部署在除节点0、节点1、节点2和节点3四者所部署的服务器之外的服务器上。对于未选中的节点5，服务器400可以将节点5部署在没有部署节点4的服务器上，如：服务器400将节点0和节点4部署在同一个服务器上，此时节点5可以部署在节点1、节点2、节点3三者所部署的服务器中的任一个服务器上。或者，将节点5部署在除节点0、节点1、节点2、节点3和节点4五者所部署的服务器之外的服务器上。

或者，理论节点总数为7(分别为节点0、节点1、节点2、节点3、节点4、节点5和节点6)，目标阈值为4时，如此时选择了节点0、节点1、节点2和节点3这4个节点，并将节点0、节点1、节点2和节点3分别部署在不同的服务器上。

此时，未选中的节点包括节点4、节点5和节点6。此时，可以将相邻两个未选取的目标标识对应的节点分别部署在不同的服务器上，如将节点4和节点5部署在不同的服务器上，将节点5和节点6部署在不同的服务器上。对于未选中的节点4，服务器400可以将节点4部署在节点0、节点1、节点2、节点3四者所部署的服务器中的任一个服务器上，也可以将节点4部署在除节点0、节点1、节点2和节点3四者所部署的服务器之外的服务器上。对于未选中的节点5，服务器400可以将节点5部署在没有部署节点4的服务器上，如：服务器400将节点0和节点4部署在同一个服务器上，此时节点5可以部署在节点1、节点2、节点3三者所部署的服务器中的任一个服务器上。或者，将节点5部署在除节点0、节点1、节点2、节点3和节点4五者所部署的服务器之外的服务器上。对于未选中的节点6，服务器400可以将节点6部署在没有部署节点5的服务器上，如：服务器400将节点0和节点5部署在同一个服务器上，将节点1和节点4部署在同一个服务器上，此时节点6可以部署在节点1、节点2、节点3三者所部署的服务器中的任一个服务器上。或者，将节点6部署在除节点0、节点1、节点2、节点3和节点5五者所部署的服务器之外的服务器上。如此，可以保证目标服务在同一个服务器中部署所述目标服务的节点的实际节点总数小于所述理论节点总数的一半。

S123、对于未选取的目标标识，将相邻两个未选取的目标标识对应的节点分别部署在不同的服务器上。

在一些示例中，目标标识包括编码时，将相邻两个未选取的目标标识对应的节点分别部署在不同的服务器上时，可以将未选取的目标标识中的奇数和偶数进行反亲和设置，从而可以保证相邻两个未选取的目标标识对应的节点分别部署在不同的服务器上。

示例性的，以分布式集群为Redis-cluster集群为例，每个分片采用一主一备做高可用，当主分片的主节点异常时，可用将从分片的从节点提升为主节点。其中，从节点和其主节点之间设置为反亲和(即从节点和其对应的主节点部署在不同的服务器100中)。

从0开始为每个Pod编号，依次为每个Pod的随机生成字符串作为其目标标识，目标标识的编号(key)为orderId，values为随机生成的字符串。对于编号为0的Pod，则不需要和其他Pod反亲和，这里可以配置为自己的orderId。对于编号小于等于3的Pod(如：编号为1的Pod、编号为2的Pod和编号为3的Pod)，则设置为与编号比其本身小的Pod反亲和，比如编号为1的Pod，需要和编号为0的Pod反亲和，编号为3的和编号为0，1，2的Pod都反亲和。对于编号大于3的Pod(如编号为4的Pod)，若该编号为偶数，则不需要反亲和，若该编号为奇数，则需要和前一个编号的Pod反亲和(如：前一个编号为4，当前的编号为5时，由于5为奇数，因此需要将编号5对于的Pod与编号4对应的Pod设置为反亲和)。

这样创建出来的Pod，就可以保证不会有大于等于一半的Pod在同一个物理服务器上，做到高可用。并且只需要保证前4个Pod分布到4个不同的物理服务器上，后面的Pod反亲和配置比较宽松，可以利用容器云本身的调度策略，将Pod分布到有资源的物理服务器上，这样就可以创建出更多节点的集群。

示例性的，结合上述S123给出的示例，如表1所示，采用本发明实施例提供的分布式集群的节点部署方法，创建出来的5Pod的redis-cluster集群，5个Pod的主节点分布在5个不同的物理服务器(即分布在不同的Node上，每Node对应的互联网协议(InternetProtocol，IP)地址不同)，每个Pod的主从节点分布在物理服务器上(每个Pod对应的IP地址不同)。

表1

其中，db_0表示编号为0的Pod、db_1表示编号为1的Pod、db_2表示编号为2的Pod、db_3表示编号为3的Pod、db_4表示编号为4的Pod，Pod地址表示Pod的IP地址，Node地址表示服务器的IP地址。

在一些可实施的示例中，结合图5，如图6所示，上报S120具体可以通过下述S1200和S1201实现。

S1200、根据理论节点总数，为每个节点分配一个随机生成的字符串。

在一些示例中，每个随机生成的字符串的长度相同。

S1201、对于每个节点，将节点对应的字符串作为节点的目标标识。

在一些可实施的示例中，结合图4，如图7所示，上述S12具体可以通过下述S124和S125实现。

S124、根据理论节点总数，为每个节点分配一个目标标识。其中，一个节点对应一个目标标识。

S125、对目标标识进行排序，确定任一个目标标识对应的节点所部署的服务器，与在任一个目标标识之前的，距离任一个目标标识的实际距离小于或等于预设距离的每个目标标识所部署的服务器均不相同。

在一些示例中，在对目标标识进行排序后，可以得到一个排序结果。如：目标标识包括编码时，可以按照从小到大的顺序对编码进行排序，从而可以得到每个目标标识所对应的排序位置。或者，目标标识包括字符串时，此时可以按照每个字符串的生成时间的先后顺序进行排序，从而可以得到每个目标标识所对应的排序位置。或者，目标标识包括编码和字符串时，可以按照从小到大的顺序对编码进行排序，从而可以得到每个目标标识所对应的排序位置。或者，目标标识包括编码和字符串时，此时可以按照每个字符串的生成时间的先后顺序进行排序，从而可以得到每个目标标识所对应的排序位置。

之后，确定当前处理的目标标识所在的排序位置，确定在当前处理的目标标识之前的，距离当前处理的目标标识预设距离的每个目标标识所部署的服务器。如：目标标识包括编码时，理论节点总数为5，预设距离为4时，此时服务器400对每个节点从0开始编码，可以得到节点0、节点1、节点2、节点3和节点4。之后，按照从小到大的顺序依次对编码进行排序，可以确定排序位置为1的是节点0、排序位置为2的是节点1、排序位置为3的是节点2、排序位置为4的是节点3、排序位置为5的是节点4。对于排序位置为1的是节点0，由于在其之前并不存在其他的节点，因此可以直接将节点0部署在服务器100上。

对于排序位置为2的是节点1，由于在其之前的节点为节点0，因此，可以确定节点1和节点0之间的实际距离为(排序位置2-排序位置1)+1等于2。由于实际距离2小于预设距离4，因此可以将节点1对应的目标标识与节点0对应的目标标识设置反亲和，从而使得节点1和节点0分别部署不同的服务器100上。

对于排序位置为3的是节点2，由于在其之前的节点为节点0和节点1，因此，可以确定节点2和节点0之间的实际距离为(排序位置3-排序位置1)+1等于3，节点2和节点1之间的实际距离为(排序位置3-排序位置2)+1等于2。由于实际距离2和3二者均小于预设距离4，因此可以将节点2对应的目标标识、节点1对应的目标标识、节点0对应的目标标识三者相互之间设置反亲和，从而使得节点2、节点1和节点0分别部署在不同的服务器100上。

对于排序位置为4的是节点3，由于在其之前的节点为节点0、节点1和节点2，因此，可以确定节点3和节点0之间的实际距离为(排序位置4-排序位置1)+1等于4，节点3和节点1之间的实际距离为(排序位置4-排序位置2)+1等于3，节点3和节点2之间的实际距离为(排序位置4-排序位置3)+1等于2。由于实际距离4等于预设距离4、实际距离3和2二者均小于预设距离4，因此可以将节点3对应的目标标识、节点2对应的目标标识、节点1对应的目标标识、节点0对应的目标标识四者相互之间设置反亲和，从而使得将节点3、节点2、节点1和节点0分别部署在不同的服务器100上。

对于排序位置为5的是节点4，由于在其之前的节点为节点0、节点1、节点2和节点3，因此，可以确定节点4和节点0之间的实际距离为(排序位置5-排序位置1)+1等于5，节点4和节点1之间的实际距离为(排序位置5-排序位置2)+1等于4，节点4和节点2之间的实际距离为(排序位置5-排序位置3)+1等于3，节点4和节点3之间的实际距离为(排序位置5-排序位置4)+1等于2。由于实际距离5大于预设距离4，因此可以将节点4对应的目标标识、节点3对应的目标标识、节点2对应的目标标识和节点1对应的目标标识四者相互之间设置反亲和，从而使得节点4部署在除部署有节点3、节点2和节点1的服务器100以外的服务器上(如：部署有节点0的服务器100)。

示例性的，如预设距离为4时，假设分布式集群只有4个服务器100(node节点)，按照上述S124和S125的操作部署目标服务的节点时，目标服务的节点分布如图8所示。可以看出，按照上述S124和S125的操作部署目标服务的节点时，会保证前4个pod分布在不同的物理服务器上，后面的pod可以依次分布在每个服务器100上，保同一个服务器100中部署目标服务的节点的实际节点总数小于理论节点总数的一半，即使某一个服务器100宕机，也可以保证分布式集群的正常运行，保证用户的体验。

具体的，目标标识包括字符串，或者目标标识包括编码和字符串时，计算实际距离的过程，与目标标识包括编码时计算实际距离的过程类似，此处不再赘述。

上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对分布式集群的节点部署装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

如图9所示，本申请的实施例提供一种服务器400的结构示意图。包括通信器101和处理器102。

通信器101，用于接收部署请求；其中，部署请求中至少包括部署目标服务所需要的理论节点总数；处理器102，用于根据通信器101接收的部署请求，确定部署目标服务的每个节点之间的部署关系；其中，部署关系包括同一个服务器中部署目标服务的节点的实际节点总数小于理论节点总数的一半；处理器102，还用于按照部署关系，在分布式集群中的服务器上部署目标服务的节点。

在一些可实施的示例中，处理器102，具体用于根据通信器101接收的理论节点总数，为每个节点分配一个目标标识；其中，一个节点对应一个目标标识；处理器102，具体用于在通信器101接收的理论节点总数小于或等于目标阈值的情况下，将每个目标标识对应的节点分别部署在不同的服务器上。

在一些可实施的示例中，处理器102，还用于在通信器101接收的理论节点总数大于目标阈值的情况下，选取目标阈值个目标标识，将选取的每个目标标识对应的节点分别部署在不同的服务器上；处理器102，还用于对于未选取的目标标识，将相邻两个未选取的目标标识对应的节点分别部署在不同的服务器上。

在一些可实施的示例中，处理器102，具体用于根据通信器101接收的理论节点总数，为每个节点分配一个随机生成的字符串；处理器102，具体用于对于每个节点，将节点对应的字符串作为节点的目标标识。

在一些可实施的示例中，处理器102，具体用于根据通信器101接收的理论节点总数，为每个节点分配一个目标标识；其中，一个节点对应一个目标标识；处理器102，具体用于对目标标识进行排序，确定任一个目标标识对应的节点所部署的服务器，与在任一个目标标识之前的，距离任一个目标标识的实际距离小于或等于预设距离的每个目标标识所部署的服务器均不相同。

其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，其作用在此不再赘述。

当然，本申请实施例提供的服务器400包括但不限于上述模块，例如服务器400还可以包括存储器103。存储器103可以用于存储该服务器400的程序代码，还可以用于存储服务器400在运行过程中生成的数据，如写请求中的数据等。

作为一个示例，结合图3，服务器400中的接收单元200和发送单元202实现的功能通信器101的功能相同，处理单元201实现的功能与处理器102的功能相同，存储单元203实现的功能与存储器103的功能相同。

如图10所示，本申请实施例还提供一种芯片系统，该芯片系统可以应用于前述实施例中的服务器400。该芯片系统包括至少一个处理器1501和至少一个接口电路1502。该处理器1501可以是上述服务器400中的处理器。处理器1501和接口电路1502可通过线路互联。该处理器1501可以通过接口电路1502从上述服务器400的存储器接收并执行计算机指令。当计算机指令被处理器1501执行时，可使得服务器400执行上述实施例中服务器400执行的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机可读存储介质，用于存储上述服务器400运行的计算机指令。

本申请实施例还提供一种计算机程序产品，包括上述服务器400运行的计算机指令。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种分布式集群的节点部署方法，其特征在于，包括：

接收部署请求；其中，所述部署请求中至少包括部署目标服务所需要的理论节点总数；

根据所述部署请求，确定部署所述目标服务的每个节点之间的部署关系；其中，所述部署关系包括同一个服务器中部署所述目标服务的节点的实际节点总数小于所述理论节点总数的一半；

按照所述部署关系，在所述分布式集群中的服务器上部署所述目标服务的节点。

2.根据权利要求1所述的分布式集群的节点部署方法，其特征在于，所述根据所述部署请求，确定部署所述目标服务的每个节点之间的部署关系，包括：

根据所述理论节点总数，为每个节点分配一个目标标识；其中，一个节点对应一个目标标识；

在所述理论节点总数小于或等于目标阈值的情况下，将每个目标标识对应的节点分别部署在不同的服务器上。

3.根据权利要求2所述的分布式集群的节点部署方法，其特征在于，所述方法还包括：

在所述理论节点总数大于所述目标阈值的情况下，选取所述目标阈值个目标标识，将选取的每个所述目标标识对应的节点分别部署在不同的服务器上；

对于未选取的目标标识，将相邻两个未选取的目标标识对应的节点分别部署在不同的服务器上。

4.根据权利要求2所述的分布式集群的节点部署方法，其特征在于，所述根据所述理论节点总数，为每个节点分配一个目标标识，包括：

根据所述理论节点总数，为每个节点分配一个随机生成的字符串；

对于每个节点，将所述节点对应的字符串作为所述节点的目标标识。

5.根据权利要求1所述的分布式集群的节点部署方法，其特征在于，所述根据所述部署请求，确定部署所述目标服务的每个节点之间的部署关系，包括：

根据所述理论节点总数，为每个节点分配一个目标标识；其中，一个节点对应一个目标标识；

对所述目标标识进行排序，确定任一个目标标识对应的节点所部署的服务器，与在所述任一个目标标识之前的，距离所述任一个目标标识的实际距离小于或等于预设距离的每个目标标识所部署的服务器均不相同。

6.一种分布式集群的节点部署装置，其特征在于，包括：

接收单元，用于接收部署请求；其中，所述部署请求中至少包括部署目标服务所需要的理论节点总数；

处理单元，用于根据所述接收单元接收的所述部署请求，确定部署所述目标服务的每个节点之间的部署关系；其中，所述部署关系包括同一个服务器中部署所述目标服务的节点的实际节点总数小于所述理论节点总数的一半；

所述处理单元，还用于按照所述部署关系，在所述分布式集群中的服务器上部署所述目标服务的节点。

7.根据权利要求6所述的分布式集群的节点部署装置，其特征在于，所述处理单元，具体用于根据所述接收单元接收的所述理论节点总数，为每个节点分配一个目标标识；其中，一个节点对应一个目标标识；

所述处理单元，具体用于在所述接收单元接收的所述理论节点总数小于或等于目标阈值的情况下，将每个目标标识对应的节点分别部署在不同的服务器上。

8.根据权利要求7所述的分布式集群的节点部署装置，其特征在于，所述处理单元，还用于在所述接收单元接收的所述理论节点总数大于所述目标阈值的情况下，选取所述目标阈值个目标标识，将选取的每个所述目标标识对应的节点分别部署在不同的服务器上；

所述处理单元，还用于对于未选取的目标标识，将相邻两个未选取的目标标识对应的节点分别部署在不同的服务器上。

9.一种电子设备，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序；所述处理器用于在执行计算机程序时，使得所述电子设备实现权利要求1-5任一项所述的分布式集群的节点部署方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，当所述计算机程序被计算设备执行时，使得所述计算设备实现权利要求1-5任一项所述的分布式集群的节点部署方法。

Images