文章目录
- Question1:简要介绍一下Zookeeper架构?
- Answer1:
- Question2:谈一谈对 ZAB协议 的认识?
- Answer2:
- 第一,事务编号Zxid(事务请求 计数器 + epoch)
- 第二,epoch
- 第三,ZAB协议两种模式
- 第四,ZAB协议四个阶段(整个选主过程只与followers和leader有关,observer没有选举权)
- 第五,ZAB协议的JAVA 实现(FLE-发现阶段和同步合并为Recovery Phase(恢复阶段))
- Question3:详细介绍一下Zookeeper集群的整个投票流程?
- Answer3:
- Question4:介绍一下Zookeeper工作原理(或谈一谈原子广播)?
- Answer4:
- Question5:介绍一下Znode目录节点
- Answer5:
面向面试的博客,以问答式Q/A方式呈现。
Question1:简要介绍一下Zookeeper架构?
Answer1:
Zookeeper 直译为动物园管理员,是一个集群管理工具,一般用于大数据集群管理,也可以管理其他集群,如Solr索引库集群。
Zookeeper 是一个分布式协调服务,可用于服务发现,分布式锁,分布式领导选举,配置管理等。Zookeeper 提供了一个类似于 Linux 文件系统的树形结构(可认为是轻量级的内存文件系统,但只适合存少量信息,完全不适合存储大量文件或者大文件),同时提供了对于每个节点的监控与通知机制。
Zookeeper 集群是一个基于主从复制的高可用集群,其架构如图所示:
每个服务器承担如下三种角色中的一种:Leader Follower Observer。
Leader:
1、维持心跳:一个 Zookeeper 集群同一时间只会有一个实际工作的 Leader,它会发起并维护与各 Follwer 及 Observer 间的心跳(就是上图中的ping 和 ack 交互)。
2、写操作过半数写入成功才提交:所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器。只要有超过半数节点(不包括 observer 节点)写入成功,该写请求就会被提交(类 2PC 协议)。
Follower:
1、维持心跳:一个 Zookeeper 集群可能同时存在多个 Follower,它会响应 Leader 的心跳。
2、读请求自己处理,写请求转发给Leader:Follower 可直接处理并返回客户端的读请求,同时会将写请求转发给 Leader 处理。
3、投票选举Leader:负责在 Leader 处理写请求时对请求进行投票。
Observer:
1、维持心跳:一个 Zookeeper 集群可能同时存在多个 Observer,它会响应 Leader 的心跳。
2、读请求自己处理,写请求转发给Leader:Observer 可直接处理并返回客户端的读请求,同时会将写请求转发给 Leader 处理。
3、无投票权:不负责在 Leader 处理写请求时对请求进行投票。
角色与 Follower 类似,但是无投票权。Zookeeper 需保证高可用和强一致性,为了支持更多的客户端,需要增加更多 Server;Server 增多,投票阶段延迟增大,影响性能;引入 Observer,Observer 不参与投票; Observers 接受客户端的连接,并将写请求转发给 leader 节点; 加入更多 Observer 节点,提高伸缩性,同时不影响吞吐率。
Question2:谈一谈对 ZAB协议 的认识?
Answer2:
第一,事务编号Zxid(事务请求 计数器 + epoch)
在 ZAB ( ZooKeeper Atomic Broadcast , ZooKeeper 原子消息广播协议) 协议的事务编号 Zxid 设计中,Zxid 是一个 64 位的数字,其中低 32 位是一个简单的单调递增的计数器,针对客户端每一个事务请求,计数器加 1;而高 32 位则代表 Leader 周期 epoch 的编号,每个当选产生一个新的 Leader 服务器,就会从这个 Leader 服务器上取出其本地日志中最大事务的 ZXID,并从中读取epoch 值,然后加 1,以此作为新的 epoch,并将低 32 位从 0 开始计数。
Zxid(Transaction id)类似于 RDBMS 中的事务 ID,用于标识一次更新操作的Proposal(提议)ID。为了保证顺序性,该 zkid 必须单调递增。
第二,epoch
epoch:可以理解为当前集群所处的年代或者周期,每个 leader 就像皇帝,都有自己的年号,所以每次改朝换代,leader 变更之后,都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃恢复之后,也没有人听他的了,因为 follower 只听从当前年代的 leader 的命令。
第三,ZAB协议两种模式
Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,Zab 就进入了恢复模式,当领导者被选举出来,且大多数 Server 完成了和 leader 的状态同步以后,恢复模式就结束了。状态同步保证了 leader 和 Server 具有相同的系统状态。
第四,ZAB协议四个阶段(整个选主过程只与followers和leader有关,observer没有选举权)
第一阶段,Leader election (选举阶段 - 选出准 Leader ):节点在一开始都处于选举阶段,只要有一个节点得到超半数节点的票数,它就可以当选准 leader。只有到达 广播阶段(broadcast) 准 leader 才会成为真正的 leader。这一阶段的目的是就是为了选出一个准 leader,然后进入下一个阶段。
第二阶段,Discovery (发现阶段 - 接受提议、生成 epoch 、接受 epoch ):在这个阶段,followers 跟准 leader 进行通信,同步 followers最近接收的事务提议。这个一阶段的主要目的是发现当前大多数节点接收的最新提议,并且准 leader 生成新的 epoch,让 followers 接受,更新它们的 accepted Epoch。
一个 follower 只会连接一个 leader,如果有一个节点 f 认为另一个 follower p 是 leader,f 在尝试连接 p 时会被拒绝,f 被拒绝之后,它(指f)就会进入重新选举阶段,直到连接到它(指f)支持的leader。
第三阶段,Synchronization (同步阶段 - 同步 follower 副本 ):同步阶段主要是利用 leader 前一阶段获得的最新提议历史,同步集群中所有的副本。只有当大多数节点都同步完成,准 leader 才会成为真正的 leader。follower 只会接收 zxid 比自己的 lastZxid 大的提议。
第四阶段,Broadcast(广播阶段 -leader 消息广播 ):到了这个阶段,Zookeeper 集群才能正式对外提供事务服务,并且 leader 可以进行消息广播。同时如果有新的节点加入,还需要对新节点进行同步。
ZAB 提交事务并不像 2PC 一样需要全部 follower 都 ACK,只需要得到超过半数的节点的 ACK 就可以了。
第五,ZAB协议的JAVA 实现(FLE-发现阶段和同步合并为Recovery Phase(恢复阶段))
协议的 Java 版本实现跟上面的定义有些不同,选举阶段使用的是 Fast Leader Election(FLE),它包含了选举的发现职责。因为 FLE 会选举拥有最新提议历史的节点作为 leader,这样就省去了发现最新提议的步骤。实际的实现将 发现阶段 和 同步合并为 Recovery Phase(恢复阶段)。所以,ZAB 的实现只有三个阶段:Fast Leader Election;Recovery Phase;Broadcast Phase。
Question3:详细介绍一下Zookeeper集群的整个投票流程?
Answer3:
每个 sever 首先给自己投票,然后用自己的选票和其他 sever 选票对比,权重大的胜出,使用权重较大的更新自身选票箱。具体选举过程如下:
- 每个 Server 启动以后都询问其它的 Server 它要投票给谁。对于其他 server 的询问,server 每次根据自己的状态都回复自己推荐的 leader 的 id 和上一次处理事务的 zxid(系统启动时每个 server 都会推荐自己)。
- 收到所有 Server 回复以后,就计算出 zxid 最大的那个 Server,并将这个 Server 相关信息设置成下一次要投票的 Server。
- 计算这过程中获得票数最多的的 server 为获胜者,如果获胜者的票数超过半数,则改server 被选为 leader。否则,继续这个过程,直到 leader 被选举出来。
- leader 就会开始等待 server 连接。
- Follower 连接 leader,将最大的 zxid 发送给 leader。
- Leader 根据 follower 的 zxid 确定同步点,至此选举阶段完成。
- 选举阶段完成 Leader 同步后通知 follower 已经成为 uptodate 状态。
- Follower 收到 uptodate 消息后,又可以重新接受 client 的请求进行服务了。
举例:目前有 5 台服务器,每台服务器均没有数据,它们的编号分别是 1,2,3,4,5,按编号依次启动,它们的选举过程如下:
- 服务器 1 启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,服务器 1 的状态一直属于 Looking。
- 服务器 2 启动,给自己投票,同时与之前启动的服务器 1 交换结果,由于服务器 2 的编号大所以服务器 2 胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是LOOKING。
- 服务器 3 启动,给自己投票,同时与之前启动的服务器 1,2 交换信息,由于服务器 3 的编号最大所以服务器 3 胜出,此时投票数正好大于半数,所以服务器 3 成为领导者,服务器1,2 成为小弟。
- 服务器 4 启动,给自己投票,同时与之前启动的服务器 1,2,3 交换信息,尽管服务器 4 的编号大,但之前服务器 3 已经胜出,所以服务器 4 只能成为小弟。
- 服务器 5 启动,后面的逻辑同服务器 4 成为小弟。
Question4:介绍一下Zookeeper工作原理(或谈一谈原子广播)?
Answer4:
Zookeeper整个工作流程步骤如下:
步骤一:Zookeeper 的核心是原子广播,这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式,它们分别是恢复模式和广播模式。
步骤二:当服务启动或者在领导者崩溃后,Zab 就进入了恢复模式,当领导者被选举出来,且大多数 server 的完成了和 leader 的状态同步以后,恢复模式就结束了。
步骤三:状态同步保证了 leader 和 server 具有相同的系统状态。
步骤四:一旦 leader 已经和多数的 follower 进行了状态同步后,他就可以开始广播消息了,即进入广播状态。这时候当一个 server 加入 zookeeper 服务中,它会在恢复模式下启动,发现 leader,并和 leader 进行状态同步。待到同步结束,它也参与消息广播。Zookeeper服务一直维持在 Broadcast 状态,直到 leader 崩溃了或者 leader 失去了大部分的followers 支持。
步骤五:广播模式需要保证 proposal 被按顺序处理,因此 zk 采用了递增的事务 id 号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了 zxid。
步骤六:实现中 zxid 是一个 64 为的数字,它高 32 位是 epoch 用来标识 leader 关系是否改变,每次一个 leader 被选出来,它都会有一个新的 epoch。低 32 位是个递增计数。
步骤七:当 leader 崩溃或者 leader 失去大多数的 follower,这时候 zk 进入恢复模式,恢复模式需要重新选举出一个新的 leader,让所有的 server 都恢复到一个正确的状态。
Question5:介绍一下Znode目录节点
Answer5:
Znode有四种形式的目录节点,如下:
- PERSISTENT:持久的节点。
- EPHEMERAL:暂时的节点。
- PERSISTENT_SEQUENTIAL:持久化顺序编号目录节点。
- EPHEMERAL_SEQUENTIAL:暂时化顺序编号目录节点。