【ZooKeeper面试题】从基础到深入

ZooKeeper面试题：从基础到深入

基础概念

1. 什么是ZooKeeper？它的主要用途是什么？

   • ZooKeeper是一个分布式的、开源的协调服务，用于分布式应用程序
   • 主要用途：配置管理、命名服务、分布式同步、集群管理等

2. ZooKeeper的数据模型是怎样的？

   • 采用类似文件系统的层次化命名空间（树形结构）
   • 每个节点称为znode，可以存储数据和子节点
   • 分为持久节点和临时节点

3. ZooKeeper中的节点(znode)有哪些类型？

   • 持久节点(PERSISTENT)：创建后一直存在，直到显式删除
   • 临时节点(EPHEMERAL)：客户端会话结束时自动删除
   • 持久顺序节点(PERSISTENT_SEQUENTIAL)：持久节点+顺序编号
   • 临时顺序节点(EPHEMERAL_SEQUENTIAL)：临时节点+顺序编号

4. ZooKeeper的Watch机制是什么？

   • 客户端可以在znode上设置watch来监听节点变化
   • 当znode发生变化时，ZooKeeper会通知客户端
   • Watch是一次性的，触发后需要重新设置

架构与原理

1. ZooKeeper集群中的角色有哪些？

   • Leader：负责处理所有写请求和事务性操作
   • Follower：处理读请求，参与Leader选举和提案投票
   • Observer：与Follower类似，但不参与投票，用于扩展读性能

2. ZooKeeper如何保证数据一致性？

   • 使用ZAB协议(ZooKeeper Atomic Broadcast)
   • 所有写请求都通过Leader处理，并广播给所有Follower
   • 只有多数节点确认后，写操作才会提交

3. ZAB协议的工作原理是什么？

   • 分为两个阶段：
     1. 发现阶段：选举Leader并同步数据
     2. 广播阶段：Leader将更新广播给Follower
   • 使用两阶段提交确保数据一致性

4. ZooKeeper的选举过程是怎样的？

   • 每个节点都有唯一的myid和zxid(最后事务ID)
   • 节点投票给zxid最大的节点，zxid相同则投给myid大的
   • 获得多数票的节点成为Leader

高级特性

1. ZooKeeper如何处理脑裂问题？

   • 通过"多数派"原则解决
   • 只有获得多数节点认可的Leader才能提供服务
   • 少数派分区中的节点无法选举出有效Leader

2. ZooKeeper的会话(Session)机制是怎样的？

   • 客户端与服务器建立TCP连接时创建会话
   • 会话有超时时间(sessionTimeout)
   • 心跳机制保持会话活跃
   • 会话过期时，临时节点会被删除

3. ZooKeeper的ACL权限控制是如何工作的？

   • 每个znode可以设置访问控制列表(ACL)
   • ACL由(scheme:expression, permissions)组成
   • 常用scheme：world, auth, digest, ip等
   • 权限：CREATE, READ, WRITE, DELETE, ADMIN

4. ZooKeeper的读写性能特点是什么？

   • 读性能高：所有服务器都可处理读请求
   • 写性能较低：所有写请求必须通过Leader处理
   • 适合读多写少的场景

实际应用

1. 如何使用ZooKeeper实现分布式锁？

   • 创建临时顺序节点
   • 检查自己是否是最小序号的节点
   • 如果是则获取锁，否则监听前一个节点
   • 释放锁时删除自己的节点

2. ZooKeeper如何实现配置管理？

   • 将配置信息存储在持久znode中
   • 客户端watch该znode的变化
   • 配置更新时，所有客户端会收到通知并获取新配置

3. ZooKeeper如何实现服务注册与发现？

   • 服务提供者创建临时znode（如/services/service1/node1）
   • 服务消费者watch父znode(/services/service1)的子节点变化
   • 当服务提供者上线/下线时，消费者会收到通知

4. ZooKeeper如何实现Leader选举？

   • 所有候选节点创建临时顺序znode
   • 序号最小的节点成为Leader
   • 其他节点watch比它小的节点
   • 当Leader失效时，下一个序号的节点成为新Leader

性能优化与运维

1. 如何优化ZooKeeper的性能？

   • 合理设置sessionTimeout
   • 使用Observer节点扩展读能力
   • 避免过多watch和频繁的小数据量写入
   • 适当增加snapshot和log清理频率

2. ZooKeeper的监控指标有哪些关键点？

   • 节点数量和数据大小
   • 请求延迟和吞吐量
   • Watch数量
   • 连接数和会话数
   • 领导者状态和选举次数

3. 如何诊断ZooKeeper的性能问题？

   • 检查四字命令如stat, mntr
   • 分析日志中的WARN和ERROR
   • 监控网络延迟和磁盘I/O
   • 检查是否有过多的watch或大znode

4. ZooKeeper的备份和恢复策略是什么？

   • 定期备份事务日志和快照文件
   • 可以通过恢复快照+重放事务日志来恢复
   • 重要数据建议多重备份机制

与其他技术对比

1. ZooKeeper与etcd有何异同？

   • 相同点：都是分布式一致性协调服务
   • 不同点：
     • etcd使用Raft协议，ZooKeeper使用ZAB
     • etcd提供HTTP/gRPC接口，ZooKeeper有自己的客户端API
     • etcd更简单轻量，ZooKeeper功能更丰富

2. 为什么Kafka早期版本依赖ZooKeeper，新版本要移除？

   • 早期用于broker注册、topic配置、ISR管理等
   • 依赖ZooKeeper增加了复杂度
   • 新版本使用Kafka内部共识协议(KRaft)替代

3. ZooKeeper适合哪些场景，不适合哪些场景？

   • 适合场景：配置管理、服务发现、分布式锁、Leader选举
   • 不适合场景：大数据量存储、高频写操作、需要强一致性读