1、zookeeper配置文件简介：
* zookeeper的配置文件在conf目录下，有zoo_sample.cfg， 需要将zoo_sample.cfg 改为zoo.cfg，因为zookeeper在启动时会找这个文件作为默认的配置文件。
* 参数：
tickTime：zookeeper服务器或者客户端与服务器之间维持心跳时间间隔参数。每个ticktime时间就会发送一个心跳。
dataDir ： zookeeper数据存储目录。默认情况会把日志文件保存到这个目录。
clientPort ：zookeeper服务器商品，zookeeper会监听这个端口，接受客户端的请求。
2、集群模式：
zookeeper不仅可以单机提供服务，同时也支持多机组成集群来提供服务。实际上zookeeper还支持另外一种伪集群的方式，就是可以在一台机器人上配置多个zookeeper实例。
配置（zoo.cfg)：
initLimit=5
syncLimit=2
server.1=192.168.211.1:2888:3888
server.2=192.168.211.2:2888:3888
* initLimit ：这个配置项是用来配置zookeeper接受客户端初始化连接时最长能忍受多少个心跳时间间隔数。
* syncLimit : leader与Follower之间发送消息、请求应用于时间长度，最长不能超过多少个ticktime的时间长度。
* server.A = B : C : D 其中A是一个数字，表示这是第几号服务器；B是这服务器的ip地址； C表示的是这个服务器与集群中的leader服务器交换信息的端口； D表示的是万一集群中的leader服务器挂了，需要一个端口来重新进行选举新的leader。
除了修改zoo.cfg配置文件，集群模式下还要配置一个文件myid， 这个文件在dataDir目录下，这个文件里面就是一个数据就是A的值，zookeeper启动时会读取这个文件，拿到里面的数据与zoo.cfg里面的配置信息从而判断到底是哪个server。
3、应用场景
Zookeeper人设计模式的角度来看是一个观察者模式的分布式服务管理框架，负责存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数据发生变化，Zookeeper就会负责通知已经注册过了的那些observer做出相应的反应，从而实现集群中类似的Master、Slave管理模式。
* 统一命名服务（Name Service)
分布式应用中，通常需要有一套完整的命名规则， 能够产生唯一的名称 又便于人识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，即对人友好又不会重复。 Name Service是Zookeeper内置的功能， 只须调用其api就可以实现。如调用 create接口就可以容易的创建 一个目录节点。（与JNDI 差不多吧）
* 配置管理
配置的管理费用在分布式应用环境中很常见，例如同一个应用系统需要多个pc server运行， 但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的的配置项，那么就必须同时修改每台运行这个应用系统的PCserver 这样非常容易出错。 像这样的配置信息完全可以交给zookeeper管理，将配置信息保存在zookeeper的某个目录节点上，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台机器就会收zookeeper的通知。