JAVA面试——Zookeeper

本文涉及的产品
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: JAVA面试——Zookeeper

11.1.1. Zookeeper 概念

Zookeeper 是一个分布式协调服务,可用于服务发现,分布式锁,分布式领导选举,配置管理等。

Zookeeper 提供了一个类似于 Linux 文件系统的树形结构(可认为是轻量级的内存文件系统,但

只适合存少量信息,完全不适合存储大量文件或者大文件),同时提供了对于每个节点的监控与

通知机制。

11.1.1. Zookeeper 角色

Zookeeper 集群是一个基于主从复制的高可用集群,每个服务器承担如下三种角色中的一种

11.1.1.1. Leader

1. 一个 Zookeeper 集群同一时间只会有一个实际工作的 Leader,它会发起并维护与各 Follwer

及 Observer 间的心跳。

2. 所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器只要有超过

半数节点(不包括 observeer 节点)写入成功,该写请求就会被提交(类 2PC 协议)。

11.1.1.2. Follower

1. 一个 Zookeeper 集群可能同时存在多个 Follower,它会响应 Leader 的心跳,

2. Follower 可直接处理并返回客户端的读请求,同时会将写请求转发给 Leader 处理,

3. 并且负责在 Leader 处理写请求时对请求进行投票

11.1.1.3. Observer

角色与 Follower 类似,但是无投票权。Zookeeper 需保证高可用和强一致性,为了支持更多的客

户端,需要增加更多 Server;Server 增多,投票阶段延迟增大,影响性能引入 Observer,

Observer 不参与投票; Observers 接受客户端的连接,并将写请求转发给 leader 节点; 加入更

多 Observer 节点,提高伸缩性,同时不影响吞吐率。

image.png

11.1.1.1. ZAB 协议

事务编号 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 协议 4 阶段

