Zookeeper 集群部署

ZooKeeper 是 Apache 的一个顶级项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性，被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。

本文的目标读者是对 ZooKeeper 有一定了解的技术人员，将从 ZooKeeper 运行模式、集群组成、容灾和水平扩容四方面逐步深入，最终构建出高可用的 ZooKeeper 集群。

一、运行模式

Zookeeper 有三种运行模式：单机模式、伪集群模式和集群模式。

1.1 单机模式

这种模式一般适用于开发测试环境，一方面我们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。

在 Linux 环境下运行单机模式需要执行以下步骤：

1. 准备 Java 运行环境

由于zookeeper集群的运行需要Java运行环境，所以需要首先安装 JDK，这里安装 Java 1.6 或更高版本的 JDK，并配置好 Java 相关的环境变量 $JAVA_HOME 。

2. 下载 ZooKeeper 安装包

下载地址：http://zookeeper.apache.org/releases.html。选择最新的 stable 版本并解压到指定目录，我们用 $ZK_HOME 表示该目录。

为了能够在任意目录启动zookeeper，我们需要配置环境变量。

　　ps:你也可以不配，这不是搭建集群的必要操作，只不过如果你不配置环境变量，那么每次启动zookeeper需要到安装文件的 bin 目录下去启动。

　　首先进入到 /etc/profile 目录，添加相应的配置信息：

#set zookeeper environment
export ZK_HOME=/usr/local/zookeeper/zookeeper-3.6.3
export PATH=$PATH:$ZK_HOME/bin

然后通过如下命令使得环境变量生效：

source /etc/profle

3. 配置 zoo.cfg

首次使用 ZooKeeper，需要将 $ZK_HOME 下的 zoo_sample.cfg 文件重命名为 zoo.cfg，并进行以下配置

tickTime=2000    ##Zookeeper最小时间单元，单位毫秒(ms)，默认值为3000
dataDir=/var/lib/zookeeper    ##Zookeeper服务器存储快照文件的目录，必须配置
dataLogDir=/var/lib/log     ##Zookeeper服务器存储事务日志的目录，默认为dataDir
clientPort=2181    ##服务器对外服务端口，一般设置为2181
initLimit=5    ##Leader服务器等待Follower启动并完成数据同步的时间，默认值10，表示tickTime的10倍
syncLimit=2    ##Leader服务器和Follower之间进行心跳检测的最大延时时间，默认值5，表示tickTime的5倍

4. 启动服务

使用 $ZK_HOME/bin 目录下的 zkServer.sh 脚本进行服务的启动。

1.2 集群模式

zookeeper 集群通常是用来对用户的分布式应用程序提供协调服务的，为了保证数据的一致性，对 zookeeper 集群进行了这样三种角色划分：leader、follower、observer分别对应着总统、议员和观察者。

　　领导者（leader）：负责进行投票的发起和决议，更新系统状态。

　　跟随者（follower）：用于接收客户端请求并向客户端返回结果以及在选举过程中参与投票。

　　观察者（observer）：也可以接收客户端连接，将写请求转发给leader节点，但是不参与投票过程，只同步leader的状态。通常对查询操作做负载。

一个 ZooKeeper 集群通常由一组机器组成，一般 3 台以上就可以组成一个可用的 ZooKeeper 集群了。

组成 ZooKeeper 集群的每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都会互相保持通信。

重要的一点是，只要集群中存在超过一半的机器能够正常工作，那么整个集群就能够正常对外服务。

ZooKeeper 的客户端程序会选择和集群中的任意一台服务器创建一个 TCP 连接，而且一旦客户端和服务器断开连接，客户端就会自动连接到集群中的其他服务器。

那么如何运行 ZooKeeper 集群模式呢？首先假如我们有三台服务器，IP 分别为 IP₁、IP₂ 和 IP₃，则需要执行以下步骤：

1. 准备 Java 运行环境（同上）

2. 下载 ZooKeeper 安装包（同上）

3. 配置 zoo.cfg

tickTime=2000
dataDir=/var/lib/zookeeper
dataLogDir=/var/lib/log
clientPort=2181
initLimit=5
syncLimit=2
server.1=IP1:2888:3888
server.2=IP2:2888:3888
server.3=IP3:2888:3888

