ZooKeeper高级应用
本系列将指导使用ZooKeeper来实现高级功能，所有功能都在客户端完成，不需要ZooKeeper的特殊支持。希望可以得到社区的支持将这些加入到一个标准的客户端类库中（Curator已经实现了除两阶段提交的功能）。
ZooKeeper最有意思的一点是，即便ZooKeeper使用异步通知，你可以使用这点来构建同步的一致性元素，如队列，锁等。你将会看到，ZooKeeper强制使用全局的更新顺序，并有机制用于广播这个顺序。
值得记录的是，本recipes尝试使用最佳实践。特别是避免投票、计时或其他会导致“羊群效应”、通信激增、扩展受限的因素。
也有许多有用的功能这里并没有描述-如可撤销的读写优先锁等。一些这里提到的（尤其是锁）只代表某些观点，你也可以找到其他方法（如事件处理和队列），或更实用的方法达到同样的功能。总而言之，这里的例子只是用于展示想法。
关于错误处理的重要注意事项
当实现这些recipes时你必须处理可恢复的错误（详见FAQ）。尤其是诸多recipes使用了sequential和ephermeral节点。当创建一个sequential ephemeral节点是，有一种情况，当create在服务端成功但是服务端在返回结果给客户端前宕机。当客户端重连会话，这个会话仍然有效，因此节点没有被移除。意味着客户端很难知道节点是否被创建。本系列的recipes会包含解决方法。
开箱即用：名字服务、配置、组成员识别
名字服务和配置是ZooKeeper两个首要功能。这两个是由ZooKeeper API直接提供的。
另一个ZooKeeper直接提供的功能是组成员识别（group membership）。组可以表现为一个节点。组的成员在组节点下创建ephemeral节点。异常失效的成员会自动从ZooKeeper中移除
目录
Barrier - http://www.cnblogs.com/resentment/p/6194361.html
Queues - http://www.cnblogs.com/resentment/p/6210677.html
Locks - http://www.cnblogs.com/resentment/p/6226146.html
Two-phased Commit - http://www.cnblogs.com/resentment/p/6246760.html
Leader Election - http://www.cnblogs.com/resentment/p/6258813.html