首页 > 其他分享 >ZooKeeper 面试资料

ZooKeeper 面试资料

时间：2025-01-11 21:03:32浏览次数：3  
标签：Zookeeper ZooKeeper 节点 面试 集群 资料 Leader 客户端

1. 说说 Zookeeper 是什么？

ZooKeeper 的特点：维护、协调、管理、监控
特点：（分布式应用协调服务）

  1. 最终一致性：客户端看到的数据最终是一致的
  2. 可靠性：服务器保存了消息，那么它就一直都存在
  3. 实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据
  4. 独立性（等待无关）：不同客户端直接互不影响
  5. 原子性：更新要不成功要不失败，没有第三个状态

2. ZooKeeper 有哪些应用场景？

2.1. 数据发布与订阅

发布与订阅即所谓的配置管理，顾名思义就是将数据发布到 ZooKeeper 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用
数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的

配置信息一般有几个特点：

  1. 数据量小的 K V
  2. 数据内容在运行时会发生动态变化
  3. 集群机器共享，配置一致

ZooKeeper 采用的是推拉结合的方式

推：服务端会推给注册了监控节点的客户端 Watcher 事件通知

拉：客户端获得通知后，然后主动到服务端拉取最新的数据

2.2. 分布式统一命名服务

命名服务是指通过指定的名字来获取资源或者服务的地址，利用ZooKeeper创建一个全局的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等

统一命名服务的命名结构图如下所示：

  1. 在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。类似于域名与IP之间对应关系，IP不容易记住，而域名容易记住。通过名称来获取资源或服务的地址，提供者等信息
  2. 按照层次结构组织服务/应用名称。可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类

2.3. 集群管理

所谓集群管理就是：是否有机器退出，加入，选举master；

集群管理主要指集群监控和集群控制两个方面。前者侧重于集群运行时的状态的收集，后者则是对集群进行操作与控制。开发和运维中，面对集群，经常有如下需求：

  1. 希望知道集群中究竟有多少机器在工作
  2. 对集群中的每台机器的运行时状态进行数据收集
  3. 对集群中机器进行上下线的操作
  4. 集群管理结构图如下所示：

  1. 分布式环境中，实时掌握每个节点的状态很必要，可根据节点实时状态做出一些调整
  2. 可交由 ZooKeeper 实现，可将节点信息写入ZooKeeper上的一个Znode，监听这个Znode 可获取它的实时状态变化
  3. 典型应用
    1. master 状态监控与选举
    2. 利用 ZooKeeper 的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功

2.4. 分布式通知与协调

分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态

  1. NameNode 需知道各个 DataNode 的状态
  2. JobTracker 需知道各个 TaskTracker 的状态
  3. 心跳检测机制可通过 ZooKeeper 来实现
  4. 信息推送可由 ZooKeeper 来实现，ZooKeeper 相当于一个发布/订阅系统
     

2.5. 分布式锁

处于不同节点上不同的服务，它们可能需要顺序的访问一些资源，这里需要一把分布式的锁；分布式锁具有以下特性：写锁、读锁、时序锁

  1. 写锁：在 zk 上创建的一个临时的无编号的节点。由于是无序编号，在创建时不会自动编号，导致只能客户端有一个客户端得到锁，然后进行写入
  2. 读锁：在 zk 上创建一个临时的有编号的节点，这样即使下次有客户端加入是同时创建相同的节点时，他也会自动编号，也可以获得锁对象，然后对其进行读取
  3. 时序锁：在 zk 上创建的一个临时的有编号的节点根据编号的大小控制锁
     

2.6. 分布式队列

分布式队列分为两种：

  1. 当队列的成员都聚齐时这个队列才可用，否则一直等所有成员到达，这是同步队列
    1. 一个job由多个task组成，只有所有任务完成后，job才运行完成
    2. 可为 job 创建一个 /job 目录，然后在该目录下，为每个完成的 task 创建一个临时的 Znode，一旦临时节点数目达到 task 总数，则表明 job 运行完成
  1. 队列按照 FIFO 方式进行入队和出队操作，例如实现生产者和消费者模型

