在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。
以下我们就来使用zookeeper。
zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；同理你多列举几个：2->0;3->1;4->1;5->2;6->2会发现一个规律，2n和2n-1的容忍度是一样的，都是n-1，所以为了更加高效，何必增加那一个不必要的zookeeper呢。官方推荐是大于等于3的奇数台。
单机模式就不介绍了，没有使用价值，下面介绍下完全分布式的安装和配置
节点准备：
node1 node2 node3,三台主机安装zookeeper
官网下载zookeeper的安装包zookeeper-3.4.12.tar.gz，zookeeper也是jvm进程，所以需要预先安装好jdk
tar zxvf zookeeper-3.4.12.tar.gz -C /usr/local/bigdata
mv zookeeper-3.4.12 zk3.4
配置环境变量,追加以下内容
export ZOOKEEPER_HOME=/usr/local/bigdata/zk3.4
export PATH=$PATH:$ZOOKEEPER_HOME/bin
使配置生效
source /etc/profile
修改zk的配置
配置文件放在conf目录下，复制zoo_sample.cfg为zoo.cfg
这是zookeeper的主要配置文件，因为Zookeeper是一个集群服务，集群的每个节点都需要这个配置文件。为了避免出差错，zoo.cfg这个配置文件里没有跟特定节点相关的配置，所以每个节点上的这个zoo.cfg都是一模一样的配置。这样就非常便于管理了，比如我们可以把这个文件提交到版本控制里管理起来。其实这给我们设计集群系统的时候也是个提示：集群系统一般有很多配置，应该尽量将通用的配置和特定每个服务的配置(比如服务标识)分离，这样通用的配置在不同服务之间copy就ok了。ok，下面来介绍一些配置点：
clientPort=2181
client port，顾名思义，就是客户端连接zookeeper服务的端口。这是一个TCP port。
dataDir=/usr/local/bigdata/zk3.4/data
dataLogDir=/usr/local/bigdata/zk3.4/dataLog
dataLogDir如果没提供的话使用的则是dataDir。zookeeper的持久化都存储在这两个目录里。dataLogDir里是放到的顺序日志(WAL)。而dataDir里放的是内存数据结构的snapshot，便于快速恢复。为了达到性能最大化，一般建议把dataDir和dataLogDir分到不同的磁盘上，这样就可以充分利用磁盘顺序写的特性。
下面是集群中服务的列表
server.1=node1:2888:3888
server.2=node1:2888:3888
server.3=node1:2888:3888
在上面的例子中，我把三个zookeeper服务放到同一台机器上。上面的配置中有两个TCP port。后面一个是用于Zookeeper选举用的，而前一个是Leader和Follower或Observer交换数据使用的。我们还注意到server.后面的数字。这个就是myid(关于myid是什么下一节会介绍)。
上面这几个是一些基本配置。
还有像 tickTime，这是个时间单位定量。比如tickTime=1000，这就表示在zookeeper里1 tick表示1000 ms，所有其他用到时间的地方都会用多少tick来表示。
比如 syncLimit = 2 就表示fowller与leader的心跳时间是2 tick。
maxClientCnxns -- 对于一个客户端的连接数限制，默认是60，这在大部分时候是足够了。但是在我们实际使用中发现，在测试环境经常超过这个数，经过调查发现有的团队将几十个应用全部部署到一台机器上，以方便测试，于是这个数字就超过了。
minSessionTimeout, maxSessionTimeout -- 一般，客户端连接zookeeper的时候，都会设置一个session timeout，如果超过这个时间client没有与zookeeper server有联系，则这个session会被设置为过期(如果这个session上有临时节点，则会被全部删除，这就是实现集群感知的基础，后面的文章会介绍这一点)。但是这个时间不是客户端可以无限制设置的，服务器可以设置这两个参数来限制客户端设置的范围。
autopurge.snapRetainCount，autopurge.purgeInterval -- 客户端在与zookeeper交互过程中会产生非常多的日志，而且zookeeper也会将内存中的数据作为snapshot保存下来，这些数据是不会被自动删除的，这样磁盘中这样的数据就会越来越多。不过可以通过这两个参数来设置，让zookeeper自动删除数据。autopurge.purgeInterval就是设置多少小时清理一次。而autopurge.snapRetainCount是设置保留多少个snapshot，之前的则删除。
不过如果你的集群是一个非常繁忙的集群，然后又碰上这个删除操作，可能会影响zookeeper集群的性能，所以一般会让这个过程在访问低谷的时候进行，但是遗憾的是zookeeper并没有设置在哪个时间点运行的设置，所以有的时候我们会禁用这个自动删除的功能，而在服务器上配置一个cron，然后在凌晨来干这件事。
创建data 和dataLog目录
cd /usr/local/bigdata/zk3.4
mkdir data
mkdir dataLog
在data目录创建myid文件，内容为1
cd /usr/local/bigdata/data
echo 1 > myid
修改zookeeper的日志输出位置
如果不做修改，默认zookeeper的日志输出信息都打印到了zookeeper.out文件中，这样输出路径和大小没法控制，因为日志文件没有轮转。所以需要修改日志输出方式。具体操作如下：
1、修改$ZOOKEEPER_HOME/bin目录下的zkEnv.sh文件，ZOO_LOG_DIR指定想要输出到哪个目录，ZOO_LOG4J_PROP，指定INFO,ROLLINGFILE的日志APPENDER.
2、修改$ZOOKEEPER_HOME/conf/log4j.properties文件的：zookeeper.root.logger的值与前一个文件的ZOO_LOG4J_PROP 保持一致，该日志配置是以日志文件大小轮转的，如果想要按照天轮转，可以修改为DaliyRollingFileAppender.
配置完成之后，发送到其他节点
scp -r /usr/local/bigdata/zk3.4 node2:/usr/local/bigdata
scp -r /usr/local/bigdata/zk3.4 node3:/usr/local/bigdata
在node2节点修改myid
echo 2 > /usr/local/bigdata/zk3.4/data/myid
在node3节点修改myid
echo 3 > /usr/local/bigdata/zk3.4/data/myid
启动zookeeper，在三个节点分别启动
zkServer.sh start
查看个个节点的状态
zkServer.sh status
