Zookeeper——集群搭建 & 选举机制

Posted 2022-08-01 张起灵-小哥

文章目录：

1.前言

2.步骤详解

3.选举机制

3.1 第一次启动

3.2 非第一次启动

---

1.前言

继上一篇文章中，我学过了Zookeeper的一些概念、配置文件以及Linux下本地启动。那么这篇文章来讲讲关于Zookeeper集群的相关操作步骤。

---

2.步骤详解

首先我们需要准备三台机器，这里就对我原有的Linux进行链接克隆，再克隆两台，一共三台就可以了。克隆完之后，我们首先需要对克隆的这两台机器的ip、主机名做一下修改。

修改 ip 命令如下：👇👇👇 我这里的三台机器分别是 130、131、132，大家根据自己的去修改。

vi /etc/sysconfig/network-scripts/ifcfg-ens33

#下面这条命令在修改完上面的ip地址之后执行，重启网络服务
systemctl restart network

修改主机名，同时将 ip 与主机名形成映射关系。分别对应下面的命令：👇👇👇

我这里是将三台机器的主机名设置成了 zk101、zk102、zk103。  修改完成之后，可以使用hostname命令查看

hostnamectl set-hostname zk101

hostnamectl set-hostname zk102

hostnamectl set-hostname zk103

vi /etc/hosts

下面要做的就是将 zookeeper 压缩包分别上传至 zk102、zk103 这两台机器上，rz -E 可以、Xftp也行、或者windows找到压缩包直接拉取也行。

之后解压、改名、修改配置文件、创建zkData等这些步骤我就不再详细说了，大家可以参考：https://blog.csdn.net/weixin_43823808/article/details/124593569 

---

下面就是集群搭建的新步骤，首先需要修改每台机器上的zookeeper的配置文件：zoo.cfg，重要的是最后的那几行配置，这里我是在 zk102 上先修改的，这个无所谓，修改完成之后，可以到 zk101、zk103上做同样的修改。

这里我对上面配置文件中的server.1=zk101:2888:3888这行配置做个简单解释：

server.A=B:C:D

A 是一个数字，表示这个是第几号服务器； 集群模式下配置一个文件 myid ，这个文件在 dataDir 目录下，这个文件里面有一个数据 就是 A 的值， Zookeeper 启动时读取此文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是哪个 server 。 B 是这个服务器的地址； C 是这个服务器 Follower 与集群中的 Leader 服务器交换信息的端口； D 是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。

---

然后我们需要配置一个新东西，叫服务器编号。

在/opt/module/zookeeper-3.5.7/zkData 目录下创建一个 myid 的文件。在文件中添加与 server 对应的编号（注意：上下不要有空行，左右不要有空格） ，也就是 zk101的myid为1、zk102的myid为2、zk103的myid为3。

 

 

以上需要配置的我们配置了，需要修改的我们修改了，下面就可以依次启动集群了。

 

 

三台机器都启动成功之后，下面使用命令查看集群中各个节点的状态，看看谁是 Leader、谁是 Follower。

以上，关于zookeeper的集群搭建及启动就完成了，如果大家感觉这样一次一次启动太麻烦，也可以写一个shell脚本，来完成对三台zookeeper的一次性启动。

#!/bin/bash

case $1 in
"start")
	for i in 192.168.40.130 192.168.40.131 192.168.40.132
	do
		echo ---------------- zookeeper $i 启动 ----------------
		ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh start"
	done

;;
"stop")
	for i in 192.168.40.130 192.168.40.131 192.168.40.132
	do
		echo ---------------- zookeeper $i 停止 ----------------
		ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh stop"
	done

;;
"status")
	for i in 192.168.40.130 192.168.40.131 192.168.40.132
	do
		echo ---------------- zookeeper $i 状态 ----------------
		ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh status"
	done

;;
esac

写好之后，我们在 /bin 目录下，创建一个可执行脚本：zk.sh，将上面写好的内容copy进去，之后 :wq！保存退出即可。

如果说这个脚本的执行权限不够，可以执行 chmod 777 zk.sh 为它赋予最大权限。最后执行就可以了。

从上面的脚本执行截图中可以看到，我们写的 start、status都是可以正常执行的。 

---

3.选举机制

3.1 第一次启动

我们假设这个zookeeper集群有5台服务器，下面简单说一下它的流程。

（ 1 ）服务器 1 启动，发起一次选举。服务器 1是自私的，那么它先 投自己一票。此时服务器 1 票数一票，不够半数以上（3票），选举无法完成，服务器 1 状态保持为 LOOKING；

（2）服务器 2 启动，再发起一次选举。服务器 1 和 2 分别投自己一票（此时服务器1有1票、服务器2有1票），然后服务器2会与服务器1交换选票信息：服务器2会把自己这1票先给服务器1，那么服务器1就有1+1=2票，服务器2就有1-1=0票， 此时服务器 1 发现服务器 2 的 myid 比自己目前投票推举的（服务器 1 ）大，它就会更改选票为推举服务器2，同时将自己手中的2票再交换给服务器2 。 此时服务器 1 票数 0 票，服务器 2 票数 2 票，票数也没有达到集群半数以上的结果，选举无法完成，服务器 1 ， 2 状态保持 LOOKING。

 

（3）服务器 3启动，发起一次选举。服务器3仍然会向第二步那样与服务器2进行交换选票信息（服务器1是0票、服务器2是2票、服务器3投给自己所以是1票），那么服务器3和服务器2交换之后，服务器2就有2+1=3票、服务器3就有1-1=0票， 此时服务器2 发现服务器3 的 myid 比自己目前投票推举的（服务器2 ）大，它就会更改选票为推举服务器3，同时将自己手中的3票再交换给服务器3 。 此时服务器1 和 2 都会更改选票为服务器 3 。此次投票结果：服务器 1 为 0 票，服务器 2 为 0 票，服务器 3 为 3 票。此时服务器3 的票数已经超过集群中的半数，所以服务器 3 当选 Leader 。服务器 1、 2 更改状态为 FOLLOWING ，服务器 3 更改状态为 LEADING。

 

（4）服务器 4 启动，发起一次选举。此时服务器 1 ， 2 ， 3 已经不是 LOOKING 状态，不会更改选票信息。交换选票信息结果：服务器 3 为 3 票，服务器 4 为 1票。此时服务器 4 服从多数，更改选票信息为服务器 3 ，并更改状态为 FOLLOWING ； （5）服务器 5 启动，同 4 一样当小弟。  

3.2 非第一次启动

（1）当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举：

• 服务器初始化启动。
• 服务器运行期间无法和Leader保持连接。

（2）而当一台机器进入 Leader 选举流程时，当前集群也可能会处于以下两种状态：

• 集群中本来就已经存在一个Leader。 对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
• 集群中确实不存在Leader。 假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻， 3和5服务器出现故障，因此开始进行Leader选举。

SID 为 1 、 2 、 4的机器投票情况：  （ EPOCH ， ZXID ， SID ）            （ EPOCH ， ZXID ， SID ）               （ EPOCH ， ZXID ， SID ）                                                                 （ 1 ， 8 ， 1）                                  （ 1 ， 8 ， 2 ）                                      （ 1 ， 7 ， 4 ） 选举 Leader 规则： ① EPOCH 大的直接胜出 ；②EPOCH 相同，事务 id 大的胜出 ；③事务id 相同，服务器 id 大的胜出。