大数据面试题 —— Zookeeper(1)

（2）在 main() 线程中创建 ZooKeeper 客户端，这时就会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）

（3）客户端通过 connet 线程将注册的监听事件发送给服务端

（4）在 ZooKeeper 的注册监听器列表中将注册的监听事件添加到列表中

（5）ZooKeeper 监听到有数据或路径的变化，就会将这个消息发送给 listener 线程

（6） 客户端 listener 线程内部调用 process() 方法做出相应处理

zookeeper集群的节点数为什么建议奇数台 ***

（1）因为 zookeeper 中只要有半数以上的机器正常工作，那么整个集群对外就是可用的。比如说如果有 2 个 zookeeper，那么只要 1 个死了 zookeeper 就不能用了，因为 1没有过半，那么 zookeeper 的死亡容忍度为 0，同理，如果有 3 个 zookeeper，如果死了 1个，还剩2个
正常，还是过半的，所以 zookeeper 的死亡容忍度为 1，我之前算过 4 个5 个 6 个等情况下的死亡容忍度，发现了一个规律，2n 和 2n-1 的容忍度是一样的，所以为了节约资源，就选择奇数台。

（2）防止因为集群脑裂造成集群用不了。比如有 4 个节点，脑裂为 2 个小集群，都为 2 个节点，这时候，不能满足半数以上的机器正常工作，因此集群就不可用了，那么当有 5 个节点的时候，脑裂为 2 个小集群，分别为2和 3，这时候 3 这个小集群仍然可以选举出 leader，因此集群还是可用的。

ZooKeeper 的部署方式有哪几种？集群中的角色有哪些？集群最少需要几台机器？规则是怎样的？

（1）部署方式

• 单机模式：将Zookeeper运行在单台机器上，仅供学习和开发使用；
• 集群模式：zookeeper运行在多台机器上，每台机器上都运行一个zookeeper实例；
• 伪分布式模式：仍然只有一台物理机器，但是该机器运行了多个Zookeeper实例。

（2）zookeeper有三种角色：

