ZooKeeper 是分布式环境下非常重要的一个中间件，可以完成动态配置推送、分布式 Leader 选举、分布式锁等功能。在运维 ZooKeeper 服务的以来，积累如下经验：
1. 集群数量
3台起，如果是虚拟机，必须分散在不同的宿主机上，以实现容灾的目的。如果长远来看（如2-3年）需求会持续增长，可以直接部署5台。ZooKeeper集群扩容是比较麻烦的事情，因此宁可前期稍微浪费一点。
2. 客户端配置域名而不是 IP
如果有一天你的 ZooKeeper 集群需要做机房迁移，或者其中几个节点机器挂了，需要更换。让你的用户更新 ZooKeeper 服务器配置不是件轻松的事情，因此一开始就配置好域名，到时候更新 DNS 即可。
3. 开启 autopurge.snapRetainCount
ZooKeeper 默认不会自动清理 tx log，所以总会有一天你会收到磁盘报警（如果你有磁盘监控的话）。开启自动清理机制后，就不用担心了，我的配置如下：
autopurge.snapRetainCount=500 autopurge.purgeInterval=24
4. 扩容
如果你可以接受停止服务半个小时，那基本随意玩了，但在比较严肃的环境下，还是不能停服务的。我的做法是这样的：
0. 有节点 A, B, C 处于服务状态
server.3=192.168.12.1:2888:3888 server.4=192.168.12.2:2888:3888 server.5=192.168.12.3:2888:3888
1. 加入节点 D，配置如下：
server.3=192.168.12.1:2888:3888 server.4=192.168.12.2:2888:3888 server.5=192.168.12.3:2888:3888 server.6=192.168.12.4:2888:3888 server.7=192.168.12.5:2888:3888
用 4 字命令检查，保证该节点同步完毕集群数据，处于 Follower 状态：
# echo srvr | nc 192.168.12.4 2181 Zookeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT Latency min/avg/max: 0/0/13432 Received: *** Sent: *** Connections: *** Outstanding: 0 Zxid: 0x*** Mode: follower Node count: ***
需要注意的是，这一步加入的节点的 id，必须大于集群中原有的节点的 id，例如 6 > 3,4,5，我也不知道为什么需要这样。
2. 同上一步一样，加入节点 E
3. 更新 A B C 的配置如 D 和 E，并依此重启
5. 机房迁移
例如要把服务从 X 机房的 A B C 迁移到 Y 机房的 A’ B’ C’。 做法是首先把集群扩容成包含6个节点的集群；然后修改域名指向让用户的连接都转到 A’ B’ C’；最后更新集群配置，把 A B C 从集群摘除。
6. 跨机房容灾
由于 ZooKeeper 天生不喜欢偶数（怕脑裂），因此有条件的就三机房部署，但机房之间的网络条件得是类似局域网的条件，否则性能就堪忧了。 双机房做自动容灾基本不可能，加入手动步骤是可以的，和 DB 一样，短时间不可用，立刻启用另外一个机房，平时保证数据同步。 三机房部署，如果一个机房离的比较远，网络延迟较高怎么办？可以 3 + 3 + 1 部署，1 就放在那个网络延迟较高的地方，确保 leader 在 3 + 3 这两个机房中间，那么平时的性能就能保证了。怎么保证 leader 不到 1 呢？目前能想到的办法就是如果发现就重启它
