ZooKeeper复制模式

ZooKeeper服务有两种不同的运行模式。独立模式（standalone mode）和复制模式（replicated mode）.

独立模式：简单，适合于测试环境，不能保证高可用性和恢复性。

复制模式：适合生产环境，运行于一个计算机集群上，通过复制来实现高可用性，只要集合体中半数以上的机器处于可用状态，它就能提供服务。因此集合体通常包含奇数台机器。

ZooKeeper概念：它所做的就是确保对znode树的每个修改都会被复制到集合体中超过半数的机器上。如果少于半数的机器出现故障，则最少有一台机器保存最新的状态，其余的副本最终也会更新到这个状态。

ZooKeeper使用了Zab协议，该协议包括两个无限重复的阶段：

阶段1：领导选举

    集合体中的所有机器通过一个选择过程来选出一台被称为“领导者”（leader）的机器，其他的机器被称为“跟随者”（follower）。一旦半数以上（或指定数量）的跟随者已经将其状态与领导者同步，则表明这个阶段已经完成。

阶段2：原子广播

    所有的写请求都被转发给领导者，再由领导者将更新广播给跟随者。当半数以上的跟随者都已经将修改持久化以后，领导者才会提交这个更新，然后客户端才会收到一个更新成功的响应。这个用来达成共识的协议被设计成具有原子性，因此每个修改要么成功要么失败。这类似于数据库的两阶段提交协议。

当领导者出现故障，其余的机器会选出另外一个领导者，并和新的领导者一起继续提供服务。随后，如果之前的领导者恢复正常，便成为一个跟随者。领导者选举的过程是非常快的，大约200毫米，因此在选举的过程中不会出现明显的性能降低。

在更新内存中znode树之前，集合体中的所有机器都会先将更新写入磁盘。任何一台机器都可以为读请求提供服务，并且由于读请求只涉及内存检索，因此非常快。