3. 说说Zookeeper的工作原理？

Zookeeper的核心是原子广播，这个机制保证了各个 Server 之间的同步。实现这个机制的协议叫 ZAB协议；有两种模式，分别是恢复模式(选主)和 广播模式(同步)。ZAB协议是Zookeeper 的原子广播。Zookeeper 是通过 ZAB 协议来保证分布式事务的最终一致性。ZAB 协议要求每个 Leader 都要经历三个阶段：发现，同步，广播

当服务启动或者在领导者崩溃后，ZAB就进入了恢复模式(选主)，当领导者被选举出来，且大多数 Server 完成了和 Leader 的状态同步以后，恢复模式就结束了。状态同步保证了 Leader 和 Server 具有相同的系统状态

为了事务的顺序一致性，zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议（proposal）都在被提出时加上了zxid。实现中 zxid 是一个64位的数字，它高32位是 epoch 用来标识 Leader 关系是否改变，每次一个 Leader 被选出来，它都会有一个新的 epoch，标识当前属于那个 Leader 的统治时期。低32位用于递增计数

epoch：可以理解为皇帝的年号，当新的皇帝 Leader 产生后，将有一个新的 epoch 年号

每个 Server 在工作过程中有四种状态：

LOOKING：当前 Server 不知道 Leader 是谁，正在搜寻

LEADING：当前 Server 即为选举出来的 Leader

FOLLOWING： Leader 已经选举出来，当前 Server 与之同步

OBSERVING：观察者状态；表明当前服务器角色是 ObServere

4. 请描述一下 Zookeeper 的通知机制是什么？

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

大致分为三个步骤：

  1. 客户端注册 Watcher
    1. 调用 getData、getChildren、exist 三个 API ，传入Watcher 对象
    2. 标记请求 request ，封装 Watcher 到 WatchRegistration
    3. 封装成 Packet 对象，向服务端发送 request
    4. 服务端将 Watcher 注册到 ZKWatcherManager （监听列表）中进行管理
    5. 请求返回，完成注册
  1. 服务端处理 Watcher
    1. 服务端接收 Watcher 并存储
    2. Watcher 触发
    3. 调用 process 方法来触发 Watcher
  1. 客户端回调 Watcher
    1. 客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调 Watcher
    2. 客户端的 Watcher 机制同样是一次性的，一旦被触发，该 Watcher 就失效

5. Zookeeper 对节点的 watch 监听通知是永久的吗？

不是，是一次性的监听通知。无论是服务端还是客户端，一旦一个 Watcher 被触发， Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大

6. Zookeeper 集群中有哪些角色？

集群中最少需要 3 台，或者保证 2N + 1 台，即奇数

为什么保证奇数？主要是为了选举算法

7. Zookeeper 集群中是怎样选举 Leader 的？

选举 Leader 的流程：

开始投票 -> 节点状态变成 LOOKING -> 每个节点选自己-> 收到票进行 PK -> sid 大的获胜 -> 更新选票 -> 再次投票 -> 统计选票，选票过半数选举结果 -> 节点状态更新为自己的角色状态

当 Leader 崩溃了，或者失去了大多数的Follower，这时候 Zookeeper 就进入恢复模式，恢复模式需要重新选举出一个新的 Leader ，让所有的 Server 都恢复到一个状态LOOKING ；Zookeeper 有两种选举算法：基于 basic paxos 实现和基于 fast paxos 实现。默认为 fast paxos

8. Zookeeper 是如何保证事务的顺序一致性的呢？

Zookeeper 采用了递增的事务 id 来识别，所有的 proposal 都在被提出的时候加上了zxid 。 zxid 实际上是一个 64 位数字。高 32 位是 epoch 用来标识 Leader 是否发生了改变，如果有新的 Leader 产生出来， epoch 会自增。低 32 位用来递增计数