• 老大Leader(领导者）
• 老二Follower （跟随者）
• 老三Observer（观察者）。Observer 接受客户端连接，将写操作转给Leader，但Observer不参与投票（即不参加一致性协议的达成），只同步Leader节点的状态，Observer角色是为集群系统扩展而生的。Follower和Observer归类为Learner（学习者）

（3）集群最少需要机器数：3，集群规则为2N+1台，N>0

ZooKeeper 的常用命令

（1） ls：查看当前 znode 的子节点

（2）create：创建节点

（3）set：设置节点的值

（4） get：获取节点的值

（5） stat：查看节点的状态

（6） delete：删除节点

（7） deleteall：递归删除节点

Zookeeper目录结构

ZooKeeper的目录结构采用类似Unix文件系统的树形结构。ZooKeeper 目录结构由 ZNode 组成，每个ZNode 默认情况下最多可以存储 1MB 的数据。ZNode是ZooKeeper中的基本数据单元，可以用于存储配置信息、状态信息等。

ZooKeeper目录结构的根节点为/，所有的ZNode都是以根节点为基础进行构建的。每个ZNode的名称是唯一的，并且可以包含多个子节点，每个子节点都是一个独立的ZNode。ZNode可以是永久节点，也可以是临时节点。

在ZooKeeper目录结构中，常用的ZNode包括：

• /zookeeper：ZooKeeper的内部节点，用于存储ZooKeeper的配置信息和状态信息。
• /brokers：Kafka集群中所有的Broker信息存储在该节点下。
• /controller：Kafka集群中Controller的状态信息存储在该节点下。
• /consumers：Kafka中所有的消费者组信息存储在该节点下。
• /config：Kafka集群的配置信息存储在该节点下。
• /admin：Kafka中所有的管理员操作信息存储在该节点下。

简述什么是CAP理论，zookeeper满足CAP的哪两个 ***

分布式系统有三个指标：

• Consistency（一致性）
  • 用户在访问分布式系统中的任意节点，得到的数据必须一致。

• Availability（可用性）
  • 用户访问集群中任意的健康节点，必须能得到响应，而不是超时或拒绝。

• Paratition tolerance（分区容错性）
  • 分区：因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立的分区。
  • 容错：在集群出现分区时，整个系统也要持续对外提供服务。

分布式系统无法同时满足这三个指标，这个结论就是 CAP 理论。

Zookeeper 符合一致性、分区容错性。（CP）

Paxos 算法 ***

Paxos 算法：一种基于消息传递且具有高度容错性的一致性算法。

Paxos 算法解决的问题：如何快速正确的在一个分布式系统中对某个数据的值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性。

在一个 Paxos 系统中，首先将所有的节点划分为Proposer（提议者）、Accepter（接受者）和 Learner（学习者）。（注意每个节点都可以身兼数职）

一个完整的 Paxos 算法流程分为三个阶段：

• 准备阶段
  • Proposer 向多个 Accepter 发出 Propose 请求Promise（承诺）
  • Accepter 针对收到的Propose请求进行Promise（承诺）
• 接受阶段
  • Proposer 收到多个Accepter的Promise（承诺）后，向Accepter发出Propose
  • Accepter 针对收到的Propose请求进行Accept处理
• 学习阶段
  • Proposer将形成的决议发送给所有的 Learner

ZAB协议/Zookeeper怎么保证一致性的 ***

依赖了 ZAB 协议，ZAB 协议借鉴了 Paxos 算法，是专门为 ZooKeeper 设计的支持崩溃恢复的原子广播协议。Paxos 算法中采用多个Proposer 会存在竞争 Acceptor 的问题，ZooKeeper 设计为只有一个 Leader 负责处理外部的写事务请求，然后 Leader 将数据同步到其他 Follower 节点。即，ZooKeeper 只有一个 Leader 可以发起提议。

ZAB 协议包括两种基本的模式：消息广播（正常）、崩溃恢复（异常）。

这两个模式是相辅相成的，消息广播模式就是 Zookeeper 不出现任何问题，并且正常工作的模式，崩溃恢复看字面意思就是当 Zookeeper 出现故障时用于恢复的。

（1）消息广播

（2）崩溃恢复

ZooKeeper 使用的ZAB协议与Paxo算法的异同？

相同点：

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

不同点：

ZAB(ZooKeeper Atomic Broadcast) 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统。而 Paxos 算法与 ZAB 协议不同的是，Paxos 算法的发起者可以是一个或多个。当集群中的 Acceptor 服务器中的大多数可以执行会话请求后，提议者服务器只负责发送提交指令，事务的执行实际发生在 Acceptor 服务器。这与 ZooKeeper 服务器上事务的执行发生在 Leader 服务器上不同。Paxos 算法在数据同步阶段，是多台 Acceptor 服务器作为数据源同步给集群中的多台 Learner 服务器，而 ZooKeeper 则是单台 Leader 服务器作为数据源同步给集群中的其他角色服务器。

注意：ZAB是在Paxos的基础上改进和演变过来的。

分布式集群中为什么会有主节点

在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，于是就需要主节点。

节点挂掉的时候Zookeeper是如何发现的

ZooKeeper提供了一种心跳机制，即每个节点都会定期向其他节点发送心跳消息，如果一个节点超过一定时间没有收到其他节点的心跳消息，就会判定这个节点已经下线了。

Leader一旦选出，如何让集群中所有Follow获悉

心跳机制

Zookeeper下 服务器的工作状态有几种

ZooKeeper 服务器有四种工作状态：

• LOOKING：寻找 Leader 状态。当服务器处于该状态时，它会认为当前服务器没有 Leader，因此需要进入 Leader 选举状态。
• FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。
• LEADING：领导者状态。表明当前服务器角色是 Leader。
• OBSERVING：观察者状态。表明当前服务器角色是 Observer。

Zookeeper提供了什么

（1）文件系统
（2）通知机制

ZooKeeper是否会自动进行日志清理？

ZooKeeper 不会自动进行日志清理，需要运维人员进行日志清理

请说明 ZooKeeper 使用到的各个端口的作用？

（1）2888：Follower与Leader交换信息的端口

（2）3888：万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口

zookeeper 负载均衡和 nginx 负载均衡区别

zk的负载均衡是可以调控，nginx只是能调权重，其他需要可控的都需要自己写插件；但是nginx的吞吐量比zk大很多，应该说按业务选择用哪种方式。

什么是脑裂

脑裂通常会出现在集群环境中，当集群中出现故障（比如网络故障），分成了“两个集群”，这两个集群无法互相通信，此时就会让集群觉得Leader挂了，这时候就会出现两个Leader节点，这就是脑裂。

实际上Zookeeper集群中是不会出现脑裂问题的，而不会出现的原因就跟过半机制有关。有了过半机制，对于一个Zookeeper集群，要么没有Leader，要没只有1个Leader，这样就避免了脑裂问题。

ZooKeeper节点类型

（1）Znode有两种类型：

• 短暂：客户端和服务器端断开连接后，创建的节点自己删除
• 持久：客户端和服务器端断开连接后，创建的节点不删除

（2）Znode有四种形式的目录节点（默认是persistent ）

• 持久化目录节点：客户端与zookeeper断开连接后，该节点依旧存在
• 持久化顺序编号目录节点： 客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
• 临时目录节点： 客户端与zookeeper断开连接后，该节点被删除
• 临时顺序编号目录节点：客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

临时节点、永久节点用来作什么？

临时节点常用于实现分布式锁等功能，而永久节点则用于存储一些配置信息、元数据等。

能否为临时节点创建子节点

ZooKeeper 中不能为临时节点创建子节点，如果需要创建子节点，应该将要创建子节点的节点创建为永久性节点

是哪个进程在Zookeeper上注册临时节点

一般情况下，是客户端进程通过ZooKeeper的API在zk上注册临时节点。客户端注册的临时节点在客户端连接断开后会自动删除。

ZooKeeper对节点的watch监听是永久的吗

不是，一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。

为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，这太消耗性能了。在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。

客户端向服务端写数据流程

可以分为两种情况，一是将写入请求直接发送给 leader ，一是将写入请求发给 follower（该情况也会将写入请求转发给 leader）。

（1）客户端会向ZK集群中的一台机器server1发送写数据的请求。

（2）server1接收到请求后，马上会通知leader 有写数据的请求来了

（3）leader拿到请求后，进行广播，让集群每一台机器都准备要写数据

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

，马上会通知leader 有写数据的请求来了

（3）leader拿到请求后，进行广播，让集群每一台机器都准备要写数据

[外链图片转存中…(img-ysOZbS7E-1714192846179)]
[外链图片转存中…(img-fwKHU6BY-1714192846180)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！