关于zookeeper常见的8个面试问题

1. zookeeper是什么,都有哪些功能

Zookeeper是一个树形数据结构的高性能的分布式应用程序的协调服务。

拥有如下功能：

一、命名服务（naming）: 是指经过指定的名字来获取资源或者服务的地址，提供者的信息。保证服务全局惟一。

二、配置管理（configuration management）： 将配置信息保存在Zookeeper的某个目录节点中，而后将全部须要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收Zookeeper的通知，而后从Zookeeper获取新的配置信息应用到系统中。

三、分布式锁（synchronization）： 解决分布式资源访问冲突的问题。

四、集群管理（group services）:

多台 Server 组成一个服务集群，那么必需要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它集群必须知道，从而作出调整从新分配服务策略。一样当增长集群的服务能力时，就会增长一台或多台 Server，一样也必须让“总管”知道。

2. zk 有几种部署模式

1. 单机模式
2. 集群模式（配置 zoo.cfg）
3. 伪集群模式（一台服务器启动多个zookeeper实例运行）

3. zk 的通知机制

客户端端会对某个 znode 创建一个 watcher 事件，当该 znode 发生变化时，这些客户端会收到 zookeeper 的通知，而后客户端能够根据 znode 变化来作出业务上的改变。

4. zk 的分布式锁实现方式

在讲zk分布锁以前，先看下zookeeper中几个关于节点的有趣的性质：

1. 有序节点：假如当前有一个父节点为/lock，咱们能够在这个父节点下面建立子节点；zookeeper提供了一个可选的有序特性，例如咱们能够建立子节点“/lock/node-”而且指明有序，那么zookeeper在生成子节点时会根据当前的子节点数量自动添加整数序号，也就是说若是是第一个建立的子节点，那么生成的子节点为/lock/node-0000000000，下一个节点则为/lock/node-0000000001，依次类推。
2. 临时节点：客户端能够创建一个临时节点，在会话结束或者会话超时后，zookeeper会自动删除该节点。
3. 事件监听：在读取数据时，咱们能够同时对节点设置事件监听，当节点数据或结构变化时，zookeeper会通知客户端。当前zookeeper有以下四种事件： 一、节点建立；二、节点删除；三、节点数据修改；四、子节点变动。

下面描述使用zookeeper实现分布式锁的算法流程，假设锁空间的根节点为/lock：

1. 客户端链接zookeeper，并在/lock下建立临时的且有序的子节点，第一个客户端对应的子节点为/lock/lock-0000000000，第二个为/lock/lock-0000000001，以此类推。
2. 客户端获取/lock下的子节点列表，判断本身建立的子节点是否为当前子节点列表中序号最小的子节点，若是是则认为得到锁，不然监听/lock的子节点变动消息，得到子节点变动通知后重复此步骤直至得到锁；
3. 执行业务代码；
4. 完成业务流程后，删除对应的子节点释放锁。

5. zk 采用的哪一种分布式一致性协议? 还有哪些分布式一致性协议

ZAB(Zookeeper Atomic Broadcast)协议是专门为zookeeper设计的一致性协议。

ZAB协议包括两种基本的模式：消息广播和崩溃恢复

1. 当整个服务框架在启动过程当中，或是当Leader服务器出现网络中断崩溃退出与重启等异常状况时，ZAB就会进入恢复模式并选举产生新的Leader服务器。
2. 当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步以后，ZAB协议就会退出崩溃恢复模式，进入消息广播模式。
3. 当有新的服务器加入到集群中去，若是此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加入的服务器会自动进入数据恢复模式，找到Leader服务器，并与其进行数据同步，而后一块儿参与到消息广播流程中去。

以上其实大体经历了三个步骤：

1. 崩溃恢复：主要就是Leader选举过程。
2. 数据同步：Leader服务器与其余服务器进行数据同步。
3. 消息广播：Leader服务器将数据发送给其余服务器。

ZAD和Paxos算法的联系和区别

共同点：