当产生新的 proposal 时，会依据数据库的两阶段过程，首先会向其他的 Server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行

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

Leader 服务器会和每一个 Follower/ObServere 服务器都建立 TCP 连接，同时为每个Follower/ObServere 都创建一个叫做 LearnerHandler 的实体。LearnerHandler 主要负责 Leader 和 Follower/ObServer 之间的网络通讯，包括数据同步，请求转发和 proposal 提议的投票等

Leader 服务器保存了所有 Follower/ObServer 的 LearnerHandler

10. ZooKeeper 分布式锁怎么实现的？

如果有 客户端1, 客户端2 等N个客户端争抢一个 Zookeeper 分布式锁；大致如下：

  1. 大家都是上来直接创建一个锁节点下的一个接一个的临时有序节点
  2. 如果自己不是第一个节点，就对自己上一个节点加监听器
  3. 只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制

使用临时有序的节点的用意是，如果某个客户端创建临时顺序节点之后，宕机了也没关系，Zookeeper 感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队

本地锁，可以用 JDK 实现

但是分布式锁就必须要用到分布式的组件，比如 ZooKeeper (CP)和 Redis(AP)

注意事项：

  1. 死锁问题：锁不能因为意外就变成死锁，所以要用 ZK 的临时节点，客户端连接失效了，锁就自动释放了
  2. 锁等待问题：锁有排队的需求，所以要 ZK 的顺序节点
  3. 锁管理问题：一个使用释放了锁，需要通知其他使用者，所以需要用到监听

监听的羊群效应：比如有 1000 个锁竞争者，锁释放后1000 个竞争者就得到了通知，然后进行判断，最终序号最小的那个竞争者拿到了锁。其它 999 个竞争者重新注册监听。这就是羊群效应，出点事，就会惊动整个羊群。应该每个竞争者只监听自己前面的那个节点。比如 2 号释放了锁，那么只有 3 号得到了通知

11. 了解Zookeeper的系统架构吗？

ZooKeeper 的架构图：

  1. ZooKeeper 分为服务器端和客户端，客户端可以连接到整个 ZooKeeper 服务的任意服务器上（除非 Leader 参数被显式设置， Leader 不允许接受客户端连接）
  2. 客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断，客户端将自动尝试连接到另外的ZooKeeper 服务器。客户端第一次连接到 ZooKeeper服务时，接受这个连接的 ZooKeeper 服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立
  3. 上图中每一个 Server 代表一个安装 Zookeeper 服务的机器，即是整个提供Zookeeper服务的集群（或者是由伪集群组成）
  4. 组成ZooKeeper服务的服务器必须彼此了解。它们维护内存中的状态图像，以及持久存储中的事务日志和快照， 只要超过半数服务器可用，ZooKeeper服务就可用
  5. ZooKeeper 启动时，将从实例中选举一个Leader，Leader 负责处理数据更新等操作，一个更新操作成功的标志是当且仅当大多数 Server 在内存中成功修改数据；每个 Server 在内存中存储了一份数据
  6. Zookeeper是可以集群复制的，集群间通过ZAB协议来保持数据的一致性；

  1. ZAB 协议包含两个阶段： Leader election 阶段和 Atomic Brodcast 阶段
    1. 集群中将选举出一个 Leader ，其他的机器则称为 follower，所有的写操作都被传送给 Leader ，并通过 brodcast 将所有的更新告诉给 follower
    2. 当 Leader 崩溃或者 Leader 失去大多数的follower时，需要重新选举出一个新的 Leader ，让所有的服务器都恢复到一个正确的状态
    3. 当 Leader 被选举出来，且大多数服务器完成了 和 Leader 的状态同步后，leadder election 的过程就结束了，就将会进入到 Atomic brodcast 的过程
    4. Atomic Brodcast同步 Leader 和follower之间的信息，保证Leader和follower具有形同的系统状态

12. 你熟悉Zookeeper节点ZNode和相关属性吗？

