共计 2774 个字符，预计需要花费 7 分钟才能阅读完成。
常见相干问题
ZooKeeper 是什么？
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，它是集群的管理者，监督着集群中各个节点的状态依据节点提交的反馈进行下一步正当操作。最终，将简略易用的接口和性能高效、性能稳固的零碎提供给用户。客户端的读申请能够被集群中的任意一台机器解决，如果读申请在节点上注册了监听器，这个监听器也是由所连贯的 zookeeper 机器来解决。对于写申请，这些申请会同时发给其余 zookeeper 机器并且达成统一后，申请才会返回胜利。因而，随着 zookeeper 的集群机器增多，读申请的吞吐会进步然而写申请的吞吐会降落。有序性是 zookeeper 中十分重要的一个个性，所有的更新都是全局有序的，每个更新都有一个惟一的工夫戳，这个工夫戳称为 zxid（Zookeeper Transaction Id）。而读申请只会绝对于更新有序，也就是读申请的返回后果中会带有这个 zookeeper 最新的 zxid。
节点类型
- PERSISTENT- 长久化目录节点 客户端与 zookeeper 断开连接后，该节点仍旧存在
- PERSISTENT_SEQUENTIAL- 长久化程序编号目录节点 客户端与 zookeeper 断开连接后，该节点仍旧存在，只是 Zookeeper 给该节点名称进行程序编号
- EPHEMERAL- 长期目录节点 客户端与 zookeeper 断开连接后，该节点被删除
- EPHEMERAL_SEQUENTIAL- 长期程序编号目录节点。客户端与 zookeeper 断开连接后，该节点被删除，只是 Zookeeper 给该节点名称进行程序编号
集群模式
在 ZooKeeper 集群中将服务器分成 Leader、Follow、Observer 三种角色服务器，在集群运行期间这三种服务器所负责的工作各不相同：
- Leader 角色服务器负责管理集群中其余的服务器，是集群中工作的调配和调度者。
- Follow 服务器的次要工作是选举出 Leader 服务器，在产生 Leader 服务器选举的时候，零碎会从 Follow 服务器之间依据少数投票准则，选举出一个 Follow 服务器作为新的 Leader 服务器。
- Observer 服务器则次要负责解决来自客户端的获取数据等申请，并不参加 Leader 服务器的选举操作，也不会作为候选者被选举为 Leader 服务器。
Zookeeper 工作原理
Zookeeper 的外围是原子播送，这个机制保障了各个 Server 之间的同步。实现这个机制的协定叫做 Zab 协定。
Zab 协定有两种模式，它们别离是恢复模式（选主）和播送模式（同步）。当服务启动或者在领导者解体后，Zab 就进入了恢复模式，当领导者被选举进去，且大多数 Server 实现了和 leader 的状态同步当前，恢复模式就完结了。状态同步保障了 leader 和 Server 具备雷同的零碎状态。
Zookeeper 下 Server 工作状态
每个 Server 在工作过程中有三种状态：
LOOKING：以后 Server 不晓得 leader 是谁，正在搜查
LEADING：以后 Server 即为选举进去的 leader
FOLLOWING：leader 曾经选举进去，以后 Server 与之同步
Zookeeper 分布式锁（文件系统、告诉机制）
有了 zookeeper 的一致性文件系统，锁的问题变得容易。
锁服务能够分为两类，一个是放弃独占，另一个是管制时序。
对于第一类，咱们将 zookeeper 上的一个 znode 看作是一把锁，通过 createznode 的形式来实现。所有客户端都去创立 /distribute_lock 节点，最终胜利创立的那个客户端也即领有了这把锁。用完删除掉本人创立的 distribute_lock 节点就开释出锁。对于第二类，/distribute_lock 曾经事后存在，所有客户端在它上面创立长期程序编号目录节点，和选 master 一样，编号最小的取得锁，用完删除，顺次不便。
zookeeper 是如何选取主 leader 的？
当 leader 解体或者 leader 失去大多数的 follower，这时 zk 进入恢复模式，恢复模式须要从新选举出一个新的 leader，让所有的 Server 都复原到一个正确的状态。
Zk 的选举算法有两种：一种是基于 basic paxos 实现的，另外一种是基于 fast paxos 算法实现的。零碎默认的选举算法为 fast paxos。
1、Zookeeper 选主流程 (basic paxos)
（1）选举线程由以后 Server 发动选举的线程负责，其次要性能是对投票后果进行统计，并选出举荐的 Server；
（2）选举线程首先向所有 Server 发动一次询问 (包含本人)；
（3）选举线程收到回复后，验证是否是本人发动的询问 (验证 zxid 是否统一)，而后获取对方的 id(myid)，并存储到以后询问对象列表中，最初获取对方提议的 leader 相干信息 (id,zxid)，并将这些信息存储到当次选举的投票记录表中；
（4）收到所有 Server 回复当前，就计算出 zxid 最大的那个 Server，并将这个 Server 相干信息设置成下一次要投票的 Server；
（5）线程将以后 zxid 最大的 Server 设置为以后 Server 要举荐的 Leader，如果此时获胜的 Server 取得 n /2 + 1 的 Server 票数，设置以后举荐的 leader 为获胜的 Server，将依据获胜的 Server 相干信息设置本人的状态，否则，持续这个过程，直到 leader 被选举进去。
通过流程剖析咱们能够得出：要使 Leader 取得少数 Server 的反对，则 Server 总数必须是奇数 2n+1，且存活的 Server 的数目不得少于 n +1. 每个 Server 启动后都会反复以上流程。
在恢复模式下，如果是刚从解体状态复原的或者刚启动的 server 还会从磁盘快照中复原数据和会话信息，zk 会记录事务日志并定期进行快照，不便在复原时进行状态复原。
2、Zookeeper 选主流程 (basic paxos) fast paxos 流程是在选举过程中，某 Server 首先向所有 Server 提议本人要成为 leader，当其它 Server 收到提议当前，解决 epoch 和 zxid 的抵触，并承受对方的提议，而后向对方发送承受提议实现的音讯，反复这个流程，最初肯定能选举出 Leader。
Zookeeper 同步流程
选完 Leader 当前，zk 就进入状态同步过程。
1、Leader 期待 server 连贯；
2、Follower 连贯 leader，将最大的 zxid 发送给 leader；
3、Leader 依据 follower 的 zxid 确定同步点；
4、实现同步后告诉 follower 曾经成为 uptodate 状态；
5、Follower 收到 uptodate 音讯后，又能够从新承受 client 的申请进行服务了。