Zookeeper面试题

1、Zookeeper需要装几台？

半数机制：2n+1，安装奇数台；集群中半数以上机器存活，集群可用

台数多，好处：提高可靠性；坏处：影响通信延时

2、常用命令

1. 启动客户端：bin/zkCli.sh
2. 显示所有操作命令：help
3. 查看当前znode中所包含的内容：ls /
4. 查看当前节点数据并能看到更新次数等数据：ls2 /
5. 创建普通节点：create /app1 "hello app1"
6. 获得节点的值：get /app1
7. 创建短暂节点：create -e /app-emphemeral 8888
8. 创建带序号的节点：create -s /app2/aa 888
9. 修改节点数据值：set /app1 999
10. 节点的值变化监听：get /app1 watch
11. 节点的子节点变化监听（路径变化）：ls /app1 watch
12. 删除节点：delete /app1/bb
13. 递归删除节点：rmr /app2
14. 查看节点状态：stat /app1

3、适用场景

1. 统一命令服务

   在分布式环境下，经常要对应用/服务器进行统一命名，便于识别

   例如：IP不容易记住，而域名容易记住

2. 统一配置管理

   • 分布式环境下，配置文件同步非常常见

     一般要求一个集群中，所有节点的配置信息是一致的，比如kafka集群

     对配置文件修改后，希望能够快速同步到各个节点上

   • 配置管理可交由zookeeper实现

     可将配置信息写入zookeeper上的一个znode

     各个客户端服务器监听这个znode

     一旦znode中的数据被修改，zookeeper将通知各个客户端服务器

3. 统一集群管理

   • 分布式环境中，实时掌握每个节点的状态是必要的

     可根据节点实时状态做出一些调整

   • zookeeper可以实现实时监控节点状态变化

     可将节点信息写入zookeeper上的一个znode

     监听这个znode可获取它的实时状态变化

4. 服务器节点动态上下线

   客户端实时洞察到服务器上下线的变化

   • 服务器启动时去注册信息（创建都是临时节点）
   • 获取当前在线服务器列表，并且注册监听
   • 服务器节点下载
   • 服务器节点上下线时间通知
   • process()重新再去获取服务器列表，并注册监听

5. 软负载均衡

   在zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

4、在你接触的项目里面，你的zookeeper在哪方面使用了？

1. Hadoop的HA，其他的一些HA场景
2. Kafka
3. HBase
4. Spark Streaming与Kafka整合

5、如何选举leader？

全新集群选举

假设目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选举过程如下：

1. 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于LOOKING；

2. 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING；

3. 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为Follower；

4. 服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为Follower；

5. 服务器5启动，后面的逻辑同服务器4成为Follower。

非全新集群选举

对于运行正常的zookeeper集群，中途有机器down掉，需要重新选举时，选举过程就需要加入数据ID、服务器ID和逻辑时钟。其中：

数据ID：数据新的version就大，数据每次更新都会更新version；

服务器ID：就是我们配置的myid中的值，每个机器一个；

逻辑时钟：这个值从0开始递增,每次选举对应一个值。 如果在同一次选举中,这个值是一致的。

这样选举的标准就变成

逻辑时钟小的选举结果被忽略，重新投票；

统一逻辑时钟后，数据id大的胜出；

数据id相同的情况下，服务器id大的胜出；

根据这个规则选出leader。

6、Zookeeper节点类型？

永久(Persistent)：客户端和服务器端断开连接后，创建的节点不删除

临时(Ephemeral)：客户端和服务器端断开连接后，创建的节点自己删除

永久化目录节点：客户端与Zookeeper断开连接后，该节点依旧存在
永久化顺序编号目录节点：客户端与Zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

临时目录节点：客户端与Zookeeper断开连接后，该节点被删除
临时顺序编号目录节点：客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

说明：创建znode时设置顺序标识，znode名称后会附加一个值，顺序号时一个单调递增的计数器，由父节点维护

注意：在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序

7、Zookeeper写数据流程？

1. Client向Zookeeper的Server1上写数据，发送一个写请求

2. 如果Server1不是Leader，那么Server1会把接收到的请求进一步转发给Leader，因为每个Zookeeper的Server里面有一个是Leader；这个Leader会将写请求广播给各个Server，比如Server1和Server2，各个Server会将该写请求加入待写队列，并向Leader发送成功消息

3. 当Leader收到半数以上Server的成功信息，说明该写操作可以执行；当Leader会向各个Server发送提交信息，各个Server收到消息后会落实队列里的写请求，此时写成功

4. Server1会进一步通知Client数据写成功了，这时就认为整个写操作成功

8、Zookeeper的监听原理是什么？

1. 首先要有一个main()线程
2. 在main线程中创建Zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）
3. 通过connect线程将注册的监听事件发送给Zookeeper
4. 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中
5. Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程
6. listener线程内部调用了process()方法

9、什么是CAP法则？Zookeeper符合了这个法则的哪两个？

CAP法则：强一致性、高可用性、分区容错性

Zookeeper符合强一致性、高可用性

10、Paxos算法？

Paxos算法是一种基于消息传递且具有高度容错特性的一致性算法

分布式系统中的节点通信存在两种模型：共享内存（shared memory）、消息传递（messages passing）

其中消息传递（messages passing）是基于消息传递通信模型的分布式系统，不可避免的会发生一些错误：进程可能会慢、被杀死或者重启；消息可能会延迟、丢失、重复；在基础Paxos场景中，限不考虑可能出现消息篡改即拜占庭错误的情况

Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性

Paxos算法缺陷：在网络复杂的情况下，一个应用Paxos算法的分布式系统，可能很久无法收敛，甚至陷入活锁的情况

一个完整的Paxos算法流程分为：

1. Prepare阶段

   Proposer向Acceptors发出Prepare请求Promise（承诺）

   Acceptors针对收到的Prepare请求进行Promise承诺

2. Accept阶段

   Proposer收到多数Acceptors承诺的Promise，向Acceptors发出Propose请求

   Acceptors针对收到的Propose请求进行Accept处理

3. Learn阶段

   Proposer将形成的决议发送给所有的Learners