12.1. 节点有哪些类型？

Znode两种类型 ：

持久的（persistent）：客户端和服务器端断开连接后，创建的节点不删除（默认）

临时的（ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除

Znode有四种形式 ：

1、持久化目录节点：客户端与Zookeeper断开连接后，该节点依旧存在

2、持久化顺序编号目录节点：客户端与Zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号：

3、临时目录节点：客户端与Zookeeper断开连接后，该节点被删除

4、临时顺序编号目录节点：客户端与Zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

「注意」：创建ZNode时设置顺序标识，ZNode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护

12.2. 节点属性有哪些

一个 Znode 节点不仅可以存储数据，还有一些其他特别的属性

接下来我们创建一个 /test 节点分析一下它各个属性的含义

Plaintext
[zk: localhost:2181(CONNECTED) 6] get /test
456
cZxid = 0x59ac 创建节点的事务的 ID
ctime = Mon Mar 30 15:20:08 CST 2020 创建节点的时间
mZxid = 0x59ad 最新修改节点事务 ID
mtime = Mon Mar 30 15:22:25 CST 2020 最新修改节点的时间
pZxid = 0x59ac 当前节点的父级节点事务 ID
cversion = 0 创建当前节点的子节点版本号（修改+1）
dataVersion = 2 当前节点的版本号（每修改一次+1递增）
aclVersion = 0 当前节点权限版本号（修改+1）
ephemeralOwner = 0x0 临时节点标示，当前节点如果是临时节点，则存储的创建者的会话id(sessionId)，如果不是，那么值=0
dataLength = 3 当前节点存储的数据长度
numChildren = 0 当前节点的子节点的数量

13. 为什么 Zookeeper 集群的数目，一般为奇数个？

首先需要明确zookeeper选举的规则：

Leader 选举，要求可用节点数量 > 总节点数量 / 2

Zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；同理，要是有3个zk，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；

同理：

2->0；两个zookeeper，最多0个zookeeper可以不可用

3->1；三个zookeeper，最多1个zookeeper可以不可用

4->1；四个zookeeper，最多1个zookeeper可以不可用

5->2；五个zookeeper，最多2个zookeeper可以不可用

6->2；两个zookeeper，最多0个zookeeper可以不可用

....

会发现一个规律，2n 和 2n-1的容忍度是一样的，都是n-1，所以为了更加高效，何必增加那一个不必要的zookeeper呢，节省机器资源；zookeeper的选举策略也是需要半数以上的节点同意才能当选 Leader ，如果是偶数节点可能导致票数相同的情况

14. 知道Zookeeper监听器的原理吗

  1. 创建一个 main 线程
  2. 在 main 线程中创建两个线程，一个负责网络连接通信，一个负责监听
  3. 通过 connect 网络连接通信线程将注册的监听事件发送给Zookeeper
  4. 将注册的监听事件添加到 Zookeeper 的注册监听器列表中
  5. zk 监听到有数据或路径发生变化时，把这条消息发送给 Listener 线程
  6. Listener 线程内部调用 process() 方法

15. 说说 Zookeeper 的 CAP 问题上做的取舍？

一致性 C：Zookeeper 是强一致性系统，为了保证较强的可用性，"一半以上成功即成功"的数据同步方式可能会导致部分节点的数据不一致。所以 Zookeeper 还提供了 sync( ) 操作来做所有节点的数据同步，这就关于 C 和 A 的选择问题交给了用户，因为使用 sync( )势必会延长同步时间，可用性会有一些损失

可用性 A：Zookeeper 数据存储在内存中，且各个节点都可以相应读请求，具有好的响应性能。Zookeeper 保证了数据总是可用的，没有锁。并且有一大半的节点所拥有的数据是最新的
分区容忍性 P：Follower 节点过多会导致增大数据同步的延时。同时选举过程的收敛速度会变慢，可用性降低。Zookeeper 通过引入 obServer 节点缓解了这个问题，增加 obServer 节点后集群可接受 client 请求的节点多了，而且 obServer 不参与投票，可以提高可用性和扩展性，但是节点多数据同步总归是个问题，所以一致性会有所降低

