面试完腾讯,总结了这12道Zookeeper面试题

2021年11月22日 阅读数:2
这篇文章主要向大家介绍面试完腾讯,总结了这12道Zookeeper面试题,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。
面试完腾讯,总结了这12道Zookeeper面试题_分布式程序员的成长之路互联网/程序员/成长/职场阅读本文大概须要 2.8 分钟。

ZooKeeper 是一个开源的分布式协调服务,属于面试的热门考点。发现一篇很不错的文章,给你们参考。node

苦于找不到出处,特此感谢此文的做者。若有老铁知道出处,请留言告知。程序员

前言面试

ZooKeeper 是一个开源的分布式协调服务,能够基于 ZooKeeper 实现诸如:数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、配置维护,名字服务、分布式同步、分布式锁和分布式队列等功能。服务器

谈下你对 Zookeeper 的认识?网络

ZooKeeper 是一个分布式的,开放源码的分布式应用程序协调服务。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。负载均衡

ZooKeeper 的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。分布式

Zookeeper 都有哪些功能?ide

1. 集群管理:监控节点存活状态、运行请求等;性能

2. 主节点选举:主节点挂掉了以后能够从备用的节点开始新一轮选主,主节点选举说的就是这个选举的过程,使用 Zookeeper 能够协助完成这个过程;线程

3. 分布式锁:Zookeeper 提供两种锁:独占锁、共享锁。独占锁即一次只能有一个线程使用资源,共享锁是读锁共享,读写互斥,便可以有多线线程同时读同一个资源,若是要使用写锁也只能有一个线程使用。Zookeeper 能够对分布式锁进行控制。

4. 命名服务:在分布式系统中,经过使用命名服务,客户端应用可以根据指定名字来获取资源或服务的地址,提供者等信息。

谈下你对 ZAB 协议的了解?

ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。ZAB 协议包括两种基本的模式:崩溃恢复和消息广播。

当整个 Zookeeper 集群刚刚启动或者Leader服务器宕机、重启或者网络故障致使不存在过半的服务器与 Leader 服务器保持正常通讯时,全部服务器进入崩溃恢复模式,首先选举产生新的 Leader 服务器,而后集群中 Follower 服务器开始与新的 Leader 服务器进行数据同步。

当集群中超过半数机器与该 Leader 服务器完成数据同步以后,退出恢复模式进入消息广播模式,Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。

Zookeeper 怎么保证主从节点的状态同步?

Zookeeper 的核心是原子广播机制,这个机制保证了各个 server 之间的同步。实现这个机制的协议叫作 Zab 协议。Zab 协议有两种模式,它们分别是恢复模式和广播模式。

1. 恢复模式

当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数 server 完成了和 leader 的状态同步之后,恢复模式就结束了。状态同步保证了 leader 和 server 具备相同的系统状态。

2. 广播模式

一旦 leader 已经和多数的 follower 进行了状态同步后,它就能够开始广播消息了,即进入广播状态。

这时候当一个 server 加入 ZooKeeper 服务中,它会在恢复模式下启动,发现 leader,并和 leader 进行状态同步。待到同步结束,它也参与消息广播。

ZooKeeper 服务一直维持在 Broadcast 状态,直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。

Zookeeper 有几种部署模式?

Zookeeper 有三种部署模式:

1. 单机部署:一台集群上运行;

2. 集群部署:多台集群运行;

3. 伪集群部署:一台集群启动多个 Zookeeper 实例运行。

说一下 Zookeeper 的通知机制?

client 端会对某个 znode 创建一个 watcher 事件,当该 znode 发生变化时,这些 client 会收到 zk 的通知,而后 client 能够根据 znode 变化来作出业务上的改变等。

集群中为何要有主节点?

在分布式环境中,有些业务逻辑只须要集群中的某一台机器进行执行,其余的机器能够共享这个结果,这样能够大大减小重复计算,提升性能,因而就须要进行 leader 选举。

