zookeeper简单可以概括为：一致、有头、数据数。
一致：就是每个节点的数据都是一致的。
有头：节点一般为单数，因为要选举一个leader，其他都是follower，当leader的服务器挂了之后zookeeper会自己选举算法重新选定leader。默认的算法是FastLeaderElection，默认是采用投票数大于半数则胜出的逻辑。
数据数：每一个节点绑定一份数据，可以是树状。所以称为数据树；
zookeeper集群有个重要的特性，即只要集群中超过一半的机器可用，则集群整体对外是可用的。一半来说，集群中配置的机器数量一半为基数个数，当只有两个zookeeper机器时，挂掉一个zookeeper则不满足超过一半机器可用，如果此时有三台机器挂一台的情况下集群还是可用的。
安装配置：
一般我们会把中间都安装在/usr/local下，这个相当于window环境的Program Files目录。解压后，在zookeeper文件下有一个conf文件夹。里面默认有三个文件：
configuration.xsl
log4j.properties
zoo_sample.cfg
把zoo_sample.cfg 文件复制一份命名为 zoo.cfg。里面的配置都暂时不用改，在文件最下面加上所有机器的IP和端口：
server.1=192.168.0.110:2888:3888
server.2=192.168.0.111:2888:3888
server.3=192.168.0.112:2888:3888
在zoo.cfg的配置中有一个默认的路径：tmp/zookeeper 。zookeeper的数据都是在内存中的，但是在本地文件也会存一份，放置在该路径下，这是临时的路径，zookeeper会定时清理，所以上生产此文件夹必须修改成其他文件夹。
在每台机器的该路径下创建一个myid 的文件。在里面写自己的别名。如上面配置的三台机器。第一台机器（192.168.0.110）的myid里面就写1，第二台（192.168.0.111）的myid写2，第三台（192.168.0.112）的myid写3
以上以完成配置，接下来就可以启动了:
cd bin
./zkServer.sh start 启动
./zkServer.sh stop 停止
./zkServer.sh status 显示状态
zookeeper应用场景：
配置一致：在zookeeper上做一个监听器，监听所有的集群机器，修改配置后所有被监听的机器都收到了。
HA：(High Available), 高可用性集群,相当于主备动态切换。
pub/sub：
naming service：
load balance：
分布式锁：
FastLeaderElection选举算法
FastLeaderElection是标准的fast paxos的实现，它首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决 epoch 和 zxid 的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息。
FastLeaderElection算法通过异步的通信方式来收集其它节点的选票，同时在分析选票时又根据投票者的当前状态来作不同的处理，以加快Leader的选举进程。
每个Server都一个接收线程池和一个发送线程池, 在没有发起选举时，这两个线程池处于阻塞状态，直到有消息到来时才解除阻塞并处理消息，同时每个Serve r都有一个选举线程(可以发起选举的线程担任)。
1). 主动发起选举端(选举线程)的处理
首先自己的 logicalclock加1，然后生成notification消息，并将消息放入发送队列中， 系统中配置有几个Server就生成几条消息，保证每个Server都能收到此消息，如果当前Server 的状态是LOOKING就一直循环检查接收队列是否有消息，如果有消息，根据消息中对方的状态进行相应的处理。
2).主动发送消息端(发送线程池)的处理
将要发送的消息由Notification消息转换成ToSend消息，然后发送对方，并等待对方的回复。
3). 被动接收消息端(接收线程池)的处理
将收到的消息转换成Notification消息放入接收队列中，如果对方Server的epoch小于logicalclock则向其发送一个消息(让其更新epoch)；如果对方Server处于Looking状态，自己则处于Following或Leading状态，则也发送一个消息(当前Leader已产生，让其尽快收敛)。