zookeeper

前言

• Zookeeper面试题   zab协议
  
• 面试题：Dubbo中zookeeper做注册中心，如果注册中心集群全都挂掉，发布者和订阅者之间还能通信么？
  
• 简单理解Zookeeper的Leader选举
  
• Zookeeper工作原理（详细）
  

一、zookeeper概念

ZooKeeper 是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

Zookeeper 的 Java 客户端都有哪些？

• Zookeeper 自带的 zkclient

• Apache 开源的 Curator：实际项目中，采用 Curator 居多。因为，功能更加强大。

1、zookeeper工作机制：

2、zookeeper特点

3、数据结构

4 应用场景

提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。

二、内部原理

1 选举机制（面试重点）

1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。

2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

3）以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如图：

• （1）服务器1启动，此时只有它一台服务器启动了，它发出去的报文没有任何响应，所以它的选举状态一直是LOOKING状态。
  
• （2）服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。
  
• （3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
  
• （4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。
  
• （5）服务器5启动，同4一样当小弟。
  

2、节点类型

Zookeeper 的文件系统是什么？

Zookeeper 提供一个多层级的节点命名空间——节点称为 znode：这些节点都可以设置关联的数据；与文件系统不同的是，文件系统中只有文件节点可以存放数据而目录节点不行。

Zookeeper 为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得 Zookeeper 不能用于存放大量的数据，每个节点的存放数据上限为 1M 。

• PERSISTENT 持久节点    
• PERSISTENT_SEQUENTIAL 持久顺序节点
  
• EPHEMERAL 临时节点   
• EPHEMERAL_SEQUENTIAL 临时顺序节点
  

3、 监听器原理（面试重点） 

4、写数据流程

Zookeeper 对于读写请求有所不同：

• 客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的 Zookeeper 机器来处理。
• 对于写请求，这些请求会同时发给其他 Zookeeper 机器并且达成一致后，请求才会返回成功。因此，随着 Zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。

5、通知机制？

Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

流程如下：

• 第一步，客户端注册 Watcher 。
• 第二步，服务端处理 Watcher 。
• 第三步，客户端回调 Watcher 。

三、Zookeeper 集群

1、 ZooKeeper的部署方式有哪几种？集群中的角色有哪些？集群最少需要几台机器？

（1）部署方式：单机模式、集群模式

（2）角色：Leader和Follower

（3）集群最少需要机器数：3

Zookeeper 集群，是一个由多个 Server 组成，一个 Leader，多个 Follower。（这个不同于我们常见的 Master/Slave 模式）Leader 为客户端服务器提供读写服务，除了 Leader 外其他的机器只能提供读服务。
每个 Server 保存一份数据副本全数据一致，分布式读 Follower ，写由 Leader 实施更新请求转发，由 Leader 实施更新请求顺序进行，来自同一个 Client 的更新请求按其发送顺序依次执行数据更新原子性，一次数据更新要么成功，要么失败。
全局唯一数据视图，Client 无论连接到哪个 Server，数据视图都是一致的实时性，在一定事件范围内，Client 能读到最新数据。

2、什么是zab协议

ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性；基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

Zab 协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）：

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

  更加详细的描述。

  当整个 Zookeeper 集群刚刚启动，或者 Leader 服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式。

  • 首先，选举产生新的Leader服务器。
  • 然后，集群中 Follower 服务器开始与新的 Leader 服务器进行数据同步。
  • 当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，

• 广播：状态同步保证了 Leader 和 Server 具有相同的系统状态。

  更加详细的描述。

  Leader 服务器开始接收客户端的事务请求，生成事务提案来进行事务请求处理。

3、ZooKeeper 集群中个服务器之间是怎样通信的？

Leader 服务器会和每一个 Follower/Observer 服务器都建立 TCP 连接，同时为每个 Follower/Observer 都创建一个叫做 LearnerHandler 的实体。

• LearnerHandler 主要负责 Leader 和 Follower/Observer 之间的网络通讯，包括数据同步，请求转发和 Proposal 提议的投票等。
• Leader 服务器保存了所有 Follower/Observer 的 LearnerHandler 。

4、Zookeeper 的选举算法有两种：

• LeaderElection ： 使用 basic paxos 算法。
  
• FastLeaderElection ：使用 fast paxos 算法。系统默认的选举算法为 fast paxos 。最终在 Zookeeper 3.4.0 版本之后，只保留 FastLeaderElection 版本。

Zookeeper 选主流程(fast paxos)？

1. FastLeaderElection 成了Zookeeper默认的Leader选举算法。
   
2. FastLeaderElection 是标准的 Fast Paxos 的实现。它首先向所有 Server 提议自己要成为 Leader ，当其它 Server 收到提议以后，解决 epoch 和 zxid 的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息。重复这个流程，最后一定能选举出Leader。
   
3. FastLeaderElection 算法通过异步的通信方式来收集其它节点的选票，同时在分析选票时又根据投票者的当前状态来作不同的处理，以加快 Leader 的选举进程。