可以看到，相比于单机模式，集群模式多了 server.id=host:port₁:port₂ 的配置。

其中，id 被称为 Server ID，用来标识该机器在集群中的机器序号（在每台机器的 dataDir 目录下创建 myid 文件，文件内容即为该机器对应的 Server ID 数字）。host 为机器 IP，port₁ 用于指定 Follower 服务器与 Leader 服务器进行通信和数据同步的端口，port₂用于进行 Leader 选举过程中的投票通信。

在多解释下参数内容：

①、tickTime：基本事件单元，这个时间是作为Zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔，每隔tickTime时间就会发送一个心跳；最小的session过期时间为2倍tickTime

　　②、dataDir：存储内存中数据库快照的位置，除非另有说明，否则指向数据库更新的事务日志。注意：应该谨慎的选择日志存放的位置，使用专用的日志存储设备能够大大提高系统的性能，如果将日志存储在比较繁忙的存储设备上，那么将会很大程度上影像系统性能。

　　③、client：监听客户端连接的端口。

　　④、initLimit：允许follower连接并同步到Leader的初始化连接时间，以tickTime为单位。当初始化连接时间超过该值，则表示连接失败。

　　⑤、syncLimit：表示Leader与Follower之间发送消息时，请求和应答时间长度。如果follower在设置时间内不能与leader通信，那么此follower将会被丢弃。

　　⑥、server.A=B:C:D

　　　　A：其中 A 是一个数字，表示这个是服务器的编号；

　　　　B：是这个服务器的 ip 地址；

　　　　C：Zookeeper服务器之间的通信端口；

　　　　D：Leader选举的端口。

　　我们需要修改的第一个是 dataDir ,在指定的位置处创建好目录。

　　第二个需要新增的是 server.A=B:C:D 配置，其中 A 对应下面我们即将介绍的myid 文件。B是集群的各个IP地址，C:D 是端口配置

4. 创建 myid 文件

在 dataDir 目录下创建名为 myid 的文件，在文件第一行写上对应的 Server ID。

5. 按照相同步骤，为其他机器配置 zoo.cfg 和 myid文件

6. 启动服务

#启动命令：
zkServer.sh start

#停止命令：
zkServer.sh stop

#重启命令：
zkServer.sh restart

#查看集群节点状态：
zkServer.sh status

查看各个节点的状态，三台机器中其中一台会被选举成为leader，而剩下的两台成为了 follower。这时候，如果你将leader节点机器关掉，会发现剩下两台又会有一台变成了 leader节点。

1.3 伪集群模式

这是一种特殊的集群模式，即集群的所有服务器都部署在一台机器上。当你手头上有一台比较好的机器，如果作为单机模式进行部署，就会浪费资源，这种情况下，ZooKeeper允许你在一台机器上通过启动不同的端口来启动多个 ZooKeeper 服务实例，以此来以集群的特性来对外服务。

这种模式下，只需要把 zoo.cfg 做如下修改：

tickTime=2000
dataDir=/var/lib/zookeeper
dataLogDir=/var/lib/log
clientPort=2181
initLimit=5
syncLimit=2
server.1=IP1:2888:3888
server.2=IP1:2889:3889
server.3=IP1:2890:3890

二、集群组成

要搭建一个高可用的 ZooKeeper 集群，我们首先需要确定好集群的规模。

关于 ZooKeeper 集群的服务器组成，相信很多对 ZooKeeper 了解但是理解不够深入的读者，都存在或曾经存在过这样一个错误的认识：为了使得 ZooKeeper 集群能够顺利地选举出 Leader，必须将 ZooKeeper 集群的服务器数部署成奇数。这里我们需要澄清的一点是：任意台 ZooKeeper 服务器都能部署且能正常运行。

