2021年 全网最细大数据学习笔记（五）：Zookeeper 集群
文章目录
- 一、学前必备知识
- 二、Zookeeper 简介
- 三、Zookeeper 安装及配置、启动 Zookeeper 集群
- 四、Zookeeper 数据模型以及节点类型
- 五、ZooKeeper 的 shell 操作
- 六、ZooKeeper Watcher(监听机制)
- 七、ZooKeeper 选举机制
-
- 7.1 全新集群选举
- 7.2 非全新集群选举
- 八、ZooKeeper 是如何实现数据一致性的呢？
- 九、ZooKeeper Java API 操作
一、学前必备知识
- 2021年 全网最细大数据学习笔记（一）：初识 Hadoop
- 2021年 全网最细大数据学习笔记（二）：Hadoop 伪分布式安装
- 2021年 全网最细大数据学习笔记（三）：Hadoop 集群的搭建与配置
- 2021年 全网最细大数据学习笔记（四）：Hadoop 之 HDFS的基本使用
二、Zookeeper 简介
Zookeeper 是 Hadoop 中非常重要的组件，它的主要功能是为分布式系统提供一致性协调服务，提供的功能包括配置维护、域名服务、分布式同步和组服务等。Google 中类似服务叫作 Chubby。
Zookeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 的开源实现，是 Hadoop 和 HBase 的重要组件。主要用来解决分布式集群中应用系统的一致性问题。ZooKeeper 本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。ZooKeeper 的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper 包含一个简单的原语集，提供 Java 和 C 的接口。
ZooKeeper 代码版本中，提供了分布式独享锁、选举、队列的接口。其中分布锁和队列有 Java 和 C 两个版本，选举只有 Java 版本。
那么 Zookeeper 能做什么事情呢，简单的例子：使用 Zookeeper 可以保证总服务器自动感知有多少提供搜索引擎的服务器并向这些服务器发出搜索请求，当总服务器宕机时自动启用备用的总服务器。应用场景：
注意：ZK 主要是用来管理其他框架的，单独使用没有任何意义。类似于动物园中的管理员：
Zookeeper 特性：
- 全局数据一致：集群中每个服务器保存一份相同的数据副本，client 无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征。
- 可靠性：如果消息被其中一台服务器接受，那么将被所有的服务器接受。
- 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息 a 在消息 b 前发布，则在所有 Server 上消息 a 都将在消息 b 前被发布；偏序是指如果一个消息 b 在消息 a 后被同一个发送者发布，a 必将排在 b 前面。
- 数据更新原子性：一次数据更新要么成功(半数以上节点成功)，要么失败，不存在中间状态。
- 实时性：Zookeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。
Zookeeper 集群角色：
- Leader：Zookeeper 集群工作的核心。事务请求(写操作)的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。对于create、setData、delete 等有写操作的请求，则需要统一转发给 Leader 处理，Leader 需要决定编号、执行操作，这个过程称为一个事务。
- Follower：处理客户端非事务(读操作)请求，转发事务请求给 Leader；
参与集群 Leader 选举投票。 - 此外，针对访问量比较大的 Zookeeper 集群，还可新增观察者角色。Observer：观察者角色，观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader 服务器进行处理。与 Follower 的区别就是不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。
三、Zookeeper 安装及配置、启动 Zookeeper 集群
Zookeeper 集群搭建指的是 ZooKeeper 分布式模式安装。通常由 2n+1(奇数) 台 Server 组成。这是因为为了保证 Leader 选举(基于 Paxos 算法的实现)能过得到多数的支持，所以 ZooKeeper 集群的数量一般为奇数。Zookeeper 运行需要 java 环境，所以需要提前安装 jdk，关于 jdk 的安装笔者这里不再赘述。对于安装 Leader+Follower 模式的集群，大致过程如下：
- 配置主机名称到 IP 地址映射配置。
- 修改 ZooKeeper 配置文件。
- 远程复制分发安装文件。
- 设置 myid。
- 启动 ZooKeeper 集群。
说明：如果要想使用 Observer 模式，可在对应节点的配置文件添加如下配置：
peerType=observer
其次，必须在配置文件指定哪些节点被指定为 Observer，如：
server.1:bigdata01:2181:3181:observer
server.1:192.168.61.100:2181:3181:observer
这里，我们安装的是 Leader + Follower 模式：
| 服务器IP | 主机名 | myid的值 |
|---|---|---|
| 192.168.61.100 | bigdata01 | 1 |
| 192.168.61.101 | bigdata02 | 2 |
| 192.168.61.102 | bigdata03 | 3 |
下面进行具体的步骤演示：
(1) 将本地的 bigdata01、bigdata02、bigdata03 启动，并且使用 SecureCRT 进行连接。
(2) 使用 SecureCRT 把 apache-zookeeper-3.5.8-bin.tar.gz 的安装包上传到 /data/soft/ 目录下。笔者可以通过 http://archive.apache.org/dist/zookeeper/ 进行 zookeeper 安装包的下载。
(3) 在 bigdata01 节点上，进入到 /data/soft 目录，解压 zookeeper 的压缩包进行安装。命令：cd /data/soft/、tar -zxvf apache-zookeeper-3.5.8-bin.tar.gz。
bin 目录：Zookeeper 的可执行脚本目录，包括 Zookeeper 服务进程、Zookeeper 客户端等脚本。其中，.sh 是 Linux 环境下的脚本，.cmd 是 Windows 环境下的脚本。conf 目录：配置文件目录。其中 zoo_sample.cfg 为样例配置文件，需要修改为自己的名称，一般为 zoo.cfg。log4j.properties 为日志配置文件。lib：Zookeeper 依赖的包。
(4) 在 bigdata01 节点上，修改配置文件。命令如下：
mv apache-zookeeper-3.5.8-bin zookeeper-3.5.8
cd zookeeper-3.5.8/conf/
cp zoo_sample.cfg zoo.cfg
mkdir -p /data/soft/zookeeper-3.5.8/zkdatas/
vi zoo.cfg 修改如下：
dataDir=/data/soft/zookeeper-3.5.8/zkdatas -- zookeeper的数据存放目录
autopurge.snapRetainCount=3 --保留多少个快照
autopurge.purgeInterval=1 --日志多少小时清理一次
-- 集群中服务器地址
server.1=bigdata01:2888:3888
server.2=bigdata02:2888:3888
server.3=bigdata03:2888:3888
(5) 添加 myid 配置。命令：echo 1 > /data/soft/zookeeper-3.5.8/zkdatas/myid
(6) 把配置好的 zookeeper 拷贝到其他两个节点。命令：
scp -rq /data/soft/zookeeper-3.5.8/ bigdata02:/data/soft/
scp -rq /data/soft/zookeeper-3.5.8/ bigdata03:/data/soft/
(7) 修改 bigdata02、bigdata03 节点上的 myid 文件。命令：
echo 2 > /data/soft/zookeeper-3.5.8/zkdatas/myid
echo 3 > /data/soft/zookeeper-3.5.8/zkdatas/myid
(8) 三个节点启动 zookeeper 服务。命令：
bigdata01 节点：
[root@bigdata01 ~]# cd /data/soft/zookeeper-3.5.8/bin/
[root@bigdata01 bin]# zkServer.sh start
ZooKeeper JMX enabled by default
Using config: /data/soft/zookeeper-3.5.8/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED
bigdata02 节点：
[root@bigdata02 ~]# cd /data/soft/zookeeper-3.5.8/bin/
[root@bigdata02 bin]# zkServer.sh start
ZooKeeper JMX enabled by default
Using config: /data/soft/zookeeper-3.5.8/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED
bigdata03 节点：
[root@bigdata03 ~]# cd /data/soft/zookeeper-3.5.8/bin/
[root@bigdata03 bin]# zkServer.sh start
ZooKeeper JMX enabled by default
Using config: /data/soft/zookeeper-3.5.8/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED
(9) 三个节点分别查看启动状态。命令：
[root@bigdata01 bin]# zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /data/soft/zookeeper-3.5.8/bin/../conf/zoo.cfg
Client port found: 2181. Client address: localhost.
Mode: follower
[root@bigdata02 bin]# zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /data/soft/zookeeper-3.5.8/bin/../conf/zoo.cfg
Client port found: 2181. Client address: localhost.
Mode: leader
[root@bigdata03 bin]# zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /data/soft/zookeeper-3.5.8/bin/../conf/zoo.cfg
Client port found: 2181. Client address: localhost.
Mode: follower
分别在 bigdata01、bigdata02、bigdata03 上执行 jps 命令验证是否有 QuorumPeerMain 进程如果都有就说明 zookeeper 集群启动正常了。例如：
如果没有就到对应的节点的 logs 目录下查看 zookeeper*-*.out 日志文件。
四、Zookeeper 数据模型以及节点类型
- 上图中的每个节点称为一个 Znode。 每个 Znode 由 3 部分组成：stat 状态信息(此为状态信息, 描述该Znode的版本, 权限等信息)、children(该Znode下的子节点)、data(与该 Znode 关联的数据)。
- ZooKeeper 的数据模型，在结构上和标准文件系统的非常相似，拥有一个层次的命名空间，都是采用树形层次结构，ZooKeeper 树中的每个节点被称为 ==> Znode。和文件系统的目录树一样，ZooKeeper 树中的每个节点可以拥有子节点，但也有不同之处。
- Znode 兼具文件和目录两种特点，既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子 Znode。用户对 Znode 具有增、删、改、查等操作(权限允许的情况下)。
- Znode 具有原子性操作，读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的 ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。
- Znode 存储数据大小有限制，ZooKeeper 虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以 KB 为大小单位。ZooKeeper 的服务器和客户端都被设计为严格检查并限制每个 Znode 的数据大小至多 1M，常规使用中应该远小于此值。
- Znode 通过路径引用，如同 Linux 中的文件路径。路径必须是绝对的，因此它们必须由斜杠字符来开头。除此以外，他们它们是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在 ZooKeeper 中，路径由 Unicode 字符串组成，并且有一些限制。
Zookeeper 节点类型。Znode 有两种，分别为 临时节点 和 永久节点。节点的类型在创建时即被确定，并且不能改变。临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
Znode 还有一个序列化的特性，如果创建的时候指定的话，该 Znode 的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为 %10d (10位数字，没有数值的数位用 0 补充，例如 0000000001)。这样便会存在四种类型的 Znode 节点，分别对应：
五、ZooKeeper 的 shell 操作
首先运行 zkCli.sh –server ip 进入命令行工具，quit 命令退出会话窗口，如下：
zkCli.sh -- 默认进入当前主机(节点)命令行工具
zkCli.sh -server bigdata01:2181 -- 进入指定主机(节点)命令行工具
quit 退出
ctrl + l 清屏
| 命令 | 说明 | 参数 |
|---|---|---|
| create [-s] [-e] path data acl | 创建Znode | -s 指定是顺序节点 -e 指定是临时节点 |
| ls path [watch] | 列出Path下所有子Znode | |
| get path [watch] | 获取Path对应的Znode的数据和属性 | |
| ls2 path [watch] | 查看Path下所有子Znode以及子Znode的属性 | |
| set path data [version] | 更新节点 | version 数据版本 |
| delete path [version] | 删除节点, 如果要删除的节点有子Znode，则无法删除 | version 数据版本 |
| rmr path | 删除节点, 如果有子Znode则递归删除 | |
| setquota -n|-b val path | 修改Znode配额 | -n 设置子节点最大个数 -b 设置节点数据最大长度 |
| history | 列出历史记录 |
【示例1】创建普通永久节点。命令：create /app1 hello
【示例2】创建顺序(序列化)节点。命令：create -s /app2 world
【示例3】创建临时节点。命令：create -e /tempnode world
【示例4】创建顺序的临时节点。命令：create -s -e /tempnode2 aaa
【示例5】获取节点数据。命令：get /app1
【示例6】修改节点数据。命令：set /app1 hadoop。
【示例7】删除节点(删除的节点不能有子节点)。命令：delete /tempnode20000000004
【示例8】 递归删除。命令：rmr /app1。
节点属性：
节点属性说明如下：
- dataVersion：数据版本号，每次对节点进行 set 操作，dataVersion 的值都会增加1(即使设置的是相同的数据)，可有效避免了数据更新时出现的先后顺序问题。
- cversion：子节点的版本号。当 znode 的子节点有变化时，cversion 的值就会增加 1。
- cZxid：Znode创建的事务 id。
- mZxid：Znode被修改的事务 id，即每次对 znode 的修改都会更新mZxid。对于 zk 来说，每次的变化都会产生一个唯一的事务 id，zxid (ZooKeeper Transaction Id)。通过 zxid，可以确定更新操作的先后顺序。例如，如果 zxid1 小于 zxid2，说明 zxid1 操作先于 zxid2 发生，zxid 对于整个 zk 都是唯一的，即使操作的是不同的 znode。该值可以表示数据的新旧程度，zxid 越大，则数据越新。
- ctime：节点创建时的时间戳。
- mtime：节点最新一次更新发生时的时间戳。
- ephemeralOwner：如果该节点为临时节点，ephemeralOwner 值表示与该节点绑定的 session id. 如果不是，ephemeralOwner 值为
0x0。在 client 和 server 通信之前，首先需要建立连接，该连接称为 session。连接建立后，如果发生连接超时、授权失败，或者显式关闭连接，连接便处于 CLOSED 状态，此时 session 结束。
ZK 监控动态上下线，如下图所示：
六、ZooKeeper Watcher(监听机制)
ZooKeeper 提供了分布式数据发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。
ZooKeeper 中，引入了 Watcher 机制来实现这种分布式的通知功能。ZooKeeper 允许客户端向服务端注册一个 Watcher 监听，当服务端的一些事件触发了这个 Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。总的来说可以概括 Watcher 为以下三个过程：客户端向服务端注册 Watcher、服务端事件发生触发 Watcher、客户端回调 Watcher 得到触发事件情况。
一次性触发：事件发生触发监听，一个 WatcherEvent 就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发。同一个事件类型在不同的通知状态中代表的含义有所不同，下表列举了常见的通知状态和事件类型。
| KeeperState | EventType | 触发条件 | 说明 |
|---|---|---|---|
| None | 连接成功 | ||
| SyncConnected | NodeCreated | Znode被创建 | 此时处于连接状态 |
| SyncConnected | NodeDeleted | Znode被删除 | 此时处于连接状态 |
| SyncConnected | NodeDataChanged | Znode数据被改变 | 此时处于连接状态 |
| SyncConnected | NodeChildChanged | Znode的子Znode数据被改变 | 此时处于连接状态 |
| Disconnected | None | 客户端和服务端断开连接 | 此时客户端和服务器处于断开连接状态 |
| Expired | None | 会话超时 | 会收到一个SessionExpiredExceptio |
| AuthFailed | None | 权限验证失败 | 会收到一个AuthFailedException |
其中连接状态事件(type=None, path=null)不需要客户端注册，客户端只要有需要直接处理就行了。
事件封装：ZooKeeper 使用 WatchedEvent 对象来封装服务端事件并传递。WatchedEvent 包含了每一个事件的三个基本属性：通知状态(keeperState)，事件类型(EventType)和节点路径(path)
event 异步发送：Watcher 的通知事件从服务端发送到客户端是异步的。
先注册再触发：Zookeeper 中的 Watch 机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。
--1.设置节点数据变动监听：
get /app20000000002 watch
'get path [watch]' has been deprecated. Please use 'get [-s] [-w] path' instead.
--2.通过另一个客户端更改节点数据：
set /app20000000002 world
此时设置监听的节点收到通知，如下：
七、ZooKeeper 选举机制
Zookeeper 默认的算法是 FastLeaderElection，采用投票数大于半数则胜出的逻辑。
- 服务器 ID。 比如有三台服务器，编号分别是 1、2、3。编号越大在选择算法中的权重越大。
- 选举状态。 LOOKING，竞选状态。FOLLOWING，随从状态，同步 Leader 状态，参与投票。OBSERVING，观察状态，同步 Leader 状态，不参与投票。LEADING，领导者状态。
- 数据ID。 服务器中存放的最新数据 Version。值越大说明数据越新，在选举算法中数据越新权重越大。
- 逻辑时钟。 也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。
7.1 全新集群选举
假设目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是 1、2、3、4、5，按编号依次启动，它们的选举过程如下：
- 服务器1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1 的状态一直属于 Looking。
- 服务器2 启动，给自己投票，同时与之前启动的服务器1 交换结果，由于服务器2 的编号大所以服务器2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是 LOOKING。
- 服务器3 启动，给自己投票，同时与之前启动的服务器1、2交换信息，由于服务器3 的编号最大所以服务器3 胜出，此时投票数正好大于半数，所以服务器3 成为领导者，服务器1、2成为小弟。
- 服务器4 启动，给自己投票，同时与之前启动的服务器1、2、3交换信息，尽管服务器4 的编号大，但之前服务器3已经胜出，所以服务器4 只能成为小弟。
- 服务器5 启动，后面的逻辑同服务器4，成为小弟。
7.2 非全新集群选举
对于运行正常的 Zookeeper 集群，中途有机器宕掉，需要重新选举时，选举过程就需要加入数据 ID、服务器 ID 和逻辑时钟。
- 数据 ID：数据新的 version 就大，数据每次更新都会更新 version。
- 服务器ID：就是我们配置的 myid 中的值，每个机器一个。
- 逻辑时钟：这个值从 0 开始递增，每次选举对应一个值。 如果在同一次选举中，这个值是一致的。这样选举的标准就变成：
- 逻辑时钟小的选举结果被忽略，重新投票；
- 统一逻辑时钟后，数据 id 大的胜出；
- 数据 id 相同的情况下，服务器 id 大的胜出；
根据这个规则选出 Leader。
八、ZooKeeper 是如何实现数据一致性的呢？
在分布式场景下，ZooKeeper 是如何实现数据一致性的呢？Zab 一致性协议。ZooKeeper 是通过 Zab 协议来保证分布式事务的最终一致性。Zab(ZooKeeper Atomic Broadcast，ZooKeeper 原子广播协议)支持崩溃恢复，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。系统架构可以参考下面这张图：
在 ZooKeeper 集群中，所有客户端的请求都是写入到 Leader 进程中的，然后，由 Leader 同步到其他节点，称为 Follower。在集群数据同步的过程中，如果出现 Follower 节点崩溃或者 Leader 进程崩溃时，都会通过 Zab 协议来保证数据一致性。Zab 协议的具体实现可以分为以下两部分：
1、消息广播阶段。 Leader 节点接受事务提交，并且将新的 Proposal 请求广播给 Follower 节点，收集各个节点的反馈，决定是否进行 Commit，在这个过程中，也会使用 Quorum 选举机制。
2、崩溃恢复阶段。 如果在同步过程中出现 Leader 节点宕机，会进入崩溃恢复阶段，重新进行 Leader 选举，崩溃恢复阶段还包含数据同步操作，同步集群中最新的数据，保持集群的数据一致性。
整个 ZooKeeper 集群的一致性保证就是在上面两个状态之前切换，当 Leader 服务正常时，就是正常的消息广播模式；当 Leader 不可用时，则进入崩溃恢复模式，崩溃恢复阶段会进行数据同步，完成以后，重新进入消息广播阶段。
Zab 流程分析。 Zab 的具体流程可以拆分为消息广播、崩溃恢复和数据同步三个过程，下面我们分别进行分析。
1、消息广播。 在 ZooKeeper 中所有的事务请求都由 Leader 节点来处理，其他服务器为 Follower，Leader 将客户端的事务请求转换为事务 Proposal，并且将 Proposal 分发给集群中其他所有的 Follower。完成广播之后，Leader 等待 Follwer 反馈，当有过半数的 Follower 反馈信息后，Leader 将再次向集群内 Follower 广播 Commit 信息，Commit 信息就是确认将之前的 Proposal 提交。Leader 节点的写入也是一个两步操作，第一步是广播事务操作，第二步是广播提交操作，其中 过半数指的是反馈的节点数 >=N/2+1，N 是全部的 Follower 节点数量。消息广播的过程描述可以参考下图：
- 客户端的写请求进来之后，Leader 会将写请求包装成 Proposal 事务，并添加一个递增事务 ID，也就是 Zxid，Zxid 是单调递增的，以保证每个消息的先后顺序；
- 广播这个 Proposal 事务，Leader 节点和 Follower 节点是解耦的，通信都会经过一个先进先出的消息队列，Leader 会为每一个 Follower 服务器分配一个单独的 FIFO 队列，然后把 Proposal 放到队列中；
- Follower 节点收到对应的 Proposal 之后会把它持久到磁盘上，当完全写入之后，发一个 ACK 给 Leader；
- 当 Leader 收到超过半数 Follower 机器的 ack 之后，会提交本地机器上的事务，同时开始广播 commit， Follower 收到 commit 之后，完成各自的事务提交。
2、崩溃恢复。 消息广播通过 Quorum 机制，解决了 Follower 节点宕机的情况，但是如果在广播过程中 Leader 节点崩溃呢？这就需要 Zab 协议支持的崩溃恢复，崩溃恢复可以保证在 Leader 进程崩溃的时候可以重新选出 Leader，并且保证数据的完整性。崩溃恢复和集群启动时的选举过程是一致的，也就是说，下面的几种情况都会进入崩溃恢复阶段：
- 初始化集群，刚刚启动的时候
- Leader 崩溃，因为故障宕机
我们通过一个模拟的例子，来了解崩溃恢复阶段，也就是选举的流程。假设正在运行的集群有五台 Follower 服务器，编号分别是 Server1、Server2、Server3、Server4、Server5，当前 Leader 是 Server2，若某一时刻 Leader 挂了，此时便开始 Leader 选举。
选举过程如下：
- 各个节点变更状态，变更为 Looking。ZooKeeper 中除了 Leader 和 Follower，还有 Observer 节点，Observer 不参与选举， Leader 挂后，余下的 Follower 节点都会将自己的状态变更为 Looking，然后开始进入 Leader 选举过程。
- 各个 Server 节点都会发出一个投票，参与选举。在第一次投票中，所有的 Server 都会投自己，然后各自将投票发送给集群中所有机器，在运行期间，每个服务器上的 Zxid 大概率不同。
- 集群接收来自各个服务器的投票，开始处理投票和选举。处理投票的过程就是对比 Zxid 的过程，假定 Server3 的 Zxid 最大，Server1 判断 Server3 可以成为 Leader，那么 Server1 就投票给 Server3，判断的依据如下：首先选举 epoch 最大的，如果 epoch 相等，则选 zxid 最大的，若 epoch 和 zxid 都相等，则选择 server id 最大的，就是配置 zoo.cfg 中的 myid；在选举过程中，如果有节点获得超过半数的投票数，则会成为 Leader 节点，反之则重新投票选举。
3、数据同步。 崩溃恢复完成选举以后，接下来的工作就是数据同步，在选举过程中，通过投票已经确认 Leader 服务器是最大 Zxid 的节点，同步阶段就是利用 Leader 前一阶段获得的最新 Proposal 历史，同步集群中所有的副本。
九、ZooKeeper Java API 操作
持续更新。。。。