简介
ZooKeeper 是一个开源的分布式协调服务，由雅虎创建，是 Google Chubby 的开源实现。分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
Zookeeper特性
- 顺序一致性（从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到zookeeper中）
- 原子性（所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，一定不会出现集群中部分机器应用了改事务，另外一部分没有应用的情况。）
- 单一视图（无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的。）
- 可靠性（一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变。）
- 实时性（zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性。）
Zookeeper数据模型
ZooKeeper提供的名称空间非常类似于标准文件系统。名称是由斜杠（/）分隔的路径元素序列。ZooKeeper名称空间中的每个节点都由路径标识。
有4种类型的znode
| 类型 | 定义 | 描述 |
|---|---|---|
| PERSISTENT | 持久化目录节点 | 客户端与zookeeper断开连接后，该节点依旧存在 |
| PERSISTENT_SEQUENTIAL | 持久化顺序编号目录节点 | 客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 |
| EPHEMERAL | 临时目录节点 | 客户端与zookeeper断开连接后，该节点被删除 |
| EPHEMERAL_SEQUENTIAL | 临时顺序编号目录节点 | 客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号 |
Zookeeper集群角色
| 角色 | 说明 |
|---|---|
| Leader(领导者) | 为客户端提供读和写的服务，负责投票的发起和决议，更新系统状态。 |
| Follower（跟随者） | 为客户端提供读服务，如果是写服务则转发给Leader。在选举过程中参与投票。 |
| Observe（观察者） | 为客户端提供读服务器，如果是写服务则转发给Leader。不参与选举过程中的投票，也不参与“过半写成功”策略。在不影响写性能的情况下提升集群的读性能。此角色于zookeeper3.3系列新增的角色。 |
| client（客户端） | 连接zookeeper服务器的使用着，请求的发起者。独立于zookeeper服务器集群之外的角色。 |
Zookeeper的核心
Zookeeper的核心是原子广播（Zab：Zookeeper Atomic Broadcast），该机制保证各个Server之间的同步。Zab协议有两种模式，分别是恢复模式和广播模式。
-
恢复模式：当Leader挂掉或者启动Server时，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server的完成了和leader的状态同步以后，恢复模式就结束了。
-
广播模式：状态同步保证了Leader和所有Server都具有相同的系统状态。这时候当Server加入Zookeeper集群后，会先在恢复模式下启动该Server，发现Leader后，并和Leader进行状态同步，待到同步结束，它也参与消息广播，即进入广播状态。Zookeeper服务一直维持在广播状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持，才会进入恢复模式，从新选举Leader。Broadcast模式就如Paxos算法所述，Leader提起一个请求，由Followers进行投票，Leader对投票结果进行计算，如果通过一半以上，则该请求通过，否则什么也不做。广播模式需要保证请求被按顺序处理，因此Zookeeper采用了递增的事务ID号(zxid)来保证。所有的请求都在被提出的时候加上了zxid。（zxid是一个64位的数字，低32代表一个单调递增的计数器，高32位代表Leader周期）。
写入请求
客户端通过Leader进行写操作
客户端向Leader发起写请求
Leader将写请求以Proposal的形式发给所有Follower并等待ACK
Leader将写请求以Proposal的形式发给所有Follower并等待ACK
Follower收到Leader的Proposal后返回ACK
Leader得到过半数的ACK（Leader对自己默认有一个ACK）后向所有的Follower和Observer发送Commmit
Leader将处理结果返回给客户端
注意：Leader并不需要得到Observer的ACK，即Observer无投票权，但仍须同步Leader的数据从而在处理读请求时可以返回尽可能新的数据；Leader不需要得到所有Follower的ACK，只要收到过半的ACK即可，同时Leader本身对自己有一个ACK。
客户端通过Follower/Observer进行写操作
Follower/Observer均可接受写请求，但不能直接处理，而需要将写请求转发给Leader处理；除了多了一步请求转发，其它流程与直接写Leader无任何区别
读入请求
客户端通过Leader/Follower/Observer都可直接处理读请求
由于处理读请求不需要服务器之间的交互，Follower/Observer越多，整体可处理的读请求量越大，也即读性能越好。