那么存在于这么多读者中的这个错误认识是怎么回事呢？其实关于 ZooKeeper 集群服务器数，ZooKeeper 官方确实给出了关于奇数的建议，但绝大部分 ZooKeeper 用户对于这个建议认识有偏差。在本书前面提到的“过半存活即可用”特性中，我们已经了解了，一个 ZooKeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。基于这个特性，如果想搭建一个能够允许 N 台机器 down 掉的集群，那么就要部署一个由 2*N+1 台服务器构成的 ZooKeeper 集群。因此，一个由 3 台机器构成的 ZooKeeper 集群，能够在挂掉 1 台机器后依然正常工作，而对于一个由 5 台服务器构成的 ZooKeeper 集群，能够对 2 台机器挂掉的情况进行容灾。注意，如果是一个由6台服务器构成的 ZooKeeper 集群，同样只能够挂掉 2 台机器，因为如果挂掉 3 台，剩下的机器就无法实现过半了。

因此，从上面的讲解中，我们其实可以看出，对于一个由 6 台机器构成的 ZooKeeper 集群来说，和一个由 5 台机器构成的 ZooKeeper 集群，其在容灾能力上并没有任何显著的优势，反而多占用了一个服务器资源。基于这个原因，ZooKeeper 集群通常设计部署成奇数台服务器即可。

在详细看为什么 zookeeper 选择奇数节点数？

　①、容错率

　　首先从容错率来说明：（需要保证集群能够有半数进行投票）

　　2台服务器，至少2台正常运行才行（2的半数为1，半数以上最少为2），正常运行1台服务器都不允许挂掉，但是相对于单节点服务器，2台服务器还有两个单点故障，所以直接排除了。

　　3台服务器，至少2台正常运行才行（3的半数为1.5，半数以上最少为2），正常运行可以允许1台服务器挂掉

　　4台服务器，至少3台正常运行才行（4的半数为2，半数以上最少为3），正常运行可以允许1台服务器挂掉

　　5台服务器，至少3台正常运行才行（5的半数为2.5，半数以上最少为3），正常运行可以允许2台服务器挂掉

　②、防脑裂

　　脑裂集群的脑裂通常是发生在节点之间通信不可达的情况下，集群会分裂成不同的小集群，小集群各自选出自己的leader节点，导致原有的集群出现多个leader节点的情况，这就是脑裂。

　　3台服务器，投票选举半数为1.5，一台服务裂开，和另外两台服务器无法通行，这时候2台服务器的集群（2票大于半数1.5票），所以可以选举出leader，而 1 台服务器的集群无法选举。

　　4台服务器，投票选举半数为2，可以分成 1,3两个集群或者2,2两个集群，对于 1,3集群，3集群可以选举；对于2,2集群，则不能选择，造成没有leader节点。

　　5台服务器，投票选举半数为2.5，可以分成1,4两个集群，或者2,3两集群，这两个集群分别都只能选举一个集群，满足zookeeper集群搭建数目。

　　以上分析，我们从容错率以及防止脑裂两方面说明了3台服务器是搭建集群的最少数目，4台发生脑裂时会造成没有leader节点的错误。

三、容灾

所谓容灾，在 IT 行业通常是指我们的计算机信息系统具有的一种在遭受诸如火灾、地震、断电和其他基础网络设备故障等毁灭性灾难的时候，依然能够对外提供可用服务的能力。

对于一些普通的应用，为了达到容灾标准，通常我们会选择在多台机器上进行部署来组成一个集群，这样即使在集群的一台或是若干台机器出现故障的情况下，整个集群依然能够对外提供可用的服务。

而对于一些核心应用，不仅要通过使用多台机器构建集群的方式来提供服务，而且还要将集群中的机器部署在两个机房，这样的话，即使其中一个机房遭遇灾难，依然能够对外提供可用的服务。

上面讲到的都是应用层面的容灾模式，那么对于 ZooKeeper 这种底层组件来说，如何进行容灾呢？讲到这里，可能多少读者会有疑问，ZooKeeper 既然已经解决了单点问题，那为什么还要进行容灾呢？

3.1 单点问题

单点问题是分布式环境中最常见也是最经典的问题之一，在很多分布式系统中都会存在这样的单点问题。

具体地说，单点问题是指在一个分布式系统中，如果某一个组件出现故障就会引起整个系统的可用性大大下降甚至是处于瘫痪状态，那么我们就认为该组件存在单点问题。

