Zookeeper 集群

Zookeeper 集群简介

1、为什么搭建 Zookeeper 集群

大部分分布式应用需要一个主控、协调器或者控制器来管理物理分布的子进程。目前，
大多数都要开发私有的协调程序，缺乏一个通用机制，协调程序的反复编写浪费，且难以形
成通用、伸缩性好的协调器，zookeeper 提供通用的分布式锁服务，用以协调分布式应用。
所以说 zookeeper 是分布式应用的协作服务。
zookeeper 作为注册中心，服务器和客户端都要访问，如果有大量的并发，肯定会有等
待。所以可以通过 zookeeper 集群解决。

2、了解 Leader 选举

Zookeeper 的启动过程中 leader 选举是非常重要而且最复杂的一个环节。那么什么是
leader 选举呢？zookeeper 为什么需要 leader 选举呢？zookeeper 的 leader 选举的过程又是什
么样子的？
首先我们来看看什么是 leader 选举。其实这个很好理解，leader 选举就像总统选举一样，
每人一票，获得多数票的人就当选为总统了。在 zookeeper 集群中也是一样，每个节点都会
投票，如果某个节点获得超过半数以上的节点的投票，则该节点就是 leader 节点了。
以一个简单的例子来说明整个选举的过程.
假设有五台服务器组成的 zookeeper 集群,它们的 id 从 1-5,同时它们都是最新启动的,也
就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会
发生什么 。
1) 服务器 1 启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的
选举状态一直是 LOOKING 状态
2) 服务器 2 启动,它与最开始启动的服务器 1 进行通信,互相交换自己的选举结果,由于
两者都没有历史数据,所以 id值较大的服务器 2 胜出,但是由于没有达到超过半数以上的服务
器都同意选举它(这个例子中的半数以上是 3),所以服务器 1,2 还是继续保持 LOOKING 状态.
3) 服务器 3 启动,根据前面的理论分析,服务器 3 成为服务器 1,2,3 中的老大,而与上面不
同的是,此时有三台服务器选举了它,所以它成为了这次选举的 leader.
4) 服务器 4 启动,根据前面的分析,理论上服务器 4 应该是服务器 1,2,3,4 中最大的,但是
由于前面已经有半数以上的服务器选举了服务器 3,所以它只能接收当小弟的命了.
5) 服务器 5 启动,同 4 一样,当小弟

3、搭建 Zookeeper

真实的集群是需要部署在不同的服务器上的，但是在我们测试时同时启动十几个虚拟机
内存会吃不消，所以我们通常会搭建 伪集群，也就是把所有的服务都搭建在一台虚拟机上，
用端口进行区分。
我们这里要求搭建一个三个节点的 Zookeeper 集群（伪集群）。
部署一台虚拟机作为我们搭建集群的测试服务器。
（1）安装 JDK 【此步骤省略】。
（2）Zookeeper 压缩包上传到服务器
（3）将 Zookeeper 解压 ，创建 data 目录 ，将 conf 下 zoo_sample.cfg 文件改名为 zoo.cfg
（4）建立/usr/local/zookeeper-cluster 目录，将解压后的 Zookeeper 复制到以下三个目录
/usr/local/zookeeper-cluster/zookeeper-1
/usr/local/zookeeper-cluster/zookeeper-2
/usr/local/zookeeper-cluster/zookeeper-3
（5） 配置每一个 Zookeeper 的 dataDir（zoo.cfg） clientPort 分别为 2181 2182 2183
修改/usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg

[root@localhost ~]# mkdir /usr/local/zookeeper-cluster
[root@localhost ~]# cp -r zookeeper-3.4.6 /usr/local/zookeeper-cluster/zookeeper-1
[root@localhost ~]# cp -r zookeeper-3.4.6 /usr/local/zookeeper-cluster/zookeeper-2
[root@localhost ~]# cp -r zookeeper-3.4.6 /usr/local/zookeeper-cluster/zookeeper-3

修改/usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg

clientPort=2181
dataDir=/usr/local/zookeeper-cluster/zookeeper-1/data

(2、3同上)

4、配置集群

在每个 zookeeper 的 data 目录下创建一个 myid 文件，内容分别是 1、2、3 。这个
文件就是记录每个服务器的 ID

——- 知识点小贴士——
如果你要创建的文本文件内容比较简单，我们可以通过 echo 命令快速创建文件
格式为：
echo 内容 >文件名

在每一个 zookeeper 的 zoo.cfg 配置客户端访问端口（clientPort）和集群服务器 IP 列表。
集群服务器 IP 列表如下：

server.1=192.168.25.140:2881:3881
server.2=192.168.25.140:2882:3882
server.3=192.168.25.140:2883:3883

解释：server.服务器 ID=服务器 IP 地址：服务器之间通信端口：服务器之间投票选举端口

启动集群

启动集群就是分别启动每个实例。
zkServer.sh start

启动后我们查询一下每个实例的运行状态
zkServer.sh status

模拟集群异常

（1）首先我们先测试如果是从服务器挂掉，会怎么样
把 3 号服务器停掉，观察 1 号和 2 号，发现状态并没有变化
由此得出结论，3 个节点的集群，从服务器挂掉，集群正常
（2）我们再把 1 号服务器（从服务器）也停掉，查看 2 号（主服务器）的状态，发现已经停止运行了。
由此得出结论，3 个节点的集群，2 个从服务器都挂掉，主服务器也无法运行。因为可运行的机器没有超过集群总数量的半数。
（3）我们再次把 1 号服务器启动起来，发现 2 号服务器又开始正常工作了。而且依然是领导者。
（4）我们把 3 号服务器也启动起来，把 2 号服务器停掉（汗干嘛？领导了？）停掉后观察 1 号和 3 号的状态。
发现新的 leader 产生了~
由此我们得出结论，当集群中的主服务器挂了，集群中的其他服务器会自动进行举状态，然后产生新得 leader
（5）我们再次测试，当我们把 2 号服务器重新启动起来（汗这是诈尸啊!）启动后，会发生什么？2 号服务器会再次成为新的领导吗？我们看结果我们会发现，2 号服务器启动后依然是跟随者（从服务器），3 号服务器依然是领导者（主服务器），没有撼动 3 号服务器的领导地位。哎~退休了就是退休了，说了不算了，哈哈。
由此我们得出结论，当领导者产生后，再次有新服务器加入集群，不会影响到现任领导者。

Dubbox 连接 zookeeper 集群

修改服务提供者和服务调用者的 spring 配置文件

<!-- 指定注册中心地址 -->
<dubbo:registry
protocol="zookeeper"
address="192.168.25.140:2181,192.168.25.140:2182,192.168.25.140:2183">
</dubbo:registry>