16. 说说 Zookeeper 中的脑裂？

服务器节点之间的通信出现问题，感觉没有master，会进行重新选举 master，这就是脑裂问题，对于 Zookeeper 来说到底是根据一个什么样的情况来判断节点宕机了？

在分布式系统中这些都是有监控者来判断的，但是监控者也很难判定其他的节点的状态，可靠的途径就是心跳，Zookeeper也是使用心跳来判断客户端是否仍然活着。

使用ZooKeeper来做 Leader HA基本都是同样的方式：每个节点都尝试注册一个象征 Leader 的临时节点，其他没有注册成功的则成为follower，并且通过 watch 机制监控着 Leader 所创建的临时节点，Zookeeper通过内部心跳机制来确定 Leader 的状态，一旦 Leader 出现意外 Zookeeper 能很快获悉并且通知其他的 follower，其他 follower 在之后作出相关反应，这样就完成了一个切换，这种模式也是比较通用的模式，基本大部分都是这样实现的

因为心跳出现超时可能是 Leader 挂了，但是也可能是zookeeper节点之间网络出现了问题，导致 Leader 假死的情况， Leader 其实并未死掉，但是与ZooKeeper之间的网络出现问题导致Zookeeper认为其挂掉了然后通知其他节点进行切换，这样 follower 中就有一个成为了 Leader ，但是原本的 Leader 并未死掉，这时候 client 也获得 Leader 切换的消息，但是仍然会有一些延时，zookeeper 需要通讯需要一个一个通知，这时候整个系统就很混乱，可能有一部分 client 已经通知到了连接到新 Leader 上了，有的 client 仍然连接在老的 Leader 上，如果同时有两个 client 需要对 Leader 的同一个数据更新，并且刚好这两个 client 此刻分别连接在新老的 Leader 上，就会出现很严重问题

假死：由于心跳超时（网络原因导致的）认为 Leader 宕机，但其实Leader还活着

脑裂：由于假死会发起新的 Leader 选举，选举出一个新的 Leader ，但旧的 Leader 网络又通了，导致出现了两个 Leader ，有的客户端连接到老的 Leader ，而有的客户端则连接到新的 Leader

17. Zookeeper 脑裂是什么原因导致的？

主要原因是 zk 集群和 zk client 判断超时并不能做到完全同步，也就是说可能一前一后，如果是集群先于 client 发现，那就会出现脑裂

同时在发现并切换 Leader 后通知各个 client 也有先后快慢。一般出现这种情况的几率很小，需要 Leader 节点与 zk 集群网络断开，但是与其他集群角色之间的网络没有问题，还要满足上面那些情况，但是一旦出现就会引起很严重的后果，数据不一致

18. Zookeeper 是如何解决脑裂问题的？

