Question

ZooKeeper 服务可以在两种模式下运行。在 standalone 模式下，我们可以运行一个单独的 ZooKeeper 服务器，我们可以在这种模式下进行基本功能的简单测试，但是这种模式没有办法体现 ZooKeeper 的高可用特性和快速恢复特性。在生产环境中，我们一般采用 replicated（复制）模式安装在多台服务器上，组建一个叫做 ensemble 的集群。ZooKeeper 在他的副本之间实现高可用性，并且只要 ensemble 集群中能够推举出主服务器，ZooKeeper 的服务就可以一直不终断。例如，在一个 5 个节点的 ensemble 中，容忍有 2 个节点脱离集群，服务还是可用的。因为剩下的 3 个节点投票，可以产生超过集群半数的投票，来推选一台主服务器。而 6 个节点的 ensemble 中，也只能容忍 2 个节点的服务器死机。因为如果 3 个节点脱离集群，那么剩下的 3 个节点无论如何不能产生超过集群半数的投票来推选一个主服务器。所以，一般情况下 ensemble 中的服务器数量都是奇数。

从概念上来看，ZooKeeper 其实是很简单的。他所做的一切就是保证每一次对 znode 树的修改，都能够复制到 ensemble 的大多数服务器上。如果非主服务器脱离集群，那么至少有一台服务器上的副本保存了最新状态。剩下的其他的服务器上的副本，会很快更新这个最新的状态。

为了实现这个简单而不平凡的设计思路，ZooKeeper 使用了一个叫做 Zab 的协议。这个协议分为两阶段，并且不断的运行在 ZooKeeper 上：

• 阶段 1：领导选举（Leader election）

Ensemble 中的成员通过一个程序来选举出一个首领成员，我们叫做 leader。其他的成员就叫做 follower。在大多数（quorum）follower 完成与 leader 状态同步时，这个阶段才结束。

• 阶段 2： 原子广播（Atomic broadcast）

所有的写入请求都会发送给 leader，leader 在广播给 follower。当大多数的 follower 已经完成了数据改变，leader 才会将更新提交，客户端就会随之得到 leader 更新成功的消息。协议中的设计也是具有原子性的，所以写入操作只有成功和失败两个结果。

如果 leader 脱离了集群，剩下的节点将选举一个新的 leader。如果之前的 leader 回到了集群中，那么将被视作一个 follower。leader 的选举很快，大概 200ms 就能够产生结果，所以不会影响执行效率。

Ensemble 中的所有节点都会在更新内存中的 znode 树的副本之前，先将更新数据写入到硬盘上。读操作可以请求任何一台 ZooKeeper 服务器，而且读取速度很快，因为读取是内存中的数据副本。