ZooKeeper之（五）集群管理

在一台机器上运营一个ZooKeeper实例，称之为单机（Standalone）模式。单机模式有个致命的缺陷，一旦唯一的实例挂了，依赖ZooKeeper的应用全得完蛋。

实际应用当中，一般都是采用集群模式来部署ZooKeeper，集群中的Server为奇数（2N+1）。只要集群中的多数（大于N+1台）Server活着，集群就能对外提供服务。

在每台机器上部署一个ZooKeeper实例，多台机器组成集群，称之为完全分布式集群。此外，还可以在仅有的一台机器上部署多个ZooKeeper实例，以伪集群模式运行。

5.1 集群配置

下面我们来建一个3个实例的zookeeper伪分布式集群。

首先，需要为三个实例创建不同的配置文件：

zk1.cfg的配置项如下：

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/zk1/dataDir

clientPort=2181

server.1=127.0.0.1:2888:3888

server.2=127.0.0.1:2889:3889

server.3=127.0.0.1:2890:3890

zk2.cfg的配置项如下：

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/zk2/dataDir

clientPort=2182

server.1=127.0.0.1:2888:3888

server.2=127.0.0.1:2889:3889

server.3=127.0.0.1:2890:3890

zk3.cfg的配置项如下：

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/zk3/dataDir

clientPort=2183

server.1=127.0.0.1:2888:3888

server.2=127.0.0.1:2889:3889

server.3=127.0.0.1:2890:3890

因为部署在同一台机器上，所以每个实例的dataDir、clientPort要做区分，其余配置保持一致。

需要注意的是，集群中所有的实例作为一个整体对外提供服务，集群中每个实例之间都互相连接，所以，每个配置文件中都要列出所有实例的映射关系。

在每个配置文件的末尾，有几行“server.A=B：C：D”这样的配置，其中， A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。

除了修改 zoo.cfg 配置文件，集群模式下还要配置一个myid文件，这个文件在 dataDir 目录下，文件里只有一个数据，就是 A 的值，Zookeeper 启动时会读取这个文件，拿到里面的数据与配置信息比较从而判断到底是那个 Server。

上例中，需要在每个实例各自的dataDir目录下，新建myid文件，分别填写“1”、“2”、“3”。

5.2 集群启动

依次启动三个实例：

查看Server状态：

可见，现在的集群中，zk2充当着Leader角色，而zk1与zk3充当着Follower角色。

使用三个客户端连接三个Server，在zk1的客户端下，新增“/newNode”节点，储存数据“zk1”：

在zk2的客户端与查看该节点：

在zk3的客户端与查看该节点：

可见，集群中的Server保持着数据同步。

5.3 集群容灾

如果我们把身为Leader的zk2关闭，会发生什么呢？

可见，集群自动完成了切换，zk3变成了Leader。实际应用中，如果集群中的Leader宕机了，或者Leader与超过半数的Follower失去联系，都会触发ZooKeeper的选举流程，选举出新的Leader之后继续对外服务。

如果我们再把zk3关闭，会发生什么呢？

可见，关闭zk3以后，由于集群中的可用Server只剩下一台（达不到集群总数的半数以上），集群将处于不可用的状态。