Zookeeper 面试题分类整理
Zookeeper 面试题分类整理
文章目录
- Zookeeper 面试题分类整理
-
- 一、基础概念
- 二、核心原理
-
- 1. Zookeeper如何保证数据一致性？
- 2. Zookeeper的Watch机制是什么？
- 3. Zookeeper的会话(Session)是什么？
- 三、集群相关
-
- 1. Zookeeper集群中的角色有哪些？
- 2. Zookeeper选举Leader的过程是怎样的？
- 3. Zookeeper集群最少需要几台服务器？
- 四、应用场景
-
- 1. 如何使用Zookeeper实现分布式锁？
- 2. 如何使用Zookeeper实现配置中心？
- 3. 如何使用Zookeeper实现服务注册与发现？
- 五、性能与优化
-
- 1. Zookeeper的读写性能如何？
- 2. Zookeeper的存储限制是什么？
- 3. 如何监控Zookeeper的健康状态？
- 六、常见问题
-
- 1. Zookeeper的脑裂问题是什么？如何避免？
- 2. Zookeeper的数据如何持久化？
- 3. Zookeeper和Eureka有什么区别？
一、基础概念
1. 什么是Zookeeper？
答案：
Zookeeper是一个开源的分布式协调服务，就像是一个\"分布式文件系统+通知机制\"。它主要用来解决分布式系统中的一致性问题，比如配置管理、命名服务、分布式锁、集群管理等场景。
简单来说，它就像是一个\"分布式环境下的记事本\"，所有分布式应用都可以在上面读写数据，而且保证数据在所有服务器上都是一致的。
2. Zookeeper的数据模型是怎样的？
答案：
Zookeeper的数据模型类似于文件系统的树形结构，每个节点叫ZNode。但与文件系统不同的是：
- 每个ZNode可以存储数据（就像文件）
- 可以有子节点（就像目录）
- 节点路径是唯一的
- 节点有四种类型：持久节点、临时节点、持久顺序节点、临时顺序节点
3. Zookeeper的节点类型有哪些？
答案：
- 持久节点(PERSISTENT)：创建后一直存在，直到显式删除
- 临时节点(EPHEMERAL)：与客户端会话绑定，会话结束节点自动删除
- 持久顺序节点(PERSISTENT_SEQUENTIAL)：持久节点+自动编号后缀
- 临时顺序节点(EPHEMERAL_SEQUENTIAL)：临时节点+自动编号后缀
顺序节点的编号是单调递增的，由父节点维护。
二、核心原理
1. Zookeeper如何保证数据一致性？
答案：
Zookeeper使用ZAB协议(Zookeeper Atomic Broadcast)来保证一致性，这类似于Paxos算法。简单说就是：
- 所有写请求都会转发给Leader
- Leader先写入自己的日志
- Leader把写请求广播给所有Follower
- 超过半数Follower确认后，Leader提交这个写操作
- Leader通知所有Follower提交
这种\"多数派\"机制保证了即使部分节点宕机，集群仍能正常工作。
2. Zookeeper的Watch机制是什么？
答案：
Watch机制就像\"订阅通知\"：
- 客户端可以在读取ZNode时设置一个Watch
- 当这个ZNode发生变化(创建/删除/数据修改)时，Zookeeper会通知客户端
- 通知是一次性的，收到后如果想继续监听需要重新设置
注意：Watch通知可能会有延迟，且不保证按顺序到达。
3. Zookeeper的会话(Session)是什么？
答案：
会话是Zookeeper中客户端与服务器之间的一个虚拟连接：
- 客户端连接时创建会话，获得一个sessionId
- 会话有超时时间(sessionTimeout)
- 客户端需要定期发送心跳保持会话活跃
- 会话过期后，所有临时节点和Watch都会被清除
三、集群相关
1. Zookeeper集群中的角色有哪些？
答案：
- Leader：处理所有写请求，负责投票的发起和决议
- Follower：处理读请求，参与Leader选举和写请求投票
- Observer：与Follower类似，但不参与投票，只同步数据，用于扩展读性能
2. Zookeeper选举Leader的过程是怎样的？
答案：
选举过程(以3节点集群为例)：
- 每个节点启动时都先投自己一票
- 节点互相交换投票信息
- 比较选举轮次(epoch)和ZXID(最新事务ID)，选择最大的
- 如果都相同，则选择myid(配置文件中的服务器ID)最大的
- 当某个节点获得超过半数的投票，就成为Leader
3. Zookeeper集群最少需要几台服务器？
答案：
最少需要3台服务器。因为Zookeeper采用\"多数派\"原则：
- 3台可以容忍1台故障(2>3/2)
- 2台的话只能容忍0台故障(因为1不大于2/2)，所以2台没有容错能力
四、应用场景
1. 如何使用Zookeeper实现分布式锁？
答案：
常见实现方式：
- 临时节点法：所有客户端尝试创建同一个临时节点，创建成功的获得锁，失败的监听这个节点
- 顺序节点法：
- 每个客户端创建一个临时顺序节点
- 判断自己是不是序号最小的
- 如果是则获得锁，否则监听前一个节点
- 前一个节点删除时获得通知
临时节点的好处是客户端断开连接时会自动释放锁。
2. 如何使用Zookeeper实现配置中心？
答案：
实现步骤：
- 把配置信息存储在Zookeeper的某个ZNode中
- 所有应用启动时读取这个ZNode获取配置
- 同时在这个ZNode上设置Watch
- 当配置变更时，Zookeeper会通知所有监听的应用
- 应用收到通知后重新读取最新配置
3. 如何使用Zookeeper实现服务注册与发现？
答案：
实现方式：
- 服务注册：服务启动时在Zookeeper上创建临时节点(如/services/serviceName/instance1)
- 服务发现：客户端监听/services/serviceName下的子节点变化
- 健康检查：由于是临时节点，服务宕机会自动删除对应节点
- 负载均衡：客户端可以轮询或随机选择可用服务实例
五、性能与优化
1. Zookeeper的读写性能如何？
答案：
Zookeeper的读写特点：
- 读性能高：所有服务器都可以处理读请求，且是内存操作
- 写性能较低：所有写请求都要由Leader处理，且需要多数节点确认
- 适合\"读多写少\"的场景
优化建议：
- 使用Observer节点扩展读能力
- 避免频繁的小数据量写入
- 合理设置sessionTimeout和tickTime
2. Zookeeper的存储限制是什么？
答案：
Zookeeper不适合存储大量数据：
- 所有数据存储在内存中，受内存限制
- 虽然会持久化到磁盘，但设计初衷不是作为数据库
- 建议每个节点存储的数据不超过1MB
- 节点数量也不宜过多(通常不超过10万级)
3. 如何监控Zookeeper的健康状态？
答案：
监控要点：
- 四字命令：如
stat查看状态，ruok检查是否存活 - JMX监控：通过JMX暴露的指标监控请求延迟、节点数等
- 关键指标：
- 活跃连接数
- 待处理请求数
- ZNode数量
- 数据大小
- Leader/Follower状态
- 日志监控：关注WARN和ERROR日志
六、常见问题
1. Zookeeper的脑裂问题是什么？如何避免？
答案：
脑裂是指网络分区导致出现多个Leader的情况。Zookeeper通过以下机制避免：
- 多数派原则：只有获得多数节点认可的才能成为Leader
- epoch机制：每次选举都有递增的epoch号，节点只认最新epoch的Leader
- Follower只接受当前epoch的Leader指令
即使网络分区，也最多只有一个分区能形成多数派，从而避免脑裂。
2. Zookeeper的数据如何持久化？
答案：
Zookeeper使用两种文件持久化数据：
- 快照文件(snapshot)：内存数据的完整拷贝，定期生成
- 事务日志(transaction log)：所有写操作的顺序记录
恢复时先加载快照，然后重放之后的事务日志。写操作会先写入事务日志(追加写，性能高)，再更新内存数据。
3. Zookeeper和Eureka有什么区别？
答案：
主要区别：
- 一致性：Zookeeper是CP系统(强一致)，Eureka是AP系统(高可用)
- 服务发现：Zookeeper服务下线能快速感知，Eureka有自我保护模式
- 使用场景：
- Zookeeper适合需要强一致的场景(如配置管理、分布式锁)
- Eureka适合服务发现，能容忍短暂不一致
- 性能：Zookeeper写性能较低，Eureka纯内存操作性能更高
