集群的搭建，这里就不详细介绍了，网上有很多教程，关键是找到适合自己的。
在集群启动过程中，会进行一次leader选举。
我们经常会有一个错误的认知：为了能顺利选举出leader，必须将zookeeper集群的服务部署成奇数。
其实zookeeper集群是存在过半存活即可用的原则的，我们部署5台服务器和部署6台服务器，都是挂掉2台能正常运行，挂掉3台整个集群都不能用了。既然是这样，6台机器在容灾上并没有什么明显的优势，所以，zookeeper通常设计成奇数台。
单点问题：
指在一个分布式系统中，如果某一个组件出现故障，就会引起整个系统的可用性大大下降甚至瘫痪
但是zookeeper有一个过半的设计原则，可以很好的预防和解决单点问题。
容灾：
在普通应用上，为了容灾，我们会选择在不同的机器上来部署组成一个集群。----对单点问题的解决
但是对于一些核心应用，为了防止因为整个机房的意外情况，导致整个集群不可用，我们会在不同的机房中部署组成一个集群。
为了防止因机房意外造成的集群不可用，我们会在不同机房部署，但是大多公司还是最多只能提供两个机房的，3个机房就很奢侈了。所以我们会在这两个机房中，安全性比较好的机房多部署机器来预防。
扩容：
作为分布式系统，水平可扩容可以说是在高可用方面提出的基本的要求。
水平扩容就是：能帮助系统在不进行或进行极少改进工作的前提下，快速提高系统对外的服务支撑能力。
但是zookeeper要支持水平扩容，就必须得重启集群---这如果对上线系统来说是非常不安全的。
重启集群有两种方式：
1、整体重启：将集群停止，更新zookeeper配置，再次重启。-----要知道在集群停止的时候，客户端的请求是不会停止的，可想而知这样做的后果
2、逐台重启：每次重启一台机器，保证整个集群在修改配置的时候是可用的。
磁盘管理
在zookeeper中，但凡是对zookeeper数据状态的变更，都会以事务日志的形式写入磁盘。（跟MySQL集群和redis集群有点像）并且只有当集群中过半的服务器已经记录了该事务日志后，服务端才会给予客户端相应。
另一方面，zookeeper还会定时将内存数据库中的所有数据和所有客户端的会话消息记录进行快照，保存到磁盘。
这两种操作，都会影响zookeeper的处理速度。
所以我们在选择磁盘的时候，尽量使用单独磁盘作为事务日志的输出目录。
参考书籍《zookeeper分布式一致性原理与实践》