zookeeper面试题

1. 什么是zookeeper

zookeeper是一个开源的 分布式协调服务 。他是一个为分布式应用提供一致性服务的软件,分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

Zookeeper保证了如下分布式一致性特性:

  1. 顺序一致性
  2. 原子性
  3. 单一视图
  4. 可靠性
  5. 实时性(最终一致性)

2. Zookeeper都有哪些功能

  • 集群管理 :监控节点存活状态、运行请求等。
    主节点选举 :主节点挂掉了之后,可以从备用的节点开始新一轮选主,主节点选举说的就是这个选举过程,使用zookeeper可以协助完成这个过程。
    分布式锁 :Zookeeper提供两种锁:独占锁、共享锁。独占锁即一次只能有一个线程使用资源,共享锁是读锁共享,读写互斥,即可以有多个线程同时读同一个资源,如果要使用写锁也只能有一个线程使用。Zookeeper可以对分布式锁进行控制。
    命名服务:在分布式系统中,通过使用命名服务,客户端应用能够指定名字来获取资源或服务地址,提供者等信息。

3. Zookeeper的工作流程

首先客户端连接Zookeeper集群中的任何一个节点,可以是leader节点,也可以是follower节点,一旦连接,节点会给客户端分配会话ID,并向客户端发送确认,如果客户端收到确认,那么连接成功,客户端会规律性的给Zookeeper发送心跳包,确保连接没有断开。

  • 客户端向zookeeper从节点发送读请求,节点会直接从数据库中找到这个节点的数据然后返回。
  • 客户端向zookeeper从节点发送写请求,节点会将znode路径和数据转发到leader节点,leader会将写请求转化为proposal提案,并且分配一个事务ID zxid,将这个proposal放到每个节点的队列中去,然后会根据先进先出的策略,将消息发送给从节点,从节点收到后会将事务写入磁盘中,然后返回ACK响应给主节点,当主节点接收到半数以上的从节点的ACK响应后,主节点会认为这个事务提交成功,完成这个事务提交,同时给所有从节点发送commit消息,从节点收到消息后,将这个事务提交。

3. Zookeeper工作原理

Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做ZAB协议。ZAB协议有两种模式,分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,ZAB就进入了恢复模式,当领导者被选举出来,且大多数server完成了和leader状态同步以后,恢复模式就结束了。状态同步,保证了leader和Server具有相同的系统状态。

4.什么是Zookeeper的文件系统

Zookeeper提供了一个多层级的节点命名空间(节点称为znode)。 与文件系统不同的是,这些节点都可以设置关联的数据,而文件系统只有文件节点可以存放数据而目录节点不行。 Zookeeper为了保证高吞吐和低延迟,在内存中维护了这个树状的目录结构,这种特性使得Zookeeper不能用于存放大量的数据,每个节点的存放数据上限为1M。

5. 集群中为什么要有主节点

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

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

Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做ZAB协议。ZAB协议有两种模式,分别是恢复模式(选主模式)和广播模式(同步)。当服务启动或者在领导者崩溃后,ZAB就进入了恢复模式,当领导者被选举出来,且大多数server完成了和leader的状态同步,恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。

7. 什么是ZAB协议

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

当整个Zookeeper集群刚刚启动或者leader服务器宕机,重启或者网络故障导致不存在过半的服务器和leader服务器保持正常通信时,所有 进程进入崩溃恢复模式。首先选举产生新的leader服务器,然后集群中follower服务器开始和新的leader服务器进行数据同步,当集群中超过半数机器和该leader服务器完成数据同步之后,退出恢复模式进入消息广播模式,leader服务器开始接收客户端的事务请求生成事务提案来进行事务请求处理。

8. ZAB和Paxos算法的联系和区别

相同点:

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

不同点:

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

9. 四种类型的数据节点Znode

  1. persistent------持久节点:除非手动删除,否则节点一直存在于zookeeper上。
  2. ephemeral------临时节点:临时节点的生命周期和客户端会话绑定,一旦客户端会话失效,
  3. persistent-sequential------持久顺序节点:基本特性同持久节点,只是增加了顺序属性,节点名后边追加一个由父节点维护的自增整形数字。
  4. ephemeral-sequential------临时顺序节点:基本特性同临时节点,增加了顺序属性,节点名后边会追加一个由父节点维护的自增整型数字。

10. 什么是Zookeeper的通知机制

client端会对某个znode建立一个watcher事件,当该znode发生变化时,这些client会收到zk的通知,然后client可以根据znode变化来做出业务上的改变。

11. Zookeeper中服务器角色有哪些?

Leader

 1. 事务请求的唯一调度和处理者,保证集群事务处理的顺序性。
 2. 集群内部各服务的调度者。