要解决 Split-Brain 脑裂的问题，一般有下面几种种方法：

  1. Quorums (法定人数) 方式：比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个leader，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的。这是 zk 防止"脑裂"默认采用的方法
  2. Redundant communications (冗余通信)方式：集群中采用多种通信方式，防止一种通信方式失效导致集群中的节点无法通信
  3. Fencing (共享资源) 方式：比如能看到共享资源就表示在集群中，能够获得共享资源的锁的就是 Leader，看不到共享资源的，就不在集群中。要想避免 zk"脑裂"情况其实也很简单，follower节点切换的时候不再检查到老的 Leader 节点出现问题后马上切换，而是在休眠一段足够的时间，确保老的 Leader 已经获知变更并且做了相关的shutdown 清理工作了，然后再注册成为master 就能避免这类问题了，这个休眠时间一般定义为与 zk 定义的超时时间就够了，但是这段时间内系统可能是不可用的，但是相对于数据不一致的后果来说还是值得的

  1. zk 默认采用了 Quorums 这种方式来防止"脑裂"现象。即只有集群中超过半数节点投票才能选举出 Leader 。这样的方式可以确保 Leader 的唯一性，要么选出唯一的一个 Leader，要么选举失败。在 zk 中Quorums作用如下：集群中最少的节点数用来选举 Leader 保证集群可用。通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。一旦这些节点保存了该数据，客户端将被通知已经安全保存了，可以继续其他任务。而集群中剩余的节点将会最终也保存了该数据；；；假设某个 Leader 假死，其余的 followers 选举出了一个新的 Leader 。这时，旧的 Leader 复活并且仍然认为自己是 Leader ，这个时候它向其他followers发出写请求也是会被拒绝的。因为每当新 Leader 产生时，会生成一个epoch标号(标识当前属于那个 Leader 的统治时期)，这个epoch是递增的，followers如果确认了新的 Leader 存在，知道其epoch，就会拒绝epoch小于现任 Leader epoch的所有请求。那有没有follower不知道新的 Leader 存在呢，有可能，但肯定不是大多数，否则新 Leader 无法产生。Zookeeper的写也遵循quorum机制，因此，得不到大多数支持的写是无效的，旧 Leader 即使各种认为自己是 Leader ，依然没有什么作用。zookeeper除了可以采用上面默认的Quorums方式来避免出现"脑裂"，还可以可采用下面的预防措施：
  2. 添加冗余的心跳线，例如双线条线，尽量减少“裂脑”发生机会
  3. 启用磁盘锁。正在服务一方锁住共享磁盘，"裂脑"发生时，让对方完全"抢不走"共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动"解锁"，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了"智能"锁。即正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了
  4. 设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下 参考IP，不通则表明断点就出在本端，不仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。

19. Zookeeper选举中投票信息的五元组是什么？

  1. Leader ：被选举的 Leader 的 SID
  2. Zxid：被选举的 Leader 的事务 ID
  3. Sid：当前服务器的 SID
  4. electionEpoch：当前投票的轮次
  5. peerEpoch：当前服务器的 epoch

epoch > Zxid > Sid

epoch，Zxid 都可能一致，但是 Sid 一定不一样，这样两张选票一定会 PK 出结果

20. 讲解一下 ZooKeeper 的持久化机制

  1. 什么是持久化？

数据存到磁盘或者文件当中。机器重启后，数据不会丢失

  1. ZooKeeper 的持久化

SnapShot 快照记录内存中的全量数据；

TxnLog 增量事务日志，记录每一条增删改记录；

  1. 为什么持久化这么麻烦，一个不可用吗？

快照的缺点，文件太大，而且快照文件不会是最新的数据

增量事务日志的缺点，运行时间了，日志太多了，加载太慢

二者结合最好。快照模式：将 ZooKeeper 内存中以 DataTree 数据结构存储的数据定期存储到磁盘中。由于快照文件是定期对数据的全量备份，所以快照文件中数据通常不是最新的。见图片：

21. 在Zookeeper中Zxid和Epoch是什么，有什么作用？

  1. Zxid：也就是事务 id，为了保证事务的顺序一致性，zk 采用了递增的事务zxid来标识事务。proposal 都会加上了zxid。zxid 是64位的数字，它高 32 位是 epoch 用来标识朝代变化，比如每次选举 Epoch 都会加改变；低 32 位用于递增计数
  2. Epoch：可以理解为当前集群所处的年代或者周期，每个leader就像皇帝，都有自己的年号，所以每次改朝换代；leader变更之后，都会在前一个年代的基础上加 1。这样就算旧的 Leader 崩溃恢复之后，也没有人听它的了，因为 Follower 只听从当前年代的 Leader 的命令

