Zookeeper 集群

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

Leader 选举

Zookeeper 的启动过程中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 一样,当小弟

搭建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 的data 目录（zoo.cfg）

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

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

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

    dataDir=/usr/local/zookeeper-cluster/zookeeper-2/data

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

    dataDir=/usr/local/zookeeper-cluster/zookeeper-3/data

配置集群

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

[root@localhost zookeeper-cluster]# cd zookeeper-1
[root@localhost zookeeper-1]# cd data
[root@localhost data]# ll
total 0
[root@localhost data]# echo 1 > myid
[root@localhost data]# ll
total 4
-rw-r--r-- 1 root root 2 Aug 31 03:44 myid
[root@localhost data]# cat myid
1
[root@localhost data]#
[root@localhost data]#
[root@localhost data]# cd ../..
[root@localhost zookeeper-cluster]# cd zookeeper-2
[root@localhost zookeeper-2]# cd data
[root@localhost data]# echo 2 > myid
[root@localhost data]# cd ../..
[root@localhost zookeeper-cluster]# cd zookeeper-3
[root@localhost zookeeper-3]# cd data
[root@localhost data]# echo 3 > myid

如果你要创建的文本文件内容比较简单，我们可以通过echo 命令快速创建文件

格式为：
echo 内容>文件名
例如我们为第一个zookeeper 指定ID 为1，则输入命令

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

表， 每个服务器的clientPort 分别为2181 2182 2183

集群服务器IP 列表如下

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

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

启动集群：

启动集群就是分别启动每个实例。

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

先查询第一个服务

Mode 为follower 表示是跟随者（从）

再查询第二个服务Mod 为leader 表示是领导者（主）

查询第三个为跟随者（从）

模拟集群异常

（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.135:2181,192.168.25.135:2182,192.168.25.135:2183">
</dubbo:registry>