1 概述
zookeeper是分布式服务框架，是hadoop Ecosystem中组件。 zookeeper主要应用包括：集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式通知等。
2 zookeeper基本概念
2.1 数据模型
zookeeper中的数据模型跟linux系统下目录结构相似，根目录/，每一个节点为zNode，每一个zNode根据唯一的路径标识，如图中标识所示；在每一个zNode上可以存储少量数据（默认1M），正是由于这个特性，zookeeper可以作为dubbo的名字服务、HBase的组管理服务等。每一个zNode可以存储ACL（权限访问）信息，各个zNode节点的ACL（access control list ）权限相互隔离，互不影响。
2.2 zNode
zNode可以分为两类：
Regular zNode（常规型节点） : zookeeper的client创建之后，在进行显式删除。
Ephemeral zNode（临时型节点）：创建之后，session失效或者client删除，节点都会消失
2.3 session
client与zookeeper server 之间的一次会话，如果client与server之间通信足够频繁，client 不会每隔t/3（t为zoo.cfg中配置的时间，默认为3s）给server发送心跳检测；若通信不频繁，client发送心跳信息之后，client在2t/3时间之后没有收到server端回复，就认为server宕机，会移动到zookeeper cluster中另一个server,这个过程对客户端是透明的。
2.4 watcher
zookeeper对Node的增、删、改、查都可以出发监听
watch事件一次性触发器，当watch的数据发生改变时，会通知watcher
watch事件异步发送到watcher
3 zookeeper体系结构
server端fast fail特性，非常健壮。无单点。超过半数的server挂掉才会影响服务。
集群角色：
Leader：为客户端提供写服务和读服务
Follower：读服务，所有写服务都要转交给Leader，参与选举
Observer：读服务，不参与选举，一般是为了增强zk集群的读请求并发能力。
zookeeper支持WAL（write-ahead-log）和snapshot,对于每一步操作，先会记录到日记中，之后更新到内存，最后通知client结果；另外还会定期将内存中的目录树snapshot到硬盘。
4 应用场景
4.1 分布式配置管理
发布与订阅就是分布式配置管理，就是将数据发布到zk节点上，供订阅者动态获取数据，实现配置信息的集中管理和动态更新
例如全局的配置
4.2 分布式命名服务
名字作为分布式系统中的资源，可以是机器的名字、提供服务的地址、完成某一功能的对象。
dubbo就是该应用的一个实现，zookeeper中记录着提供者的url地址，具体实现为：dubbo的服务提供者（provider）再启动的时候会将自己的url写到zookeeper的 /dubbo/${serviceName}/providers目录下写下自己的提供url，dubbo的服务消费者（consumer）启动的时候会watcher 服务提供者/dubbo/${serviceName}/providers，并在zk的/dubbo/${serviceName}/consumers目录写下自己的消费url， 所有向zookeeper写下的节点都是临时型的，这样可以保证服务提供者和消费者可以自动感知。
4.3 分布式通知/协调
zk的watcher注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理
不同系统都对zk上同一个znode进行注册，监听znode的变化，其中一个update,那么其余系统能够收到通知
4.4 分布式锁
zk可以保证数据的强一致性，也就是说zk集群中任意节点上相同znode的数据一定是相同的
效率过低，实际项目中基本不用
4.5 集群管理与选举
监控系统向zookeeper的某一个节点watch变化，当新加进来一个节点或者某一个节点宕机之后，该节点变化会触发watcher事件，这样监控系统就可以动态感知集群的状态。
HBase集群利用 zookeeper集群的选举算法来产生HMaster。
4.6 分布式队列
基本上不用