Follower

  1. 处理客户端的非事务请求,转发事务请求给Leader服务器。
  2. 参与事务请求Proposal投票
  3. 参与Leader选举

Observer

   1.在不影响集群事务处理能力的基础上提升集群的非事务处理能力。
   2. 处理客户端的非事务请求,转发事务请求给Leader服务器。
   3. 不参与任何形式的投票。 

12. Zookeeper下Server工作状态

服务器具有四种状态:Looking、Following、Leading、Observing
Looking : 寻找Leader状态,当服务器处于该状态时,他会认为当前集群中,没有Leader。因此,需要进入Leader选举状态。
Following : 跟随者状态,表明当前服务器角色是Follower。
Leading :领导者状态,表明当前服务器角色是Leader。
Observing:观察者状态,表明当前服务器角色是Observer。

13. Zookeeper是如何保证事务的顺序一致性的

Zookeeper采用全局递增的事务ID来标识,所有的proposal都在被提出的时候加上了zxid。当新产生proposal的时候,会依据数据库的两阶段过程,首先向其他server发出事务执行请求,如果半数的机器都能执行并且执行成功,那么就会开始执行。

14. 集群最少要几台机器?集群规则是怎样的

最少要三台,规则为2N+1

15. Zookeeper节点宕机如何处理

Zookeeper本身也是集群,推荐配置不少于3台服务器。Zookeeper自身也要保证当一个节点宕机时,其他节点继续提供服务。

如果是一个Follower宕机,还有2台服务器提供服务,因为Zookeeper上的数据有多个副本,数据并不会丢失。

如果是一个Leader宕机,Zookeeper会选举出新的Leader。

ZK集群的机制是只要超过半数的节点正常,集群就能正常提供服务。只有在zk节点挂的太多时,只剩一半或者不到一半节点能工作,集群才失效,所以:

  • 3个节点的cluster可以挂掉1个节点。
  • 2个节点的cluster不能挂掉任何节点。

16. Eureka和Zookeeper区别

  • 一致性模型与CAP定理取舍
    Eureka: 遵循AP原则,在网络分区发生时,Eureka优先保证服务的可用性,即使返回过时的信息。它通过自我恢复和客户端缓存机制来提高可用性,牺牲了一定程度的数据强一致性。Eureka提供了最终一致性模型,即所有节点上的服务注册信息最终会达到一致状态,但在短时间内可能存在差异。
    Zookeeper:遵循CP原则(一致性与分区容错性)。Zookeeper保证了数据的一致性,即使在部分网络分区的情况下,也确保不会返回错误的数据。这得益于其严格的Leader选举和事务日志复制机制。然而,在某些故障场景下,如Leader选举期间,服务的可用性可能会受到影响。
  • 架构与容错能力
    Eureka:采用客户端-服务器模型,客户端作为服务实例向Eureka服务器注册自己的信息,并定期发送心跳以续约。Eureka服务器之间通过副本数据的同步来实现高可用性和容错性。Eureka通过区域感知和自我保护机制来应对网络分区,即使部分节点故障,也能保持服务的可用性。
    Zookeeper:为主从结构,包含Leader节点和Follower节点。当Leader节点故障时,剩余节点会重新进行选举,选举过程中服务可能不可用。选举完成后,新Leader会与Follower节点进行数据同步,然后恢复服务。Zookeeper通过集群模式提高容错能力,但单个节点故障可能影响整个集群的服务。
相关推荐
Data跳动4 小时前
Spark内存都消耗在哪里了?
大数据·分布式·spark
Java程序之猿6 小时前
微服务分布式(一、项目初始化)
分布式·微服务·架构
来一杯龙舌兰6 小时前
【RabbitMQ】RabbitMQ保证消息不丢失的N种策略的思想总结
分布式·rabbitmq·ruby·持久化·ack·消息确认
节点。csn8 小时前
Hadoop yarn安装
大数据·hadoop·分布式
NiNg_1_2349 小时前
基于Hadoop的数据清洗
大数据·hadoop·分布式
隔着天花板看星星10 小时前
Spark-Streaming集成Kafka
大数据·分布式·中间件·spark·kafka
技术路上的苦行僧15 小时前
分布式专题(8)之MongoDB存储原理&多文档事务详解
数据库·分布式·mongodb
龙哥·三年风水15 小时前
workman服务端开发模式-应用开发-后端api推送修改二
分布式·gateway·php
小小工匠16 小时前
分布式协同 - 分布式事务_2PC & 3PC解决方案
分布式·分布式事务·2pc·3pc
闯闯的日常分享18 小时前
分布式锁的原理分析
分布式