zookeeper集群的目的是为了保证系统的性能承载更多的客户端连接设专门提供的机制。通过集群可以实现以下功能：
读写分离：提高承载，为更多的客户端提供连接，并保障性能。主从自动切换：提高服务容错性，部分节点故障不会影响整个服务集群。半数以上运行机制说明： 集群至少需要三台服务器，并且强烈建议使用奇数个服务器。因为zookeeper 通过判断大多数节点的存活来判断整个服务是否可用。比如3个节点，挂掉了2个表示整个集群挂掉，而用偶数4个，挂掉了2个也表示其并不是大部分存活，因此也会挂掉。
配置语法： server.<节点ID>=:<数据同步端口>:<选举端口>
节点ID：服务id手动指定1至125之间的数字，并写到对应服务节点的 {dataDir}/myid 文件中。 IP地址：节点的远程IP地址，可以相同。但生产环境就不能这么做了，因为在同一台机器就无法达到容错的目的。所以这种称作为伪集群。（IP地址也可以配置本地域名解析） 数据同步端口：主从同时数据复制端口，（做伪集群时端口号不能重复）。 选举端口：主从节点选举端口，（做伪集群时端口号不能重复）。
配置文件示例：
tickTime=2000 dataDir=/var/lib/zookeeper/ clientPort=2181 initLimit=5 syncLimit=2 #以下为集群配置，必须配置在所有节点的zoo.cfg文件中 server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888检查集群复制情况： 分别连接指定节点 zkCli.sh 后加参数-server 表示连接指定IP与端口。 ./bin/zkCli.sh -server 127.0.0.1:2181 ./bin/zkCli.sh -server 127.0.0.1:2182 ./bin/zkCli.sh -server 127.0.0.1:2183
任意节点中创建数据，查看其它节点已经同步成功
注意： -server参数后可以同时连接多个服务节点，并用逗号隔开，如： 127.0.0.1:2181,127.0.0.1:2182
zookeeper 集群中总共有三种角色，分别是 leader（主节点） follower(子节点) observer（次级子节点）
leader | 主节点，又名领导者。用于写入数据，通过选举产生，如果宕机将会选举新的主节点。follower | 子节点，又名追随者。用于实现数据的读取。同时他也是主节点的备选节点，并用拥有投票权。observer | 次级子节点，又名观察者。用于读取数据，与fllower区别在于没有投票权，不能选为主节点。并且在计算集群可用状态时不会将observer计算入内。observer配置： 只要在集群配置中加上observer后缀即可，示例如下： server.3=127.0.0.1:2889:3889:observer
通过 ./bin/zkServer.sh status 命令可以查看到节点状态 可以发现中间的2182 是leader状态.其选举机制如下图：
投票机制说明： 第一轮投票全部投给自己 第二轮投票给myid比自己大的相邻节点 如果得票超过半数，选举结束。
选举触发： 当集群中的服务器出现已下两种情况时会进行Leader的选举：
服务节点初始化启动半数以上的节点无法和Leader建立连接当节点初始起动时会在集群中寻找Leader节点，如果找到则与Leader建立连接，其自身状态变化follower或observer。如果没有找到Leader，当前节点状态将变化LOOKING，进入选举流程。 在集群运行其间如果有follower或observer节点宕机只要不超过半数并不会影响整个集群服务的正常运行。但如果leader宕机，将暂停对外服务，所有follower将进入LOOKING 状态，进入选举流程。
数据同步机制
zookeeper 的数据同步是为了保证各节点中数据的一至性，同步时涉及两个流程，一个是正常的客户端数据提交，另一个是集群某个节点宕机在恢复后的数据同步。
客户端写入请求：
写入请求的大至流程是，收leader接收客户端写请求，并同步给各个子节点。如下图：
但实际情况要复杂的多，比如client 它并不知道哪个节点是leader 有可能写的请求会发给follower ，由follower在转发给leader进行同步处理：
客户端写入流程说明：
client向zk中的server发送写请求，如果该server不是leader，则会将该写请求转发给leader server，leader将请求事务以proposal形式分发给follower；当follower收到收到leader的proposal时，根据接收的先后顺序处理proposal；当Leader收到follower针对某个proposal过半的ack后，则发起事务提交，重新发起一个commit的proposalFollower收到commit的proposal后，记录事务提交，并把数据更新到内存数据库；当写成功后，反馈给client。服务节点初始化同步： 在集群运行过程当中如果有一个follower节点宕机，由于宕机节点没过半，集群仍然能正常服务。当leader 收到新的客户端请求，此时无法同步给宕机的节点。造成数据不一至。为了解决这个问题，当节点启动时，第一件事情就是找当前的Leader，比对数据是否一至。不一至则开始同步,同步完成之后在进行对外提供服务。 如何比对Leader的数据版本呢，这里通过ZXID事物ID来确认。比Leader小就需要同步。 ZXID说明： ZXID是一个长度64位的数字，其中低32位是按照数字递增，任何数据的变更都会导致,低32位的数字简单加1。高32位是leader周期编号，每当选举出一个新的leader时，新的leader就从本地事物日志中取出ZXID,然后解析出高32位的周期编号，进行加1，再将低32位的全部设置为0。这样就保证了每次新选举的leader后，保证了ZXID的唯一性而且是保证递增的。
ZooKeeper响应少量命令。每个命令由四个字母组成。可通过telnet或nc向ZooKeeper发出命令。 这些命令默认是关闭的，需要配置4lw.commands.whitelist来打开，可打开部分或全部示例如下：
#打开指定命令 4lw.commands.whitelist=stat, ruok, conf, isro #打开全部 4lw.commands.whitelist=*安装Netcat工具，以使用nc命令
#安装Netcat 工具 yum install -y nc #查看服务器及客户端连接状态 echo stat | nc localhost 2181
命令列表
conf：3.3.0中的新增功能：打印有关服务配置的详细信息。缺点：3.3.0中的新增功能：列出了连接到该服务器的所有客户端的完整连接/会话详细信息。包括有关已接收/已发送的数据包数量，会话ID，操作等待时间，最后执行的操作等信息。crst：3.3.0中的新增功能：重置所有连接的连接/会话统计信息。dump：列出未完成的会话和临时节点。这仅适用于领导者。envi：打印有关服务环境的详细信息ruok：测试服务器是否以非错误状态运行。如果服务器正在运行，它将以imok响应。否则，它将完全不响应。响应“ imok”不一定表示服务器已加入仲裁，只是服务器进程处于活动状态并绑定到指定的客户端端口。使用“ stat”获取有关状态仲裁和客户端连接信息的详细信息。srst：重置服务器统计信息。srvr：3.3.0中的新功能：列出服务器的完整详细信息。stat：列出服务器和连接的客户端的简要详细信息。wchs：3.3.0中的新增功能：列出有关服务器监视的简要信息。wchc：3.3.0中的新增功能：按会话列出有关服务器监视的详细信息。这将输出具有相关监视（路径）的会话（连接）列表。请注意，根据手表的数量，此操作可能会很昂贵（即影响服务器性能），请小心使用。dirs：3.5.1中的新增功能：以字节为单位显示快照和日志文件的总大小wchp：3.3.0中的新增功能：按路径列出有关服务器监视的详细信息。这将输出具有关联会话的路径（znode）列表。请注意，根据手表的数量，此操作可能会很昂贵（即影响服务器性能），请小心使用。mntr：3.4.0中的新增功能：输出可用于监视集群运行状况的变量列表。