集群中有 3 台服务器,其中一个节点宕机,这个时候 Zookeeper 还可使用吗?

能够继续使用,单数服务器只要没超过一半的服务器宕机就能够继续使用。

集群规则为 2N+1 台,N >0,即最少须要 3 台。

说一下两阶段提交和三阶段提交的过程?分别有什么问题?

两阶段提交协议 2PC

1. 第一阶段(投票阶段):

(1)协调者节点向全部参与者节点询问是否能够执行提交操做(vote),并开始等待各参与者节点的响应;

(2)参与者节点执行询问发起为止的全部事务操做,并将Undo信息和Redo信息写入日志。

(3)各参与者节点响应协调者节点发起的询问。若是参与者节点的事务操做实际执行成功,则它返回一个”赞成”消息;若是参与者节点的事务操做实际执行失败,则它返回一个”停止”消息。

2. 第二阶段(提交执行阶段):

当协调者节点从全部参与者节点得到的相应消息都为”赞成”时:

(1)协调者节点向全部参与者节点发出”正式提交(commit)”的请求;

(2)参与者节点正式完成操做,并释放在整个事务期间内占用的资源;

(3)参与者节点向协调者节点发送”完成”消息;

(4)协调者节点受到全部参与者节点反馈的”完成”消息后,完成事务。

两阶段提交存在的问题:

1. 执行过程当中,全部参与节点都是事务阻塞型的。当参与者占有公共资源时,其余第三方节点访问公共资源不得不处于阻塞状态;

2. 参与者发生故障:协调者须要给每一个参与者额外指定超时机制,超时后整个事务失败;

3. 协调者发生故障:参与者会一直阻塞下去。须要额外的备机进行容错;

4. 二阶段没法解决的问题:协调者再发出 commit 消息以后宕机,而惟一接收到这条消息的参与者同时也宕机了。那么即便协调者经过选举协议产生了新的协调者,这条事务的状态也是不肯定的,没人知道事务是否被已经提交。

三阶段提交协议 3PC

与两阶段提交不一样的是,三阶段提交有两个改动点:

1. 引入超时机制。同时在协调者和参与者中都引入超时机制;

2. 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段以前各参与节点的状态是一致的。

也就是说,除了引入超时机制以外,3PC 把 2PC 的准备阶段再次一分为二,这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。

1. CanCommit 阶段

3PC 的 CanCommit 阶段其实和 2PC 的准备阶段很像。协调者向参与者发送 commit 请求,参与者若是能够提交就返回 Yes 响应,不然返回 No 响应。

(1)事务询问:协调者向参与者发送 CanCommit 请求。询问是否能够执行事务提交操做。而后开始等待参与者的响应。

(2)响应反馈:参与者接到 CanCommit 请求以后,正常状况下,若是其自身认为能够顺利执行事务,则返回 Yes 响应,并进入预备状态。不然反馈 No。

2. PreCommit 阶段

协调者根据参与者的反应状况来决定是否能够继续事务的 PreCommit 操做。根据响应状况,有如下两种可能:

假如协调者从全部的参与者得到的反馈都是 Yes 响应,那么就会执行事务的预执行。

(1)发送预提交请求:协调者向参与者发送 PreCommit 请求,并进入 Prepared 阶段。

(2)事务预提交:参与者接收到 PreCommit 请求后,会执行事务操做,并将 undo 和 redo 信息记录到事务日志中。

(3)响应反馈:若是参与者成功的执行了事务操做,则返回 ACK 响应,同时开始等待最终指令。

假若有任何一个参与者向协调者发送了 No 响应,或者等待超时以后,协调者都没有接到参与者的响应,那么就执行事务的中断。

(1)发送中断请求:协调者向全部参与者发送 abort 请求。

(2)中断事务:参与者收到来自协调者的 abort 请求以后(或超时以后,仍未收到协调者的请求),执行事务的中断。

3. doCommit 阶段

该阶段进行真正的事务提交,也能够分为如下两种状况。

3.1 执行提交

