zookeeper系列(二)-白红宇

前言

在上一篇我们讲到，ZooKeeper 是一个开源的分布式协调服务，由于zookeeper的设计目标是用于协调分布式系统的工作，所以其本身也需要支持集群部署，以避免分布式系统出现单点问题。

分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

在之前的集群模式中最常见的莫过于： Master/Slave 模式（主备模式）。在这种模式中，通常 Master服务器作为主服务器提供写服务，其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。

例如MySQL就可以通过设置slave服务器去读取master的二进制日志来进行不同数据库之间的数据同步，这就是典型的master/slave模式的应用。

但是，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色。如下图所示

ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器，Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，Follower 和 Observer 都只能提供读服务。

Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。

当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，zookeeper就会进入恢复模式并选举产生新的Leader服务器。这个过程大致是这样的：

Synchronization（同步阶段）:同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后准 leader 才会成为真正的 leader。

Broadcast（广播阶段）到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。

以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么。

1) 服务器1启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的选举状态一直是LOOKING状态。

2) 服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1，2还是继续保持LOOKING状态。

3) 服务器3启动，根据前面的理论分析，服务器3成为服务器1，2，3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的leader。

4) 服务器4启动，根据前面的分析，理论上服务器4应该是服务器1，2，3，4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。

5) 服务器5启动，同4一样，当小弟。

那么，初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。

需要加入数据id、leader id和逻辑时钟：

逻辑时钟：这个值从0开始递增，每次选举对应一个值，也就是说: 如果在同一次选举中，那么这个值应该是一致的 ; 逻辑时钟值越大，说明这一次选举leader的进程更新.

选举的标准就变成：

1、逻辑时钟小的选举结果被忽略，重新投票。

2、统一逻辑时钟后，数据id大的胜出。

3、数据id相同的情况下，leader id大的胜出。

根据这个规则选出leader。

到这里对于zookeeper的介绍也就差不多了，更加深层次的paxos算法和ZAB协议就不在这里讨论，待以后再说。

zookeeper的核心是
Paxos算法，但是zookeeper 并没有完全采用 Paxos算法，而是使用 ZAB 协议作为其保证数据一致性的核心算法。

所以这里我们最后总结一下zookeeper的特性吧

1. Zookeeper：一个leader，多个follower组成的集群。

2. 全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的。

3. 分布式读写，更新请求转发，由leader实施。

4. 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行到zookeeper中去。

5. 数据更新原子性，一次数据更新要么成功，要么失败。所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。

6.实时性，在一定时间范围内，client能读到最新数据。

7. 可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

参考自：