背景
近期在看Apache的项目zookeeper，根据官网文档，在自己本地虚拟机上实践了下zookeeper的基本用法。
验证集群的高可用性这个特征一直没有成功，不知道哪里操作不正确，把leader节点的服务stop后，其他follower中没有产生新的leader，并且这些follower自身的zookeeper服务也无法使用，操作流程是正确的。
环境准备
从官网下载zookeeper的稳定版本zookeeper-3.4.8.tar.gz，开启三个虚拟机，并将该压缩包上传到三个虚拟机目录下。
SSH分别连接三个虚拟机，进入上传目录，执行解压操作：
tar xvf zookeeper-3.4.8.tar.gz
zookeeper环境安装完成。
集群配置
zookeeper的启动需要/zookeeper-3.4.8/conf目录下的zoo.cfg配置文件，部署包中提供了一个zoo_sample.cfg文件作为参考。
第一步，编写集群配置信息。
集群配置需要启动2N+1台机器，实践时使用了3台虚拟机，编号分别是：
server.1=192.168.10.154:2888:3888
server.2=192.168.10.167:2888:3888
server.3=192.168.10.170:2888:3888
zookeeper集群中的节点需要知道彼此的存在，所以需要对每个zoo.cfg配置添加上述配置，每个集群的zookeeper服务端口统一为2181。为了方便，三个集群节点的zoo.cfg配置文件可以相同。如下：
第二步，为每个集群创建myid进程文件，写入对应节点的编号。
上图红框的编号1，2，3即每个虚拟机的myid文件的内容。myid文件位于dataDir目录下。
分别在每个虚拟机上执行如下操作：
cd /opt/zookeeper-data
touch myid
写入对应的编号1，2，3
实践发现，集群replicated模式下，这个myid文件必须创建，否则服务启动会失败；但standalone模式下可以不需要这个文件。
服务启动
zookeeper-3.4.8的bin目录下是相关的服务脚本。按照服务器的编号，依次启动zookeeper服务器操作如下：
cd /zk/zookeeper-3.4.8/bin
sh zkServer.sh start
sh zkServer.sh status
查看三个集群的状态，可以看到一个leader，2个follower。
基本操作
SSH连接到在一个follower节点192.168.10.167虚拟机后，创建zkClient，执行create创建节点操作如下：
sh zkCli.sh -server 127.0.0.1:2181
ls /
create /helloworld a
再连接另一个follower节点192.168.10.170虚拟机，创建zkClient客户端查看节点信息：
sh zkCli.sh -server 127.0.0.1:2181
ls /
实践结果显示，followere服务器自动同步了最新的节点信息。
实践总结
发现两个问题：
首先，正常调用zkServer.sh的start命令后，没有报错信息，但是status查看时却得到服务未运行的信息。重启虚拟机后，再次重启服务，能正常运行。
其次，如果将leader虚拟机的zookeeper服务stop掉，那么其他两个follower的zookeeper服务也会立即失效。但是反之，follower的服务停止对leader没有影响。这与官网上说的高可用性有点矛盾：停掉leader之后，并没有产生新的leader，而且其他集群节点都失效了。
对于集群的可用性验证，反复执行了十几遍，还是没有产生新的leader的。如果建立5个虚拟机节点来测试leader的选举能不能成功呢？
后记：重新搭建了一个环境，验证可用性成功了。