ZooKeeper 确实已经很好地解决了单点问题。我们已经了解到，基于“过半”设计原则，ZooKeeper 在运行期间，集群中至少有过半的机器保存了最新的数据。因此，只要集群中超过半数的机器还能够正常工作，整个集群就能够对外提供服务。

3.2 容灾

解决了单点问题，是不是该考虑容灾了呢？答案是否定的，在搭建一个高可用的集群的时候依然需要考虑容灾问题。正如上面讲到的，如果集群中超过半数的机器还在正常工作，集群就能够对外提供正常的服务。

那么，如果整个机房出现灾难性的事故，这时显然已经不是单点问题的范畴了。

在进行 ZooKeeper 的容灾方案设计过程中，我们要充分考虑到“过半原则”。也就是说，无论发生什么情况，我们必须保证 ZooKeeper 集群中有超过半数的机器能够正常工作。因此，通常有以下两种部署方案。

3.3.1 双机房部署

在进行容灾方案的设计时，我们通常是以机房为单位来考虑问题。在现实中，很多公司的机房规模并不大，因此双机房部署是个比较常见的方案。但是遗憾的是，在目前版本的 ZooKeeper 中，还没有办法能够在双机房条件下实现比较好的容灾效果——因为无论哪个机房发生异常情况，都有可能使得 ZooKeeper 集群中可用的机器无法超过半数。当然，在拥有两个机房的场景下，通常有一个机房是主要机房（一般而言，公司会花费更多的钱去租用一个稳定性更好、设备更可靠的机房，这个机房就是主要机房，而另外一个机房则更加廉价一些）。我们唯一能做的，就是尽量在主要机房部署更多的机器。例如，对于一个由 7 台机器组成的 ZooKeeper 集群，通常在主要机房中部署 4 台机器，剩下的 3 台机器部署到另外一个机房中。

3.3.2 三机房部署

既然在双机房部署模式下并不能实现好的容灾效果，那么对于有条件的公司，选择三机房部署无疑是个更好的选择，无论哪个机房发生了故障，剩下两个机房的机器数量都超过半数。假如我们有三个机房可以部署服务，并且这三个机房间的网络状况良好，那么就可以在三个机房中都部署若干个机器来组成一个 ZooKeeper 集群。

我们假定构成 ZooKeeper 集群的机器总数为 N，在三个机房中部署的 ZooKeeper 服务器数分别为 N₁、N₂ 和 N₃，如果要使该 ZooKeeper 集群具有较好的容灾能力，我们可以根据如下算法来计算 ZooKeeper 集群的机器部署方案。

1. 计算 N₁

如果 ZooKeeper 集群的服务器总数是 N，那么：

N1 = (N-1)/2

在 Java 中，“/” 运算符会自动对计算结果向下取整操作。举个例子，如果 N=8，那么 N₁=3；如果 N=7，那么 N₁ 也等于 3。

2. 计算 N₂ 的可选值

N₂ 的计算规则和 N₁ 非常类似，只是 N₂的取值是在一个取值范围内：

N2 的取值范围是 1~(N-N1)/2

即如果 N=8，那么 N₁=3，则 N₂ 的取值范围就是 1~2，分别是 1 和 2。注意，1 和 2 仅仅是 N₂ 的可选值，并非最终值——如果 N₂为某个可选值的时候，无法计算出 N₃ 的值，那么该可选值也无效。

3. 计算 N₃，同时确定 N₂ 的值

很显然，现在只剩下 N₃ 了，可以简单的认为 N₃ 的取值就是剩下的机器数，即：

N3 = N - N1 - N2

只是 N₃ 的取值必须满足 N₃ < N₁+N2。在满足这个条件的基础下，我们遍历步骤 2 中计算得到的 N₂ 的可选值，即可得到三机房部署时每个机房的服务器数量了。

现在我们以 7 台机器为例，来看看如何分配三机房的机器分布。根据算法的步骤 1，我们首先确定 N₁ 的取值为 3。根据算法的步骤 2，我们确定了 N₂ 的可选值为 1 和 2。最后根据步骤 3，我们遍历 N₂ 的可选值，即可得到两种部署方案，分别是 (3,1,3) 和 (3,2,2)。以下是 Java 程序代码对以上算法的一种简单实现：

