每天十道面试题-20200331

题目

• 1、Zookeeper的java客户端都有哪些？
• 2、Zookeeper 下 Server工作状态
• 3、chubby是什么，和zookeeper比你怎么看？
• 4、ZAB和Paxos算法的联系与区别？
• 5、Zookeeper的典型应用场景
• 6、Chroot特性
• 7、会话创建过程会话管理？
• 8、服务器角色
• 9、集群支持动态添加机器吗？
• 10、Zookeeper对节点的watch监听通知是永久的吗？为什么不是永久的?

解答

题目一

• 题干：Zookeeper的java客户端都有哪些？
• 分析：

• zk自带的zkclient及Apache开源的Curator

• 回答：

• zk自带的zkclient及Apache开源的Curator。

题目二

• 题干：Zookeeper 下 Server工作状态？
• 分析：

• 服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。
  LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。
  FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
  LEADING：领导者状态。表明当前服务器角色是Leader。
  OBSERVING：观察者状态。表明当前服务器角色是Observer。

• 回答：

• LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。
  FOLLOWING：跟随者状态。表明当前服务器角色是Follower。
  LEADING：领导者状态。表明当前服务器角色是Leader。
  OBSERVING：观察者状态。表明当前服务器角色是Observer。

题目三

• 题干：chubby是什么，和zookeeper比你怎么看？
• 分析：

• chubby是google的，完全实现paxos算法，不开源。zookeeper是chubby的开源实现，使用zab协议，paxos算法的变种。。

• 回答：

• chubby是google的，完全实现paxos算法，不开源。zookeeper是chubby的开源实现，使用zab协议，paxos算法的变种。。

题目四

• 题干：ZAB和Paxos算法的联系与区别？
• 分析：

• 相同点：
  两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行
  Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交
  ZAB协议中，每个Proposal中都包含一个 epoch 值来代表当前的Leader周期，Paxos中名字为Ballot
  不同点：
  ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。

• 回答：

• 见分析。

题目五

• 题干：Zookeeper的典型应用场景？
• 分析：

• 数据发布/订阅
  负载均衡
  命名服务
  分布式协调/通知
  集群管理
  Master选举
  分布式锁
  分布式队列

• 回答：

• 数据发布/订阅
  负载均衡
  命名服务
  分布式协调/通知
  集群管理
  Master选举
  分布式锁
  分布式队列

题目六

• 题干：Chroot特性
• 分析：

• Chroot特性，该特性允许每个客户端为自己设置一个命名空间。如果一个客户端设置了Chroot，那么该客户端对服务器的任何操作，都将会被限制在其自己的命名空间下。
  通过设置Chroot，能够将一个客户端应用于Zookeeper服务端的一颗子树相对应，在那些多个应用公用一个Zookeeper进群的场景下，对实现不同应用间的相互隔离非常有帮助。

• 回答：

• 见分析

题目七

• 题干：会话创建过程会话管理？
• 分析：

• 分桶策略：将类似的会话放在同一区块中进行管理，以便于Zookeeper对会话进行不同区块的隔离处理以及同一区块的统一处理。
  分配原则：每个会话的“下次超时时间点”（ExpirationTime）

• 回答：

• 见分析

题目八

• 题干：服务器角色
• 分析：

• Leader
  事务请求的唯一调度和处理者，保证集群事务处理的顺序性
  集群内部各服务的调度者
  Follower
  处理客户端的非事务请求，转发事务请求给Leader服务器
  参与事务请求Proposal的投票
  参与Leader选举投票
  Observer
  3.3.0版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力
  处理客户端的非事务请求，转发事务请求给Leader服务器
  不参与任何形式的投票

• 回答：

• 见分析

题目九

• 题干：集群支持动态添加机器吗？

• 分析：

• 全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。
  逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。。

• 回答：

• 全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。
  逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。

题目十

• 题干：Zookeeper对节点的watch监听通知是永久的吗？为什么不是永久的?

• 分析：

• Watch Manger时服务端的Watcher管理者并且还负责Watcher事件的触发,并且移除那些被触发的Watcher见 第六题
  如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。
  一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。
  在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。

• 回答：

• Watch Manger时服务端的Watcher管理者并且还负责Watcher事件的触发,并且移除那些被触发的Watcher见 第六题
  如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。
  一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。
  在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。