Zookeeper安装方式有三种，单机模式和集群模式以及伪集群模式。
■ 单机模式：Zookeeper只运行在一台服务器上，适合测试环境；
■ 伪集群模式：就是在一台物理机上运行多个Zookeeper 实例；
■ 集群模式：Zookeeper运行于一个集群上，适合生产环境，这个计算机集群被称为一个“集合体”（ensemble）
单机模式
下载 ZooKeeper，解压，将 conf 目录下的 zoo_sample.cfg 复制一份重命名为 zoo.cfg
cp zoo_sample.cfg zoo.cfg
然后直接启动 ZooKeeper 就行了
bin/zkServer.sh start
查看 ZooKeeper 运行状态
可以看到 ZooKeeper 的 Mode 是单机模式的(standalone)
使用客户端连接 ZK
本地连接
bin/zkCli.sh
远程连接 ZK
bin/zkCli.sh -server ip:port
停止 ZooKeeper
bin/zkServer.sh stop
伪集群模式
Zookeeper不但可以在单机上运行单机模式Zookeeper，而且可以在单机模拟集群模式 Zookeeper的运行，也就是将不同节点运行在同一台机器。我们在实验的时候，可以先使用少量数据在集群伪分布模式下进行测试。当测试可行的时候，再将数据移植到集群模式进行真实的数据实验。这样不但保证了它的可行性，同时大大提高了实验的效率。这种搭建方式，比较简便，成本比较低，适合测试和学习，如果你的手头机器不足，就可以在一台机器上部署了 3个server。
注意事项
在一台机器上部署了3个server，需要注意的是：在伪分布式模式下我们使用的每个配置文件模拟一台机器，也就是说单台机器上运行多个Zookeeper实例。但是，必须保证每个配置文档的各个端口号不能冲突，除了clientPort不同之外，dataDir也不同。另外，还要在dataDir所对应的目录中创建myid文件来指定对应的Zookeeper服务器实例。
■ clientPort端口：如果在1台机器上部署多个server，那么每台机器都要不同的 clientPort，比如 server1是2181,server2是2182，server3是2183
■ dataDir和dataLogDir：dataDir和dataLogDir也需要区分下，将数据文件和日志文件分开存放，同时每个server的这两变量所对应的路径都是不同的
■ server.X和myid： server.X 这个数字就是对应，data/myid中的数字。在3个server的myid文件中分别写入了1，2，3，那么每个server中的zoo.cfg都配 server.1 server.2,server.3就行了。因为在同一台机器上，后面连着的2个端口，3个server都不要一样，否则端口冲突。
同样将 conf 目录下的 zoo_sample.cfg 复制三份，分别重命名为 zoo1.cfg，zoo2.cfg，zoo3.cfg。
cp zoo_sample.cfg zoo1.cfg
cp zoo_sample.cfg zoo2.cfg
cp zoo_sample.cfg zoo3.cfg
然后分别修改每个配置文件，我的配置如下：
创建 zoox.cfg 配置文件中 dataDir 和 dataLogDir 的路径，
# 创建数据目录
mkdir -p /var/elvis/zookeeper/data/server1
mkdir -p /var/elvis/zookeeper/data/server2
mkdir -p /var/elvis/zookeeper/data/server3
# 创建日志文件目录
mkdir -p /var/elvis/zookeeper/logs/server1
mkdir -p /var/elvis/zookeeper/logs/server1
mkdir -p /var/elvis/zookeeper/logs/server1
在每个 dataDir 目录下常见一个 myid 文件并在其中写入 server 对应的序号，比如在 /var/elvis/zookeeper/data/server1 目录下创建一个 myid 文件，并在 myid 中写入 1，其他目录同理。
然后使用每个配置文件启动3个 ZooKeeper 实例：
bin/zkServer.sh stop conf/zoo1.cfg
bin/zkServer.sh stop conf/zoo2.cfg
bin/zkServer.sh stop conf/zoo3.cfg
可以使用 jps 来查看是否启动成功
jps -ml
查看 zk 的运行状态
bin/zkServer.sh status conf/zoo1.cfg
bin/zkServer.sh status conf/zoo2.cfg
bin/zkServer.sh status conf/zoo3.cfg
可以看到 ZK 的 Mode 不再是 standalone 了，而且 server2 作为 leader，其他2台server 作为 follower。
客户端连接 zk 集群
本地连接/远程连接
bin/zkCli.sh -server ip:2181
bin/zkCli.sh -server ip:2182
bin/zkCli.sh -server ip:2183
可以看见，我们远程连接任何一个端口都能够连接上。
上面我们知道 server2 是 leader，所以我们使用客户端连接到 server2上，然后创建一些节点。
bin/zkCli.sh -server 39.106.111.160:2182
create /zktest 123
现在我们在本地连接到 server1 看能不能看到刚才我们创建的节点。
bin/zkCli.sh -server localhost:2181
ls /
get /zktest
可以看到我们在 server1 上也获取到了刚才我们通过远程连接在 server2 上创建的 /zktest 数据。
现在我们尝试将 server2 这个leader 给停掉。
bin/zkServer.sh stop conf/zoo2.cfg
然后查看 server1和 server3 的运行状态
现在可以看到 ZooKeeper 通过选举，将 server3选举成了新的 leader。
这个时候我们刚才远程连接到 server2 的客户端开始报错了，zkCli.sh 客户端并没有实现连接断后，自动连接其他节点的功能。
这时我们再重启 server2
bin/zkServer.sh start conf/zoo2.cfg
然后再来查看各个 server 的运行状态
可以看到 server2 再次加入组织，不过 server2已经不再是 leader 了。
这个时候连接 sever2 的客户端也从报错中恢复过来。
集群模式
集群模式和伪分布式部署基本相同，唯一的区别就是 zoo.cfg 中，ip 配置不在是127.0.0.1 或 localhost 了，而是真正的机器 ip。
server.2= ip:2288:3388
