Zookeeper面试题汇总大全

1，概述

Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。

2，Zookeeper特点

1. Zookeeper：一个leader多个follower组成的集群。
2. 集群中只要有半数以上的节点存活，zk集群就能正常提供服务。
3. 全局数据一致性：每一个server都保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的。
4. 更新请求按顺序进行，来自同一个client的更新请求按其发送顺序依次执行。
5. 数据更新原子性：一次数据更新要么成功，要么失败。
6. 实时性：在一定时间范围内，client能读到最新的数据。

3，数据结构

zk数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称作一个ZNode，每个ZNode默认能够存储1MB的数据，每个ZNode都可以通过路径唯一标识。

4， 应用场景

zk应用场景包括统一命名服务，统一配置管理，统一集群管理，服务器节点动态上下线，软负载均衡等等。

1. 统一命名服务
   

2. 统一配置管理
   

3. 统一集群管理
   

4. 服务器动态上下线
   

5. 软负载均衡
   

5， 常见配置参数解读

Zookeeper中的配置文件zoo.cfg中参数含义解读如下：

1. tickTime =2000：通信心跳数，Zookeeper服务器与客户端心跳时间，单位毫秒
   Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。
   它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)

2. initLimit =10：LF初始通信时限
   集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。

3. syncLimit =5：LF同步通信时限
   集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。

4. dataDir：数据文件目录+数据持久化路径
   主要用于保存Zookeeper中的数据。

5. clientPort =2181：客户端连接端口
   监听客户端连接的端口。

6，zk节点类型

7，监听器原理

8，选举机制

1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
3）以一个简单的例子来说明整个选举的过程。
假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如下图所示。

（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；
（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING
（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；
（5）服务器5启动，同4一样当小弟。

9，zk写数据流程

10，zk部署

（1）部署方式单机模式、集群模式
（2）角色：Leader和Follower
（3）集群最少需要机器数：3

11，zk集群节点数为什么是单数

（1）防止由脑裂造成的集群不可用。
集群脑裂通常发生在节点通信不可达的情况下，整个集群分裂成多个独立的子集群，选举出各自的master。
假如集群包含5个节点，由于通信原因，分裂成两个子集群，有两种情况：
a: 1+4
b: 2+3
无论是哪种情况，都存在一个子集群节点的数量大于总节点数/2，zk能够正常对外提供服务。
假如集群包含6个节点，分裂情况如下：
a:1+5
b:2+4
c:3+3
在第三种情况下，没有子集群的节点数量大于总节点数/2，zk无法对外提供服务。
如果zk无法对外提供服务，那将是致命的，所以从这一角度说，zk集群通常采用奇数。
（2）在容错能力相同的情况下，奇数台更节省资源。
5台机器和6台机器的容错能力相同，都是两台。奇数节点能节省资源。

12，zk实现分布式锁

首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端想要获得锁时，需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。
之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。
如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2。 Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。于是，Client2向排序仅比它靠前的节点Lock1注册Watcher，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。
这时候，如果又有一个客户端Client3前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock3。 Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3是不是顺序最靠前的一个，结果同样发现节点Lock3并不是最小的。于是，Client3向排序仅比它靠前的节点Lock2注册Watcher，用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败，进入了等待状态。
这样一来，Client1得到了锁，Client2监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列，很像是Java当中ReentrantLock所依赖的AQS（AbstractQueuedSynchronizer）。
释放锁分为两种情况：
1.任务完成，客户端显示释放，当任务完成时，Client1会显示调用删除节点Lock1的指令。
2.任务执行过程中，客户端崩溃，获得锁的Client1在任务执行过程中，如果崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。
由于Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。
同理，如果Client2也因为任务完成或者节点崩溃而删除了节点Lock2，那么Client3就会接到通知。
以下是zk和Redis实现分布式锁比较。