22. ZooKeeper 负载均衡和 Nginx 负载均衡有什么区别？

  1. ZooKeeper：
  • 不存在单点问题，ZAB 机制保证单点故障可重新选举一个 Leader
  • 只负责服务的注册与发现，不负责转发，减少一次数据交换
  • 需要自己实现相应的负载均衡算法
  1. nginx：
  • 存在单点问题，单点负载高数据量大，需要通过 KeepAlived 辅助实现高可用
  • 每次负载，都充当一次中间人转发角色，本身是个反向代理服务器
  • 自带负载均衡算法

23. 说说ZooKeeper 的序列化

序列化：

  • 内存数据，保存到硬盘需要序列化。
  • 内存数据，通过网络传输到其他节点，需要序列化。

ZK 使用的序列化协议是 Jute，Jute 提供了 Record 接口。接口提供了两个方法：

  • serialize 序列化方法
  • deserialize 反序列化方法

如果要序列化，在这两个方法中存入到流对象中即可。

24. 说说 Zookeeper 中的 ACL 权限控制机制

ACL（Access Control List）访问控制列表包括三个方面：

24.1. 权限模式（Scheme）（略）

  1. IP：从 IP 地址粒度进行权限控制
  2. Digest：最常用，用类似于 username：password 的权限标识来进行权限配置，便于区分不同应用来进行权限控制
  3. World：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标识“world:anyone”
  4. Super：超级用户

24.2. 授权对象

授权对象指的是权限赋予的用户或一个指定实体，例如 IP 地址或是机器灯

24.3. 权限 Permission

CREATE，DELETE，READ，WRITE，ADMIN

  1. CREATE：数据节点创建权限，允许授权对象在该 Znode 下创建子节点
  2. DELETE：子节点删除权限，允许授权对象删除该数据节点的子节点
  3. READ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容，或访问并读取子节点列表等
  4. WRITE：数据节点更新权限，允许授权对象对该数据节点进行更新操作
  5. ADMIN：数据节点管理权限，允许授权对象对该数据节点进行 ACL 相关设置操作

25. Zookeeper 有哪几种几种部署模式？

ZK 有三种部署模式：

  1. 单机部署：一台集群上运行
  2. 集群部署：多台集群运行
  3. 伪集群部署：一台集群启动多个 Zookeeper 实例运行

26. 描述一下 ZAB 协议（原子广播协议）

ZAB 协议有两种模式： Leader 节点崩溃了如何恢复 和 消息如何广播到所有节点

整个zk集群没有leader节点的时候，属于崩溃的情况。比如集群启动刚刚启动，这时节点们互相不认识。比如运作leader节点宕机或者网络问题，其他节点ping不通leader，这时就需要 ZAB 中的节点崩溃协议，所有节点进入选举模式，选举出新的 Leader 。整个选举过程就是通过广播来实现的；选举成功后，一切都需要以 leader 的数据为准，那么就需要进行数据同步了...

27. ZAB 和 Paxos 算法的联系与区别？

相同点：

  1. 两者都存在类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行
  2. Leader 进程都会等待超过半数的follower做出正确的反馈后，才会将提案进行提交
  3. ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader 周期

不同点：

ZAB 用来构建高可用的分布式数据主备系统，Paxos 用来构建分布式一致性状态机系统

28. Zookeeper集群支持动态添加机器吗？

其实就是水平扩容了，zk 在这方面不太好。两种方式：

  1. 全部重启：关闭所有 zk 服务，修改配置之后启动。不影响之前客户端的会话
  2. 逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。3.5 版本开始支持动态扩容

标签：Zookeeper,ZooKeeper,节点,面试,集群,资料,Leader,客户端
From： https://blog.csdn.net/weixin_44374928/article/details/145019452

