定义
ZooKeeper是Hadoop的正式子项目，它是一个针对大型分布式系统的可靠协调系统，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
原理
ZooKeeper是以Fast Paxos算法为基础的，paxos算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader，只有leader才能提交propose，具体算法可见Fast Paxos。
系统结构
在zookeeper中实现了一个类似file system系统的数据结构，比如/zookeeper/status。 每个节点都对应于一个znode节点。Zookeeper的功能都是通过对znode的操作实现的
znode 的 模式:
PERSISTENT (持续的，相比于EPHEMERAL，不会随着client session的close/expire而消失)
PERSISTENT_SEQUENTIAL
EPHEMERAL (短暂的，生命周期依赖于client session，对应session close/expire后其znode也会消失)
EPHEMERAL_SEQUENTIAL (SEQUENTIAL意为顺序的)
zxid (ZooKeeper Transaction Id，每次请求对应一个唯一的zxid，如果zxid a < zxid b ，则可以保证a一定发生在b之前)。
对应zxid 有两个
czxid
The zxid of the change that caused this znode to be created.
mzxid
The zxid of the change that last modified this znode.
Alone模式的启动方法：
conf/zoo.cfg:
tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
运行 bin/zkServer.sh start
shell客户端连接：
bin/zkCli.sh -server 127.0.0.1:2181
可以通过help打印出帮助信息
常见操控znode命令有：
get path [watch]
create [-s] [-e] path data acl
ls path [watch]
set path data [version]
delete path [version]
[zk: 127.0.0.1:2181(CONNECTED) 2] create -s /zk_test/st1 aaaa
Created /zk_test/st10000000000
[zk: 127.0.0.1:2181(CONNECTED) 3] create -s /zk_test/st1 aaaa
Created /zk_test/st10000000001
对某个znode节点 建立watch
get /zk_test/et10000000009 watch
Watches
Zookeeper 所有的读操作—— getData() , getChildren() , 和 exists() 都 可以设置监视(watch)，监视事件可以理解为一次性的触发器， 官方定义如下： a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes。对此需要作出如下理解：
（一次性触发）One-time trigger
当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了 getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。
（发送至客户端）Sent to the client
Zookeeper 客户端和服务端是通过 socket 进行通信的，由于网络存在故障，所以监视事件很有可能不会成功地到达客户端，监视事件是异步发送至监视者的，Zookeeper 本身提供了保序性(ordering guarantee)：即客户端只有首先看到了监视事件后，才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set a watch until it first sees the watch event). 网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但 是不同的客户端所看到的一切具有一致的顺序。
（被设置watch的数据）The data for which the watch was set
这意味着 znode 节点本身具有不同的改变方式。你也可以想象 Zookeeper 维护了两条监视链表：数据监视和子节点监视(data watches and child watches) getData() and exists() 设置数据监视，getChildren() 设置子节点监视。 或者，你也可以想象 Zookeeper 设置的不同监视返回不同的数据，getData() 和 exists() 返回 znode 节点的相关信息，而 getChildren() 返回子节点列表。因此， setData() 会触发设置在某一节点上所设置的数据监视(假定数据设置成功)，而一次成功的 create() 操作则会出发当前节点上所设置的数据监视以及父节点的子节点监视。一次成功的 delete() 操作将会触发当前节点的数据监视和子节点监视事件，同时也会触发该节点父节点的child watch。
Zookeeper 中的监视是轻量级的，因此容易设置、维护和分发。当客户端与 Zookeeper 服务器端失去联系时，客户端并不会收到监视事件的通知，只有当客户端重新连接后，若在必要的情况下，以前注册的监视会重新被注册并触发，对于开发人员来说 这通常是透明的。只有一种情况会导致监视事件的丢失，即：通过 exists() 设置了某个 znode 节点的监视，但是如果某个客户端在此 znode 节点被创建和删除的时间间隔内与 zookeeper 服务器失去了联系，该客户端即使稍后重新连接 zookeeper服务器后也得不到事件通知。
对于watch，zookeeper提供以下保证：
1.watch对于其他事件、watch、异步响应是有序的。zookeeper client library保证有序分发
2.客户端监视一个节点，总是先获取watch事件，再发现节点的数据变化。
3.watch事件的顺序对应于zookeeper服务所见的数据更新的顺序。
关于watch要记住的是：
1.watch是一次性触发的，如果获取一个watch事件并希望得到新变化的通知，需要重新设置watch
2.watch是一次性触发的并且在获取watch事件和设置新watch事件之间有延迟，所以不能可靠的观察到节点的每一次变化。要认识到这一点。
3.watch object只触发一次，比如，一个watch object被注册到同一个节点的getData()和exists()，节点被删除，仅对应于exists()的watch ojbect被调用
4.若与服务端断开连接，直到重连后才能获取watch事件。
Watch事件类型：
ZOO_CREATED_EVENT：节点创建事件，需要watch一个不存在的节点，当节点被创建时触发，此watch通过zoo_exists()设置
ZOO_DELETED_EVENT：节点删除事件，此watch通过zoo_exists()或zoo_get()设置
ZOO_CHANGED_EVENT：节点数据改变事件，此watch通过zoo_exists()或zoo_get()设置
ZOO_CHILD_EVENT：子节点列表改变事件，此watch通过zoo_get_children()或zoo_get_children2()设置
ZOO_SESSION_EVENT：会话失效事件，客户端与服务端断开或重连时触发
ZOO_NOTWATCHING_EVENT：watch移除事件，服务端出于某些原因不再为客户端watch节点时触发
ACL
传统的文件系统中，ACL分为两个维度，一个是属组，一个是权限，子目录/文件默认继承父目录的ACL。而在Zookeeper中，node的ACL是没有继承关系的，是独立控制的。Zookeeper的ACL，可以从三个维度来理解：一是scheme; 二是user; 三是permission，通常表示为scheme:id:permissions, 下面从这三个方面分别来介绍：
scheme: scheme对应于采用哪种方案来进行权限管理，zookeeper实现了一个pluggable的ACL方案，可以通过扩展scheme，来扩展ACL的机制。zookeeper-3.4.4缺省支持下面几种scheme:
world: 它下面只有一个id, 叫anyone, world:anyone代表任何人，zookeeper中对所有人有权限的结点就是属于world:anyone的
auth: 它不需要id, 只要是通过authentication的user都有权限（zookeeper支持通过kerberos来进行authencation, 也支持username/password形式的authentication)
digest: 它对应的id为username:BASE64(SHA1(password))，它需要先通过username:password形式的authentication
ip: 它对应的id为客户机的IP地址，设置的时候可以设置一个ip段，比如ip:192.168.1.0/16, 表示匹配前16个bit的IP段
super: 在这种scheme情况下，对应的id拥有超级权限，可以做任何事情(cdrwa)
另外，zookeeper-3.4.4的代码中还提供了对sasl的支持，不过缺省是没有开启的，需要配置才能启用，具体怎么配置在下文中介绍。
sasl: sasl的对应的id，是一个通过sasl authentication用户的id，zookeeper-3.4.4中的sasl authentication是通过kerberos来实现的，也就是说用户只有通过了kerberos认证，才能访问它有权限的node.
id: id与scheme是紧密相关的，具体的情况在上面介绍scheme的过程都已介绍，这里不再赘述。
permission: zookeeper目前支持下面一些权限：
CREATE(c): 创建权限，可以在在当前node下创建child node
DELETE(d): 删除权限，可以删除当前的node
READ(r): 读权限，可以获取当前node的数据，可以list当前node所有的child nodes
WRITE(w): 写权限，可以向当前node写数据
ADMIN(a): 管理权限，可以设置当前node的permission
zookeeper使用事例：
1. 配置项管理
分布式系统中，经常会有多个节点共享一份配置信息，并且配置信息可能动态的发生变化，此时需要节点能在配置变化时动态加载，通过zookeeper可很方便的完成。将配置信息存储在zookeeper的某个节点C上（可能包含很多配置子项），进程启动时先连接zookeeper获取C上的配置信息并注册watch，当配置信息发生变化时会得到通知，此时进程重新加载配置。
2. 主从配合
分布式系统中，多个进程可能需要协作，某个进程在启动时需要知道其他进程的一些信息，而这些信息可能会动态变化。如某系统中，包含一个master进程和多个worker进程，worker在启动时必须连接知道master的运行的一些信息（如ip：port，状态等），而master的运行由调度器完成，可能动态变化，通过zookeeper可完成这类需求。在zookeeper上创建一个节点R，当master启动时，将其运行信息写入R节点，当worker启动时，读取R的信息并设置watch，如果R中有信息，则读取并启动；如果没有，当master向R写入信息后，worker会被通知，此时读取信息并且启动worker；另外，可以将R设为Ephemeral并注册deletewatch时间，当R不存在时，所有的进程退出。
3. 组管理
组管理在分布式系统中很常见，如某个分布式存储系统，包含多个存储节点，这多个存储节点构成一个group，合理管理group是系统运行的关键，如监控并处理group中节点加入（扩展性）和退出（容错）事件，通过zookeeper也可方便实现组管理功能。用一个节点G代表group，系统在group上设置watch，当有节点加入时，在G下创建一个临时子节点，当节点退出时，临时子节点也会被删除，系统只需要根据相应的事件类型进行处理即可。
4. 分布式锁
解决方案依然很简单，需要加锁的进程先尝试在zookeeper上创建一个临时节点L，如果创建成功则加锁成功，如果不成功（已存在）则在该节点上设置watch。进程通过删除L来解锁（当进程意外终止，L也会被删除，不会造成死锁），当L被删除时，其它等待锁的进程会得到通知，此时这些进程再次创建L来获得锁。
上面的方案，当竞争锁的进程比较多时，解锁时会引起Herd Effect，可对加锁规则进行限制，如按进程尝试加锁的顺序来分配锁。在zookeeper上，每个加锁的进程创建一个带SEQUENTIAL标志的临时节点，每次让序号最小的节点获得锁，这样每个节点只需要watch它前面节点的状态即可，当其前面节点被删除时，其将被通知，并获得锁。
5. 分布式Barrier
Barrier是一种控制和协调多个任务触发次序的机制，简单说来就是搞个闸门把欲执行的任务给拦住，等所有任务都处于可以执行的状态时，才放开闸门。
是用一个Node作为Barrer的实体，需要被Barrer的任务通过调用exists()检测这个Node的存在，当需要打开Barrier的时候，删掉这个Node，ZooKeeper的watch机制会通知到各个任务可以开始执行。
6. 分布式 Queue
与 Barrier类似 分布式环境中 实现Queue也需要高一致性做保障， ZooKeeper提供了一个种简单的方式， ZooKeeper通过一个Node来维护Queue的实体，用其children来存储Queue的内容，并且 ZooKeeper的create方法中提供了顺序递增的模式，会自动地在name后面加上一个递增的数字来插入新元素。可以用其 children来构建一个queue的数据结构，offer的时候使用create，take的时候按照children的顺序删除第一个即可。 ZooKeeper保障了各个server上数据是一致的，因此也就实现了一个 分布式 Queue。
Curator
Curator是Netflix开源的一套ZooKeeper客户端框架.
Curator主要解决了三类问题:
封装ZooKeeper client与ZooKeeper server之间的连接处理;
提供了一套Fluent风格的操作API;
提供ZooKeeper各种应用场景(recipe, 比如共享锁服务, 集群领导选举机制)的抽象封装.
CuratorFramework zkClient = CuratorFrameworkFactory .builder() .connectString(zkQuorum) .retryPolicy( new RetryNTimes(zkRetryTimes, zkRetrySleepInterval))
.build(); zkClient.start(); zkClient.create().creatingParentsIfNeeded() .forPath(shardZkPath, null); byte[] shardZkData = zkClient.getData().forPath( shardZkPath);
参考资料：
总体：
http://agapple.iteye.com/blog/1111377
http://blog.csdn.net/cutesource/article/details/5822459
http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html
http://okwangxing.iteye.com/blog/598548
Acl:
http://www.wuzesheng.com/?p=2438
curator