常见相干问题

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的申请进行服务了。