目录
1. 简介
2. 集群架构
3. 数据模型
4. 使用场景（常用功能）
4.1 Master选举
4.2 成员管理（负载均衡实现）
4.3 配置管理（发布订阅）
4.4 任务分配
4.5 分布式锁
1. 简介
Zookeeper是一个开源的分布式协调服务，其设计目标是将那些复杂的且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一些简单的接口提供给用户使用。其是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
2. 集群架构
官网配图
ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。
写请求：每个写请求都会通过Follower转发给Leader，通过ZAB协议达到一致性和顺序性，然后同步至全部follower，最终达成数据一致。
读请求：在zookeeper中，所有的server(leader和follower)都可以直接响应读请求。
基于以上读写方式，决定了zookeeper在读远多于写的情况下，性能最好。如果读没有明显多于写的情况下，不太适合对并发和性能要求太高的情况。
3. 数据模型
在zookeeper中，数据是按树形存储，每个节点被称为Znode，类似于文件系统。但是与文件系统不同的是，上图中的每个Znode也可以存储数据。就相当于，文件系统中，目录中也可以存内容。例如：创建/app2时可以同时设定内容其内容为"I am app2 content"。之后可以从/app2节点读取相应数据。
4. 使用场景（常用功能）
4.1 Master选举
当前node1为leader，leader节点的内容是"node1"，当node1挂掉后，/leader节点会被删除。node2和node3监控/leader节点，当/leader节点被删除时，尝试创建/leader节点。创建成功的成为新的leader，并同时将leader节点的内容设置为新的leader节点。
4.2 成员管理（负载均衡实现）
成员管理的目的就是，集群内某个节点宕机或者新加入节点，可以及时感知。举例如下：
上图中，起初node2和node3分别注册/cluster-1目录下的/node2和/node3,client1、client2连接node2，client3连接node3。当新增节点node1时，被client1感知到。client1实现了负载均衡算法，所以从node2改为连接node1。
举例中，客户端程序client监听/cluster-1的变化，但不仅限于此，所有对/cluster-1的变化感兴趣的组件都可以注册监听，例如上图中node节点。
4.3 配置管理（发布订阅）
client1、client2和client3 同时监听/conf节点。当/conf内容发生变化时，所有节点都会收到通知。
4.4 任务分配
任务分配程序监听/tasks,当有新任务task1，task2来到，将task1分配给/processor1,即在/processor1下创建task1，然后删除task1。processor1处理完成后删除task1。task2与之相同。
4.5 分布式锁
在zookeeper中，支持创建节点时后缀自动编号的特性。例如上图中，client1 执行创建"/lock/node-" 的命令时，在/lock下自动创建类似node-01的节点，当client2执行相同命令时，则自动生成node-02。
此时，client1发现node-01是编号最小的，所以client1获得锁，当执行完成后，删除node-01。而client2发现在自己之前还有node-01，所以它监听node-01的删除事件。当node-01被删除时，client2即获得锁。以此类推。Curator中就使用类似的方式。