zookeeper篇

问题 1 你怎么理解 zookeeper？

Zookeeper 是 Google 的 Chubby 的开源实现，是 Hadoop 的分布式协调服务

它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等

zookeeper 能干什么

1、 确保集群中只有一个主

2、 监控集群中的节点是否存活，进行分配资源。

3、 将配置信息存入 zookeeper，集群中启动时可以读取通用的信息。

例如：

Hadoop2.0,使用 Zookeeper 的事件处理确保整个集群只有一个活跃的 NameNode,存储配置信息
等.

HBase,使用 Zookeeper 的事件处理确保整个集群只有一个 HMaster,察觉 HRegionServer 联机和宕
机,存储访问控制列表等.

问题 2 工作中哪些地方用到了 zookeeper？

1、 我们所有的集群只要是涉及到主从 master 的都会用到 zookeeper

2、 我们自定义一些框架涉及到存储元数据状态的，需要用到 zookeeper，例如自定义 RPC 框架

问题 3 谈谈你对 zookeeper 选举机制的理解？

1. zookeeper 原理

   1. zookeeper 的选举机制（全新集群）

      以一个简单的例子来说明整个选举的过程. 假设有五台服务器组成的 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 运行了一段时间之后，有 机器 down 掉，重新选举时，选举过程就相对复杂了。 需要加入数据 id、leader id。

      数据 id：数据新的 id 就大，数据每次更新都会更新 id。

      Leader id：就是我们配置的 myid 中的值，每个机器一个。

      选举的标准就变成：

      1. 数据 id 大的胜出

      2. 数据 id 相同的情况下，leader id 大的胜出根据这个规则选出 leader。

问题 4 zookeeper HA 原理

zk 实现集群 HA 的原理有两种，以 hadoop 举例：

第 一种：

1、 两个 NameNode 同时向 zk 注册同一个临时目录，注册成功的为主节点，不成功的监控这个节点

2、 如果主节点挂掉了，那么这个临时目录就消失了，这时候从节点监控到就可以重新注册这个目录，变身为从节点

3、 当失败的主节点恢复后，发现这个临时目录已经存在，就会像之前的从节点一样监控这个节点，变为从节点

第二种：

1、 两个 NameNode 向 zk 某个目录下同时注册临时序列化目录

2、 然后两个节点把注册的两个临时序列化目录读取下来进行比较，谁是较大的谁就是主节点

3、 当主节点挂掉后，从节点监控目录子节点目录的变化，判断自己是不是 大的节点，从而决定是否自切换为主节点

4、失败的主节点重启后，会重新注册临时序列化节点，重复上面的比较步骤

问题 5 zookeeper 端口说明，作用

zookeeper-端口说明 一、zookeeper 有三个端口（可以修改）

1、2181

2、3888

3、2888

二、3 个端口的作用

1、 2181：对 cline 端提供服务

2、 3888：选举 leader 使用

3、 2888：集群内机器通讯使用（Leader 监听此端口）

问题 6 zookeeper 主从服务器如何通信

在 Zookeeper 整个系统中，有 3 种角色的服务，client、Follower、leader。其中 client 负责发起应用的请求，Follower 接受 client 发起的请求，参与事务的确认过程，在 leader crash 后的 leader选择。

而leader 主要承担事务的协调，当然 leader 也可以承担接收客户请求的功能，为了方便描述，后面的描述都是 client 与 Follower 之间的通信，如果 Zookeeper 的配置支持 leader 接收 client 的请求，client 与 leader 的通信跟 client 与 Follower 的通信模式完全一样。Follower 与 leader 之间的角色可能在某一时刻进行转换。

一个 Follower 在 leader crash 掉以后可能被集群（Quorum）的Follower 选举为 leader。

而一个 leader 在 crash 后，再次加入集群（Quorum）将作为 Follower角色存在。在一个集群（Quorum）中,除了在选举 leader 的过程中没有 Follower 和 leader 的区分外，其他任何时刻都只有 1 个 leader 和多个 Follower。Client、Follower 和 leader 之间的通信架构如下：

Client 与 Follower 之间

为了使客户端具有较高的吞吐量，Client 与 Follower 之间采用 NIO 的通信方式。当 client 需要与Zookeeper service 打交道时，首先读取配置文件确定集群内的所有 server 列表，按照一定的 load balance 算法选取一个 Follower 作为一个通信目标。这样 client 和 Follower 之间就有了一条由NIO 模式构成的通信通道。这条通道会一直保持到 client 关闭 session 或者因为 client 或 Follower任一方因某种原因异常中断通信连接。正常情况下, client 与 Follower 在没有请求发起的时候都有心跳检测。

Follower 与 leader 之间

Follower 与 leader 之间的通信主要是因为 Follower 接收到像（create, delete, setData, setACL, createSession, closeSession, sync）这样一些需要让 leader 来协调最终结果的命令，将会导致Follower 与 leader 之间产生通信。由于 leader 与 Follower 之间的关系式一对多的关系，非常适合client/server 模式，因此他们之间是采用 c/s 模式，由 leader 创建一个 socket server，监听各Follower 的协调请求。集群在选择 leader 过程中由于在选择 leader 过程中没有 leader，在集群中的任何一个成员都需要与其他所有成员进行通信，当集群的成员变得很大时，这个通信量是很大的。选择 leader 的过程发生在 Zookeeper 系统刚刚启动或者是 leader 失去联系后，选择 leader 过程中将不能处理用户的请求，为了提高系统的可用性，一定要尽量减少这个过程的时间。选择哪种方式让他们可用快速得到选择结果呢？Zookeeper 在这个过程中采用了策略模式，可用动态插入选择 leader 的算法。系统默认提供了 3 种选择算法，AuthFastLeaderElection，FastLeaderElection，LeaderElection。其中 AuthFastLeaderElection 和 LeaderElection 采用UDP 模式进行通信，而 FastLeaderElection 仍然采用 tcp/ip 模式。在 Zookeeper 新的版本中，新增了一个 learner 角色，减少选择 leader 的参与人数。使得选择过程更快。一般说来 Zookeeper leader 的选择过程都非常快，通常<200ms。