zookeeper相关面试题

r囧r小猫 2023-03-12 15:29 16阅读 0赞

原文链接：https://blog.csdn.net/Yang\_Hui\_Liang/article/details/90263005

**1、什么是zookeeper**  
zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。  
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

**2、zookeeper集群如何保证数据一致性**  
zookeeper中 有一个leader 该主机是用于写 写入的更新会自动同步到其他的 follower服务器中  如果leader挂掉后 会重新选举一个leader 所以如果是集群环境 最少2n+1台机器组成

**3、zookeeper如何存储数据**  
zookeeper使用类似于window注册表的树状结构存储数据 只有一个根节点 / 子节点可以存储数据

**4、zookeeper的节点类型有哪些**  
永久节点：调用写入 自动持久化到硬盘

临时节点：在zk会话存在期间才存在的znode，如果会话停止了，那么znode也被删除了。临时性的znode不允许有子节点

序列节点：创建znode的时候，可以要求zk为路径后面附上一个单调递增的计数器，这个计数器的格式这样的 %010d，这个计数器是由父znode维护的一个signed int，最大值2147483647

**5、zookeeper应用场景**  
 一：作为分布式配置中心

二： 用于微服务注册中心 注册微服务的信息

三： 实现分布式锁 分布式主键 秒杀

**6、zookeeper通知机制**  
client端会对某个znode建立一个watcher事件，当该znode发生变化时，这些client会收到zk的通知，然后client可以根据znode变化来做出业务上的改变等。

**7、zookeeper做了什么**  
一：命名服务  
命名服务是指通过指定的名字来获取资源或者服务的地址，利用zk创建一个全局的路径，即是唯一的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

二：配置管理  
程序分布式的部署在不同的机器上，将程序的配置信息放在zk的znode下，当有配置发生改变时，也就是znode发生变化时，可以通过改变zk中某个目录节点的内容，利用watcher通知给各个客户端，从而更改配置。

三：集群管理  
所谓集群管理主要在乎于两点：是否有机器退出和加入、选举master。   
对于第一点，所有机器约定在父目录下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。  
新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了，对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。

四：分布式锁  
有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。   
对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute\_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute\_lock 节点就释放出锁。   
对于第二类， /distribute\_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。

五：队列管理  
两种类型的队列：  
1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。   
2、队列按照 FIFO 方式进行入队和出队操作。   
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。   
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。在特定的目录下创建PERSISTENT\_SEQUENTIAL节点，创建成功时Watcher通知等待的队列，队列删除序列号最小的节点用以消费。

**8、Zookeeper工作原理**  
Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

**9、zookeeper是如何保证事务的顺序一致性的**  
zookeeper采用了递增的事务Id来标识，所有的proposal（提议）都在被提出的时候加上了zxid，zxid实际上是一个64位的数字，高32位是epoch（时期; 纪元; 世; 新时代）用来标识leader是否发生改变，如果有新的leader产生出来，epoch会自增，低32位用来递增计数。当新产生proposal的时候，会依据数据库的两阶段过程，首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

**10、Zookeeper 下 Server工作状态**  
每个Server在工作过程中有三种状态  
LOOKING：当前Server不知道leader是谁，正在搜寻  
LEADING：当前Server即为选举出来的leader  
FOLLOWING：leader已经选举出来，当前Server与之同步

**11、zookeeper是如何选取主leader的**  
当leader崩溃或者leader失去大多数的follower，这时zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

**12、Zookeeper选主流程**  
（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会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。

**13、机器中为什么会有leader**  
在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行leader选举。

**14、zookeeper负载均衡和nginx负载均衡区别**  
zk的负载均衡是可以调控，nginx只是能调权重，其他需要可控的都需要自己写插件；但是nginx的吞吐量比zk大很多，应该说按业务选择用哪种方式。

**15、zookeeper watch机制**  
一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。