public class Allocation {
     
    static final int n = 7;
    public static void main(String[] args){
        int n1,n2,n3;
        n1 = (n-1) / 2;
        int n2_max = (n-n1) / 2;
        for(int i=1; i<=n2_max; i++){
            n2 = i;
            n3 = n - n1 -n2;
            if(n3 >= (n1+n2)){
                continue;
            }
            System.out.println("("+n1+","+n2+","+n3+")");
        }
    }
}

四、水平扩容

水平可扩容可以说是对一个分布式系统在高可用性方面提出的基本的，也是非常重要的一个要求，通过水平扩容能够帮助系统在不进行或进行极少改进工作的前提下，快速提高系统对外的服务支撑能力。简单地讲，水平扩容就是向集群中添加更多的机器，以提高系统的服务质量。

很遗憾的是，ZooKeeper 在水平扩容扩容方面做得并不十分完美，需要进行整个集群的重启。通常有两种重启方式，一种是集群整体重启，另外一种是逐台进行服务器的重启。

4.1 整体重启

所谓集群整体重启，就是先将整个集群停止，然后更新 ZooKeeper 的配置，然后再次启动。如果在你的系统中，ZooKeeper 并不是个非常核心的组件，并且能够允许短暂的服务停止（通常是几秒钟的时间间隔），那么不妨选择这种方式。在整体重启的过程中，所有该集群的客户端都无法连接上集群。等到集群再次启动，这些客户端就能够自动连接上——注意，整体启动前建立起的客户端会话，并不会因为此次整体重启而失效。也就是说，在整体重启期间花费的时间将不计入会话超时时间的计算中。

4.2 逐台重启

这种方式更适合绝大多数的实际场景。在这种方式中，每次仅仅重启集群中的一台机器，然后逐台对整个集群中的机器进行重启操作。这种方式可以在重启期间依然保证集群对外的正常服务。

参考文章：https://www.cnblogs.com/cyfonly/p/5626532.html

posted @ 2021-12-23 11:03 VicLW 阅读(2968) 评论(0) 编辑收藏举报

刷新页面返回顶部

VicLiu

人生近看是悲剧，远看是喜剧。

Zookeeper 集群部署

一、运行模式

1.1 单机模式

1. 准备 Java 运行环境

2. 下载 ZooKeeper 安装包

3. 配置 zoo.cfg

4. 启动服务

1.2 集群模式

1. 准备 Java 运行环境（同上）

2. 下载 ZooKeeper 安装包（同上）

3. 配置 zoo.cfg

4. 创建 myid 文件

5. 按照相同步骤，为其他机器配置 zoo.cfg 和 myid文件

6. 启动服务

1.3 伪集群模式

二、集群组成

三、容灾

3.1 单点问题

3.2 容灾

3.3.1 双机房部署

3.3.2 三机房部署

1. 计算 N₁

2. 计算 N₂ 的可选值

3. 计算 N₃，同时确定 N₂ 的值

四、水平扩容

4.1 整体重启

4.2 逐台重启

公告

VicLiu

人生近看是悲剧，远看是喜剧。

Zookeeper 集群部署

一、运行模式

1.1 单机模式

1. 准备 Java 运行环境

2. 下载 ZooKeeper 安装包

3. 配置 zoo.cfg

4. 启动服务

1.2 集群模式

1. 准备 Java 运行环境（同上）

2. 下载 ZooKeeper 安装包（同上）

3. 配置 zoo.cfg

4. 创建 myid 文件

5. 按照相同步骤，为其他机器配置 zoo.cfg 和 myid文件

6. 启动服务

1.3 伪集群模式

二、集群组成

三、容灾

3.1 单点问题

3.2 容灾

3.3.1 双机房部署

3.3.2 三机房部署

1. 计算 N1

2. 计算 N2 的可选值

3. 计算 N3，同时确定 N2 的值

四、水平扩容

4.1 整体重启

4.2 逐台重启

公告

1. 计算 N₁

2. 计算 N₂ 的可选值

3. 计算 N₃，同时确定 N₂ 的值