1. 二者都存在一个相似于Leader进程的角色，由其负责协调多个Follow进程的运行。
2. Leader进程都会等待超过半数的Follower作出正确的反馈后，才会将一个提案进行提交。
3. 在ZAB协议中，每一个Proposal中都包含了一个epoch值，用来表明当前Leader周期，在Paxos算法中，一样存在这样一个标识，只是名字变成了Ballot。 不一样点：

Paxos算法中，一个新的选举产生的主进程会进行两个阶段的工做

1. 读阶段，新的主进程会经过和全部其余进程进行通讯的方式来搜集上一个主进程提出的提案，并将它们提交。
2. 写阶段，当前主进程开始提出它本身的提案。
3. ZAB在Paxos基础上额外添加一个同步阶段。同步阶段以前，ZAB协议存在一个和Paxos读阶段相似的发现（Discovery）阶段

同步阶段中，新的Leader会确保存在过半的Follower已经提交了以前Leader周期中的全部事务Proposal

• 发现阶段的存在，确保全部进程都已经完成对以前全部事物Proposal的提交
• ZAB协议主要用于构建一个高可用的分布式数据主备系统，例如ZooKeeper，Paxos算法则是用于构建一个分布式的一致性状态机系统

6. zk 是怎样保证主从节点的状态同步

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫作Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。

恢复模式：当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步之后，恢复模式就结束了。

所以，选主获得的leader保证了同步状态的进行，状态同步又保证了leader和Server具备相同的系统状态，当leader失去主权后能够在其余follower中选主新的leader。

7. 集群中为何要有主节点

在分布式环境中，有些业务逻辑只须要集群中的某一台机器进行执行，

其余的机器能够共享这个结果，这样能够大大减小重复计算，提升性能，因此就须要主节点

8. leader 选举过程

有两种状况会发起Leader选举：

1. 服务器启动的时候
2. 服务器运行的时候当Leader宕机

在讲解流程以前，先说明一下选举流程中涉及到的角色：

• LOOKING：寻找Leader状态，处于该状态须要进入选举流程（只有该节点才能够投票）
• LEADING：领导者状态，处于该状态的节点说明是角色已是Leader
• FOLLOWING：跟随者状态，表示Leader已经选举出来，当前节点角色是follower
• OBSERVER：观察者状态，代表当前节点角色是observer（该节点不参与竞选）

三个核心选举原则：

1. Zookeeper集群中只有超过半数以上的服务器启动，集群才能正常工做；
2. 在集群正常工做以前，myid小的服务器给myid大的服务器投票，直到集群正常工做，选出Leader；
3. 选出Leader以后，以前的服务器状态由Looking改变为Following，之后的服务器都是Follower。

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

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是同样的。

假设这些服务器从id1-5，依序启动：

由于一共5台服务器，只有超过半数以上，即最少启动3台服务器，集群才能正常工做。

（1）服务器1启动，发起一次选举。

服务器1投本身一票。此时服务器1票数一票，不够半数以上（3票），选举没法完成；

服务器1状态保持为LOOKING；

（2）服务器2启动，再发起一次选举。

服务器1和2分别投本身一票，此时服务器1发现服务器2的id比本身大，更改选票投给服务器2；

此时服务器1票数0票，服务器2票数2票，不够半数以上（3票），选举没法完成；

服务器1，2状态保持LOOKING；

（3）服务器3启动，发起一次选举。

与上面过程同样，服务器1和2先投本身一票，而后由于服务器3id最大，二者更改选票投给为服务器3；

这次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数（3票），服务器3当选Leader。

服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

（4）服务器4启动，发起一次选举。

此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。

此时服务器4服从多数，更改选票信息为服务器3；

服务器4并更改状态为FOLLOWING；

（5）服务器5启动，同4同样投票给3，此时服务器3一共5票，服务器5为0票；

服务器5并更改状态为FOLLOWING；

（6）选举结果

最终Leader是服务器3，状态为LEADING；

其他服务器是Follower，状态为FOLLOWING。