zookeeper有两种运行模式：独立模式和仲裁模式。独立模式就是只运行一个Zookeeper Server，这自然没法解决服务崩溃导致系统不可用的问题。仲裁模式就是以集群的方式运行Zookeeper Server，这样在Leader不可用时，集群内部会发起选举，而推选一个新的Leader。既然我们要使用zookeeper，肯定是有分布式协作需求，所以本文只讲述仲裁模式的部署。（转载请指明出于breaksoftware的csdn博客）
为了方便大家测试，我们将Zookeeper Server部署在同一台机器上，通过对外提供不同的端口号来模拟多机部署。
首选我们要选择部署几个Server服务（不考虑Observer）。2个？3个？4个？如果一定要在三个数字中选，大部分建议是选择3个。
如果选择2，那么依据少数服从多数的原则，要求Leader的必须获得2票。如果坏了一台机器，剩下的那台机器肯定得不到2票，那么整个系统将不可用。于是损失一台机器的系统可用率是0。
如果选择是3，要求Leader的票数也必须>=2。如果坏了一台机器，剩下的两台机器可以抉择出哪台可以得到2票，从而系统可用。如果又坏了一台，剩下一台机器不可能得到2票。于是损失一台机器的系统可用率是100%，损失两台机器的系统可用率是0。
如果选择4，要求Leader的票数>=3。如果坏了一台机器，剩下的三台机器可以抉择出哪台可以得到3票，从而系统可用。如果又坏了一台，剩下的两台机器不可能得到3票。于是损失一台机器的系统可用率是100%，损失两台机器的系统可用率是0。
| 集群机器数 | 损失1台机器系统可用率 | 损失2台机器系统可用率 |
| 2 | 0 | 0 |
| 3 | 100% | 0 |
| 4 | 100% | 0 |
可以看出来在损失2台机器的情况下，集群部署3台或者4台的系统可用率是相等的。部署4台并不比部署3台要可靠。
也许有人开始质疑“少数服从多数”这个选举原则。如果4台机器只要有机器获得2票，就可以被认为是Leader，那不就提高了可用率了么？答案是这样的设计会导致严重的问题。
如下图，ABCD构成了一个集群，其中A是Leader。开始时甲连接的是A机器，ABCD各机器上服务保持了数据一致性。假如此时乙用户要连接任何一台服务，那么甲乙对数据的修改是彼此透明的。
但是，如果此时CD和AB断开了连接。以获得2票成为Leader的原则，很有可能CD选举出C为Leader，D从此和C同步数据。AB选举出A为Leader，B只和A同步数据。假如此时乙用户要接入，而不巧接入到C或者D。那么甲乙对数据的修改就是隔离的。这样一个系统中出现两个Leader的现象称之为“脑裂”，这当然是不能接受的。
选择好数量后，我们从https://www.apache.org/dyn/closer.cgi/zookeeper/下载并解压压缩包。以我环境为例，解压后文件路径为
$ pwd /home/work/fangliang/zookeeper-3.4.11
进入该目录，新建一个叫multi_server的文件夹。然后在其下新建z1、z2和z3三个目录，这三个目录分别用于保存三个Zookeeper Server的信息。
mkdir multi_server cd multi_server mkdir -p z1/data mkdir -p z2/data mkdir -p z3/data echo 1 > z1/data/myid echo 2 > z2/data/myid echo 3 > z3/data/myid
myid文件的内容是其对应的服务id。
然后在z1、z2和z3下分别创建z1.cfg,z2.cfg,z3.cfg三个文件。以z1.cfg为例，我们在文件中填充
tickTime=2000 initLimit=10 syncLimit=5 dataDir=/home/work/fangliang/zookeeper-3.4.11/multi_server/z1/data clientPort=2181 server.1=127.0.0.1:2222:2223 server.2=127.0.0.1:3333:3334 server.3=127.0.0.1:4444:4445
相应的，我们需要将z2.cfg和z3.cfg文件中dataDir指向自己目录，clientPort指向其他的端口
dataDir=/home/work/fangliang/zookeeper-3.4.11/multi_server/z2/data clientPort=2182
dataDir=/home/work/fangliang/zookeeper-3.4.11/multi_server/z3/data clientPort=2183
整个文件的目录树如下
multi_server/
|-- z1
| |-- data
| | |-- myid
| |-- z1.cfg
|-- z2
| |-- data
| | |-- myid|
| |-- z2.cfg
`-- z3
|-- data
| |-- myid
`-- z3.cfg
接下来我们开始启动各个服务。
首先启动z1。
且到z1目录下，执行
../../bin/zkServer.sh start ./z1.cfg当前目录下会生成一个日志文件zookeeper.out。
第三行我们看到它发起了一次选举，但是由于其他两个服务没有启动，所以整个系统还不可用。
然后我们启动z2。
切到z2目录下，执行
../../bin/zkServer.sh start ./z2.cfg
我们查看下z2目录下日志文件
第三行显示z2也发起了一次选举，由于此时z3没有启动，所以它只能和z1进行通信。最终它们使用FastLeaderElection协商出z2作为Leader。
然后z2和z1进行了数据同步。
我们再看下z1日志的变化。
z1仍然和z3通信失败。但是和z2通信后，自己成为了follower。
最后我们启动z3。
切到z3目录下执行
../../bin/zkServer.sh start ./z3.cfg
查看z3的日志
z3发起了一次选举，但是z2此时已经是leader了，所以z3顺理成章的成为follower，并从z2服务同步了一份数据快照
此时看下z1的日志，它发现了z3
再看下z2的日志，它发现z3后，给z3同步了一次数据
我们切换到bin目录，执行
./zkCli.sh -server 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183
让Client连接到上述三台机器中的一台，可以看到如下显示