Leader election(选举阶段-选出准 Leader

1. Leader election(选举阶段):节点在一开始都处于选举阶段,只要有一个节点得到超半数

节点的票数,它就可以当选准 leader。只有到达 广播阶段(broadcast) 准 leader 才会成

为真正的 leader。这一阶段的目的是就是为了选出一个准 leader,然后进入下一个阶段

Discovery(发现阶段-接受提议、生成 epoch、接受 epoch

2. Discovery(发现阶段):在这个阶段,followers 跟准 leader 进行通信,同步 followers

最近接收的事务提议。这个一阶段的主要目的是发现当前大多数节点接收的最新提议,并且

准 leader 生成新的 epoch,让 followers 接受,更新它们的 accepted Epoch

一个 follower 只会连接一个 leader,如果有一个节点 f 认为另一个 follower p 是 leader,f

在尝试连接 p 时会被拒绝,f 被拒绝之后,就会进入重新选举阶段

Synchronization(同步阶段-同步 follower 副本)

3. Synchronization(同步阶段):同步阶段主要是利用 leader 前一阶段获得的最新提议历史,

同步集群中所有的副本只有当 大多数节点都同步完成,准 leader 才会成为真正的 leader

follower 只会接收 zxid 比自己的 lastZxid 大的提议。

Broadcast(广播阶段-leader 消息广播)

4. Broadcast(广播阶段):到了这个阶段,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。

11.1.1.2. 投票机制

每个 sever 首先给自己投票然后用自己的选票和其他 sever 选票对比,权重大的胜出,使用权

重较大的更新自身选票箱。具体选举过程如下:

1. 每个 Server 启动以后都询问其它的 Server 它要投票给谁。对于其他 server 的询问,

server 每次根据自己的状态都回复自己推荐的 leader 的 id 和上一次处理事务的 zxid(系

统启动时每个 server 都会推荐自己)

2. 收到所有 Server 回复以后,就计算出 zxid 最大的哪个 Server,并将这个 Server 相关信

息设置成下一次要投票的 Server。

3. 计算这过程中获得票数最多的的 sever 为获胜者,如果获胜者的票数超过半数,则改

server 被选为 leader。否则,继续这个过程,直到 leader 被选举出来

4. leader 就会开始等待 server 连接

5. Follower 连接 leader,将最大的 zxid 发送给 leader

6. Leader 根据 follower 的 zxid 确定同步点,至此选举阶段完成。

7. 选举阶段完成 Leader 同步后通知 follower 已经成为 uptodate 状态

8. Follower 收到 uptodate 消息后,又可以重新接受 client 的请求进行服务了

目前有 5 台服务器,每台服务器均没有数据,它们的编号分别是 1,2,3,4,5,按编号依次启动,它们

的选择举过程如下:

1. 服务器 1 启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反

馈信息,服务器 1 的状态一直属于 Looking。

2. 服务器 2 启动,给自己投票,同时与之前启动的服务器 1 交换结果,由于服务器 2 的编号

大所以服务器 2 胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是

LOOKING。

3. 服务器 3 启动,给自己投票,同时与之前启动的服务器 1,2 交换信息,由于服务器 3 的编

号最大所以服务器 3 胜出,此时投票数正好大于半数,所以服务器 3 成为领导者,服务器

1,2 成为小弟。

4. 服务器 4 启动,给自己投票,同时与之前启动的服务器 1,2,3 交换信息,尽管服务器 4 的

编号大,但之前服务器 3 已经胜出,所以服务器 4 只能成为小弟。

5. 服务器 5 启动,后面的逻辑同服务器 4 成为小弟。

11.1.2. Zookeeper 工作原理(原子广播)

1. Zookeeper 的核心是原子广播,这个机制保证了各个 server 之间的同步。实现这个机制

的协议叫做 Zab 协议。Zab 协议有两种模式,它们分别是恢复模式和广播模式。

2. 当服务启动或者在领导者崩溃后,Zab 就进入了恢复模式,当领导者被选举出来,且大多

数 server 的完成了和 leader 的状态同步以后,恢复模式就结束了。

3. 状态同步保证了 leader 和 server 具有相同的系统状态

4. 旦 leader 已经和多数的 follower 进行了状态同步后,他就可以开始广播消息了,即进

入广播状态。这时候当一个 server 加入 zookeeper 服务中,它会在恢复模式下启动,发

现 leader,并和 leader 进行状态同步。待到同步结束,它也参与消息广播。Zookeeper

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

followers 支持。

5. 广播模式需要保证 proposal 被按顺序处理,因此 zk 采用了递增的事务 id 号(zxid)来保

证。所有的提议(proposal)都在被提出的时候加上了 zxid。

6. 实现中 zxid 是一个 64 为的数字,它高 32 位是 epoch 用来标识 leader 关系是否改变,

每次一个 leader 被选出来,它都会有一个新的 epoch。低 32 位是个递增计数。

7. 当 leader 崩溃或者 leader 失去大多数的 follower,这时候 zk 进入恢复模式,恢复模式

需要重新选举出一个新的 leader,让所有的 server 都恢复到一个正确的状态。

11.1.3. Znode 有四种形式的目录节点

1. PERSISTENT:持久的节点。

2. EPHEMERAL:暂时的节点。

3. PERSISTENT_SEQUENTIAL:持久化顺序编号目录节点。

4. EPHEMERAL_SEQUENTIAL:暂时化顺序编号目录节点。


相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
目录
相关文章
|
1月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
73 2
|
23天前
|
Java 程序员
Java社招面试题:& 和 && 的区别,HR的套路险些让我翻车!
小米,29岁程序员,分享了一次面试经历,详细解析了Java中&和&&的区别及应用场景,展示了扎实的基础知识和良好的应变能力,最终成功获得Offer。
62 14
|
1月前
|
存储 缓存 算法
面试官:单核 CPU 支持 Java 多线程吗?为什么?被问懵了!
本文介绍了多线程环境下的几个关键概念,包括时间片、超线程、上下文切换及其影响因素,以及线程调度的两种方式——抢占式调度和协同式调度。文章还讨论了减少上下文切换次数以提高多线程程序效率的方法,如无锁并发编程、使用CAS算法等,并提出了合理的线程数量配置策略,以平衡CPU利用率和线程切换开销。
面试官:单核 CPU 支持 Java 多线程吗?为什么?被问懵了!
|
1月前
|
存储 算法 Java
大厂面试高频:什么是自旋锁?Java 实现自旋锁的原理?
本文详解自旋锁的概念、优缺点、使用场景及Java实现。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:什么是自旋锁?Java 实现自旋锁的原理?
|
1月前
|
存储 缓存 Oracle
Java I/O流面试之道
NIO的出现在于提高IO的速度,它相比传统的输入/输出流速度更快。NIO通过管道Channel和缓冲器Buffer来处理数据,可以把管道当成一个矿藏,缓冲器就是矿藏里的卡车。程序通过管道里的缓冲器进行数据交互,而不直接处理数据。程序要么从缓冲器获取数据,要么输入数据到缓冲器。
Java I/O流面试之道
|
28天前
|
Java 编译器 程序员
Java面试高频题:用最优解法算出2乘以8!
本文探讨了面试中一个看似简单的数学问题——如何高效计算2×8。从直接使用乘法、位运算优化、编译器优化、加法实现到大整数场景下的处理,全面解析了不同方法的原理和适用场景,帮助读者深入理解计算效率优化的重要性。
32 6
|
1月前
|
存储 缓存 Java
大厂面试必看!Java基本数据类型和包装类的那些坑
本文介绍了Java中的基本数据类型和包装类,包括整数类型、浮点数类型、字符类型和布尔类型。详细讲解了每种类型的特性和应用场景,并探讨了包装类的引入原因、装箱与拆箱机制以及缓存机制。最后总结了面试中常见的相关考点,帮助读者更好地理解和应对面试中的问题。
59 4
|
1月前
|
存储 Java 程序员
Java基础的灵魂——Object类方法详解(社招面试不踩坑)
本文介绍了Java中`Object`类的几个重要方法,包括`toString`、`equals`、`hashCode`、`finalize`、`clone`、`getClass`、`notify`和`wait`。这些方法是面试中的常考点,掌握它们有助于理解Java对象的行为和实现多线程编程。作者通过具体示例和应用场景,详细解析了每个方法的作用和重写技巧,帮助读者更好地应对面试和技术开发。
121 4
|
2月前
|
存储 安全 算法
Java面试题之Java集合面试题 50道(带答案)
这篇文章提供了50道Java集合框架的面试题及其答案,涵盖了集合的基础知识、底层数据结构、不同集合类的特点和用法,以及一些高级主题如并发集合的使用。
120 1
Java面试题之Java集合面试题 50道(带答案)
|
2月前
|
存储 Java 程序员
Java面试加分点!一文读懂HashMap底层实现与扩容机制
本文详细解析了Java中经典的HashMap数据结构,包括其底层实现、扩容机制、put和查找过程、哈希函数以及JDK 1.7与1.8的差异。通过数组、链表和红黑树的组合,HashMap实现了高效的键值对存储与检索。文章还介绍了HashMap在不同版本中的优化,帮助读者更好地理解和应用这一重要工具。
68 5