zookeeper系列(二)

前言

在上一篇咱们讲到，ZooKeeper 是一个开源的分布式协调服务，因为zookeeper的设计目标是用于协调分布式系统的工做，因此其自己也须要支持集群部署，以免分布式系统出现单点问题。

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

zookeeper的集群介绍

在以前的集群模式中最多见的莫过于： 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服务器。这个过程大体是这样的：

1. Leader election（选举阶段）：节点在一开始都处于选举阶段，只要有一个节点获得超半数节点的票数，它就能够当选准 leader。
2. Discovery（发现阶段）：在这个阶段，followers 跟准 leader 进行通讯，同步 followers 最近接收的事务提议。
3. Synchronization（同步阶段）:同步阶段主要是利用 leader 前一阶段得到的最新提议历史，同步集群中全部的副本。同步完成以后 准 leader 才会成为真正的 leader。
4. Broadcast（广播阶段） 到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，而且 leader 能够进行消息广播。同时若是有新的节点加入，还须要对新节点进行同步。

不一样类型集群的选举机制

1. 全新集群的选举机制

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

假设有五台服务器组成的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同样，当小弟。

2. 非全新集群的选举机制

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

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

• 数据id：数据新的id就大，数据每次更新都会更新id。
• Leader id：就是咱们配置的myid中的值，每一个机器一个。
• 逻辑时钟：这个值从0开始递增，每次选举对应一个值，也就是说: 若是在同一次选举中，那么这个值应该是一致的 ; 逻辑时钟值越大，说明这一次选举leader的进程更新.

选举的标准就变成：

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

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

三、数据id相同的状况下，leader id大的胜出。

根据这个规则选出leader。

总结

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

zookeeper的核心是 Paxos算法，可是zookeeper 并无彻底采用 Paxos算法 ，而是使用 ZAB 协议做为其保证数据一致性的核心算法。

因此这里咱们最后总结一下zookeeper的特性吧

zookeeper的特性

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

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

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

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

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

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

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

参考自：

github.com/Snailclimb/…