zookeeper要保证各个server之间同步，实现同步的协议是zab协议。此协议有两种模式：恢复模式（选主）和广播模式（同步）。
服务启动或者leader崩溃时，进入恢复模式。选举成功且大多数server完成了和leader的状态同步后（2n+1台中的n+1台），恢复模式就结束了。
状态同步保证了leader和Server具有相同的系统状态。为了保证事务的顺序一致性，zookeeper采用了递增的事务id号 （zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用 来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递 增计数。
同步流程
选完leader以后，zk就进入状态同步过程。
1. leader等待server连接；
2 .Follower连接leader，将最大的zxid发送给leader；
3 .Leader根据follower的zxid确定同步点；
4 .完成同步后通知follower 已经成为uptodate状态；
5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。
Leader主要有三个功能：
1 .恢复数据；
2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
PING 消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议 的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。
Follower主要有四个功能：
1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
2 .接收Leader消息并进行处理；
3 .接收Client的请求，如果为写请求，发送给Leader进行投票；
4 .返回Client结果。
Follower的消息循环处理如下几种来自Leader的消息：
1 .PING消息： 心跳消息；
2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；
3 .COMMIT消息：服务器端最新一次提案的信息；
4 .UPTODATE消息：表明同步完成；
5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
以上内容引用自这篇博客，里面有流程图：
http://www.cnblogs.com/kunpengit/p/4045334.html
一、配置项解释：
zoo.cfg=>
initLimit=10
syncLimit=5tickTime=2000dataDir=E:/zookeeper/zookeeper-3.4.5/dataclientPort=2181server.1=slave1:2887:3887
server.2=slave2:2887:3887
server.3=slave3:2887:3887
解释：
initLimit：集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量）。F在启动时，会从Leader同步所有的最新数据，然后确定自己能对外服务的起始状态。L允许在这个时间范围内完成这个工作。如果ZK集群的数据量很大，F在启动的时候，同步的时间就会很长，需要相应调大这个参数。
syncLimit：集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。在集群运行过程中，L负责与所有的机器进行通信，例如通过心跳检测机器是否存货。如果发出的心跳包在这个时间范围内没有收到响应，那么就会弃用这个机器。这个值不宜设置过大。
tickTime:心跳时间，客户端在服务端保留session，最小的session过期时间，是tickTime的2倍。
dataDir:用来存储在内存中的数据库快照。
logDir:
leaderServes：默认情况下，leader机器会接收客户端的读写请求。如果设置为no，该机器将会专注于急群众机器的协调工作。以此来提高写操作的性能。
clientPort:监听客户端连接的端口号。
globalOutstandingLimit：最大请求堆积数。默认是1000。ZK运行的时候， 尽管server已经没有空闲来处理更多的客户端请求了，但是还是允许客户端将请求提交到服务器上来，以提高吞吐性能。当然，为了防止Server内存溢出，这个请求堆积数还是需要限制下的。
server.1中的1对应上面配置的dataDir目录下的myid文件中的值
两个端口：第一个是F和L之间通信（数据同步和其他通信）的端口，第二个是用于leader选举中投票通信。
扩展：
preAllocSize：预先开辟磁盘空间，用于后续写入事务日志。默认是64M，每个事务日志大小就是64M。如果ZK的快照频率较大的话，建议适当减小这个参数。
snapCount：每进行snapCount次事务日志输出后，触发一次快照(snapshot), 此时，ZK会生成一个snapshot.*文件，同时创建一个新的事务日志文件log.*。默认是100000.（真正的代码实现中，会进行一定的随机数处理，以避免所有服务器在同一时间进行快照而影响性能）
traceFile：用于记录所有请求的log，一般调试过程中可以使用，但是生产环境不建议使用，会严重影响性能。
autopurge.purgeInterval：3.4.0及之后版本，ZK提供了自动清理事务日志和快照文件的功能，这个参数指定了清理频率，单位是小时，需要配置一个1或更大的整数，默认是0，表示不开启自动清理功能。
autopurge.snapRetainCount：这个参数和上面的参数搭配使用，这个参数指定了需要保留的文件数目。默认是保留3个。
二、命令：
启动和重启
bin/zkServer.sh start / restart
查看状态
bin/zkServer.sh status
集群中应该只有一台leader，其余是follower 和looking（当前server不知道leader是谁，正在搜寻）
查看节点的详细配置信息：
echo conf | nc slave1 2181
查看节点的当前性能和连接客户端列表：
echo stat | nc slave1 2181
上述命令的简化版本：
echo cons |nc slave1 2181 仅仅列出当前连接到服务器的客户端的信息
列出当前机器环境的详细信息：
echo reqs |nc slave1 2181
列出watch详细信息：
echo wchs |nc slave1 2181
通过session列出服务器watch信息
echo wchc |nc slave1 2181
通过路径列出服务器watch信息
echo wchp |nc slave1 2181
列出未经处理的会话和临时节点：
echo dump |nc slave1 2181
列出所有未处理请求：
echo cons |nc slave1 2181
另一个关掉server的命令：
echo kill | nc salve1 2181
打开客户端
bin/zkCli.sh -server slave1:2181
列出节点：ls /
列出节点以及版本信息（增删节点会更新）、节点数量等内容：ls2 /
创建节点： create /testzk wordwordword 后面的是存入的内容字符串
查看：get /testzk 包括内容，以及版本等
设置内容字符串：set /testzk sssss 执行后，替换了
删除znode delete /testzk
退出客户端： quit
经验之谈：
1、今天遇到一个问题，过程是这样的：
我使用客户端连接到了三台集群机器上，后来从一台机器客户端界面ssh到了另一台上，这样，就相当于我打开了三个客户端界面，其实其中两个是连到了同一台机器，然，我却不知。然后逐台启动zookeeper，启动后习惯性的查看状态：bin/zkServer.sh status 发现一个奇怪的现象，每一台都是follower！我一开始怀疑是集群出错了。但是用jps查看，服务都是正常启动的。中间各种排查、搜索不表，最后发现了事情的原因。
这说明，要求zookeeper集群机器数必须是奇数的。因为选举算法，不能保证偶数台机器，每次都能选出leader（之所以这么说，是因为我有时候在启动集群时，发现当启动了两台的时候，leader已经产生了）。于是忍不住好奇，去研究相关的内容：
zookeeper集群自身维护了一套数据结构。是一个树形结构。其上的每一个节点，称之为znode。每一个znode默认能存储1MB数据（对于存储状态性质的数据足够）。可以通过zkCli连上集群，操作这些znode。
znode的结构是什么样的呢？
zxid：时间戳。每次修改znode都会生成新的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。
version：对节点每次修改，版本号+1
data：存储的数据。对之修改，会引起以上两者变化（修改数据，是对当前znode影响，对上级的znode则不会影响）
tick：租约协议的具体实现。（比较晦涩，如果当前节点是临时节点，那么在tick时间周期内没收到新的客户端租约，则视为失效）
选举规则：
默认选举规则称为：FastLeaderELection
详情请参考这篇博客：
http://blog.csdn.net/xhh198781/article/details/6619203