(1)发送提交请求:协调接收到参与者发送的 ACK 响应,那么他将从预提交状态进入到提交状态。并向全部参与者发送 doCommit 请求。

(2)事务提交:参与者接收到 doCommit 请求以后,执行正式的事务提交。并在完成事务提交以后释放全部事务资源。

(3)响应反馈:事务提交完以后,向协调者发送 ACK 响应。

(4)完成事务:协调者接收到全部参与者的 ACK 响应以后,完成事务。

3.2 中断事务

协调者没有接收到参与者发送的 ACK 响应(多是接受者发送的不是 ACK 响应,也可能响应超时),那么就会执行中断事务。

(1)发送中断请求:协调者向全部参与者发送 abort 请求。

(2)事务回滚:参与者接收到 abort 请求以后,利用其在阶段二记录的 undo 信息来执行事务的回滚操做,并在完成回滚以后释放全部的事务资源。

(3)反馈结果:参与者完成事务回滚以后,向协调者发送 ACK 消息。

(4)中断事务:协调者接收到参与者反馈的 ACK 消息以后,执行事务的中断。

三阶段提交的问题:

网络分区可能会带来问题。须要四阶段解决:四阶段直接调用远程服务的数据状态,肯定当前数据一致性的状况。

Zookeeper 宕机如何处理?

Zookeeper 自己也是集群,推荐配置很多于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时,其余节点会继续提供服务。

若是是一个 Follower 宕机,还有 2 台服务器提供访问,由于 Zookeeper 上的数据是有多个副本的,数据并不会丢失;若是是一个 Leader 宕机,Zookeeper 会选举出新的 Leader。

Zookeeper 集群的机制是只要超过半数的节点正常,集群就能正常提供服务。只有在 Zookeeper 节点挂得太多,只剩一半或不到一半节点能工做,集群才失效。因此:

3 个节点的 cluster 能够挂掉 1 个节点(leader 能够获得 2 票 > 1.5)

2 个节点的 cluster 就不能挂掉任何1个节点了(leader 能够获得 1 票 <= 1)

11. 说下四种类型的数据节点 Znode?

1. PERSISTENT:持久节点,除非手动删除,不然节点一直存在于 Zookeeper 上。

2. EPHEMERAL:临时节点,临时节点的生命周期与客户端会话绑定,一旦客户端会话失效(客户端与 Zookeeper链接断开不必定会话失效),那么这个客户端建立的全部临时节点都会被移除。

3. PERSISTENT_SEQUENTIAL:持久顺序节点,基本特性同持久节点,只是增长了顺序属性,节点名后边会追加一个由父节点维护的自增整型数字。

4. EPHEMERAL_SEQUENTIAL:临时顺序节点,基本特性同临时节点,增长了顺序属性,节点名后边会追加一个由父节点维护的自增整型数字。

Zookeeper 和 Dubbo 的关系?

Dubbo 的将注册中心进行抽象,是得它能够外接不一样的存储媒介给注册中心提供服务,有 ZooKeeper,Memcached,Redis 等。

引入了 ZooKeeper 做为存储媒介,也就把 ZooKeeper 的特性引进来。首先是负载均衡,单注册中心的承载能力是有限的,在流量达到必定程度的时 候就须要分流,负载均衡就是为了分流而存在的,一个 ZooKeeper 群配合相应的 Web 应用就能够很容易达到负载均衡;

资源同步,单单有负载均衡还不 够,节点之间的数据和资源须要同步,ZooKeeper 集群就自然具有有这样的功能;

命名服务,将树状结构用于维护全局的服务地址列表,服务提供者在启动 的时候,向 ZooKeeper 上的指定节点 /dubbo/${serviceName}/providers 目录下写入本身的 URL 地址,这个操做就完成了服务的发布。 其余特性还有 Mast 选举,分布式锁等。

面试完腾讯,总结了这12道Zookeeper面试题_分布式_02

面试完腾讯,总结了这12道Zookeeper面试题_分布式_03