相关文章

  • WiFi+4G摄像头拍照图传模块(夜视2K高清1080P)-关于参考资料,程序移植,新建调用自己的
    <p><iframename="ifd"src="https://mnifdv.cn/resource/cnblogs/product/audioCamera.html"frameborder="0"scrolling="auto"width="100%"height="1500"></iframe></p> 关于参考资料......
  • #【鸿蒙面试题】分享几个不怎么注意到的面试题
    Navigation中哪个生命周期可以获取到页面栈，怎么获取的？Navigation的onReady生命周期中可以获取到页面栈，通过回调函数获取的。.onReady((context:NavDestinationContext)=>{context.pathStack})鸿蒙的后台任务类型有哪些短时任务：实时性要求较高的任务，比如状态保存长时任......
  • 代码随想录算法训练营第4天 | 24. 两两交换链表中的节点，19.删除链表的倒数第N个节点，面
    一、刷题部分1.124.两两交换链表中的节点原文链接：代码随想录题目链接：24.两两交换链表中的节点-力扣（LeetCode）1.1.1题目描述给你一个链表，两两交换其中相邻的节点，并返回交换后链表的头节点。你必须在不修改节点内部的值的情况下完成本题（即，只能进行节点交换）。示例1：输......
  • 整理字节腾讯阿里等数百份大厂面经：Java多线程和线程安全最高频面试题及参考答案
    多线程（并发编程）和线程安全几乎是每场面试必问的问题，下面面试题是从字节跳动、腾讯和阿里等几百份的面试题整理的，面试时出现频率很高的。目录Java对锁的优化机制是怎样的？无锁是怎么回事？CAS锁原理是什么？它跟CPU底层的指令有关系吗？ABA问题是怎么回事？说说synchronized和......
  • 【大厂面试AI算法题中的知识点】方向涉及：ML/DL/CV/NLP/大数据...本篇介绍自动驾驶检测
    【大厂面试AI算法题中的知识点】方向涉及：ML/DL/CV/NLP/大数据…本篇介绍自动驾驶检测模型如何针对cornercase优化？【大厂面试AI算法题中的知识点】方向涉及：ML/DL/CV/NLP/大数据…本篇介绍自动驾驶检测模型如何针对cornercase优化？文章目录【大厂面试AI算法题中的知......
  • 全网网络安全面试题大全（整理版）稳了
    前言随着国家政策的扶持，网络安全行业也越来越为大众所熟知，想要进入到网络安全行业的人也越来越多。为了拿到心仪的Offer之外，除了学好网络安全知识以外，还要应对好企业的面试。一、web安全岗面试题1.1、什么是 SQL注入攻击？如何防止SQL注入攻击？SQL注入攻击是指攻击者......
  • 招行面试：亿级秒杀，超卖问题+少卖问题，如何解决？（图解+秒懂+史上最全）
    本文原文链接文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录博客园版为您奉上珍贵的学习资源：免费赠送:《尼恩Java面试宝典》持续更新+史上最全+面试必备2000页+面试必备+大厂必备+涨薪必备免费赠送:《尼恩技术圣经+高并发系列PDF》，帮你实现技术自由，完......
  • 【面试题】简单聊一下什么是云原生、什么是k8s、容器，容器与虚机相比优势
    云原生（CloudNative）定义：云原生是一种构建和运行应用程序的方法，旨在充分利用云计算的优势。它涵盖了一系列技术和理念，包括容器化、微服务架构、自动化部署与管理等。特点：云原生应用程序被设计为可弹性扩展、容错性强，能够快速响应变化。例如，一个电商平台的云原生应用可以根据......
  • 销售部门的机密资料太多怎么防泄密？
    销售部门通常会处理大量的客户信息、销售数据和业务策略等机密资料，防止这些资料的泄密对于保护公司的商业利益至关重要。以下是一些基于搜索结果的建议，可以帮助销售部门防止机密资料的泄密： 1、采用专业的加密软件使用具备强大加密能力的软件，如“上邦安全”软件，它基于高级......
  • 鸿蒙面试 2025-01-10
    写了鉴权工具，你在项目中申请了那些权限？（常用权限）位置权限 ：ohos.permission.LOCATION_IN_BACKGROUND：允许应用在后台访问位置信息。ohos.permission.LOCATION：允许应用访问精确的位置信息。ohos.permission.APPROXIMATELY_LOCATION：允许应用访问大致的位置信息。相机权限 ：......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99