ZooKeeper 高频面试题（28道 + 详细答案）

国内服务器4小时前发布 beixibaobao
1 0 0

一、基础概念

1. ZooKeeper 是什么？

ZooKeeper 是一个开源的 分布式协调服务，用于管理分布式系统中各节点的状态，提供高性能、高可用、强一致性的协调能力。

核心功能：

  • 数据发布/订阅（配置中心）
  • 命名服务
  • 分布式锁
  • Master 选举
  • 集群管理
  • 分布式队列
  • 负载均衡协调

一致性保证：

  • 顺序一致性：所有更新全局有序（通过 zxid）
  • 原子性：事务要么全部成功，要么失败
  • 单一视图：客户端无论连接哪个节点，看到的数据一致
  • 可靠性：一旦写入成功，不会丢失
  • 最终实时性：客户端在一定时间内能读到最新数据

⚠️ 读请求可由任意节点处理，写请求需 Leader 协调并达成多数派共识。
集群规模增大 → 读吞吐↑，写吞吐↓。

2. ZooKeeper 提供了什么？

  • 类文件系统的多层级命名空间（ZNode）
  • Watcher 事件通知机制

3. ZooKeeper 文件系统特点？

  • 节点称为 ZNode，支持多级路径（如 /app/config）
  • 每个 ZNode 可存储数据（目录和文件均可存数据）
  • 内存存储：为保证低延迟和高吞吐，全量数据驻留内存
  • 单节点数据上限 1MB，不适合存储大文件

二、核心协议与机制

4. ZAB 协议是什么？

ZAB（ZooKeeper Atomic Broadcast） 是 ZooKeeper 专用的 崩溃恢复型原子广播协议，包含两种模式：

模式 触发条件 行为
崩溃恢复 集群启动 / Leader 宕机 / 网络分区 选举新 Leader，同步数据
消息广播 集群稳定运行 Leader 广播事务提案，Follower 投票确认

✅ ZAB 保证了事务的全局顺序性和集群状态一致性。

5. 四种 ZNode 类型？

类型 特性 生命周期
PERSISTENT 持久节点 手动删除才消失
EPHEMERAL 临时节点 客户端会话结束自动删除
PERSISTENT_SEQUENTIAL 持久顺序节点 自动追加递增序号（如 node0000000001）
EPHEMERAL_SEQUENTIAL 临时顺序节点 临时 + 顺序

📌 临时节点不能有子节点。

6. Watcher 机制详解

ZooKeeper 允许客户端对 ZNode 注册 一次性监听器（Watcher），当节点发生变更时触发通知。

工作流程：
  1. 客户端调用 getData() / exists() / getChildren() 并传入 Watcher
  2. 服务端记录 Watcher（仅标记，不传对象）
  3. 节点变更（create/delete/setData）→ 触发 Watcher
  4. 服务端异步发送事件通知给客户端
  5. 客户端串行回调 Watcher
核心特性：
  • 一次性：触发后自动失效（避免频繁通知压垮服务端）
  • 轻量：只通知“发生了事件”，不包含具体内容
  • 异步通知：存在网络延迟，不保证强一致性，仅最终一致
  • 重连恢复：客户端断线重连后，会自动重新注册 Watcher（除特殊场景外）

❗ 对未创建节点的 exists Watch，若在断连期间被创建又删除，可能丢失事件。

7–9. Watcher 实现细节（略作归纳）

  • 客户端注册：通过 API 封装 Watcher，发送请求至服务端
  • 服务端存储：以 path → ServerCnxn 形式存入 WatchTable
  • 触发时：构造 WatchedEvent，删除对应 Watcher（体现一次性），通过 TCP 发送
  • 客户端回调：由 EventThread 串行执行用户逻辑

三、安全与权限

10. ACL 权限控制机制

ZooKeeper 使用 ACL（Access Control List） 控制访问权限，比传统 UGO 更细粒度。

权限模式（Scheme）：
模式 说明
World world:anyone，开放给所有人（默认）
Digest username:password，最常用（如 admin:123456）
IP 基于 IP 地址授权（如 ip:192.168.1.100）
Super 超级管理员，可绕过所有权限检查
权限类型（Permission）：
  • CREATE：创建子节点
  • DELETE：删除子节点
  • READ：读取节点数据和子节点列表
  • WRITE：更新节点数据
  • ADMIN：修改 ACL

11. Chroot 特性（2.0+）

  • 客户端可设置 Chroot 命名空间（如 /app1）
  • 后续所有操作自动限定在该子树下
  • 用途：多租户隔离，多个应用共享同一 ZooKeeper 集群

四、集群与高可用

12. 会话管理

  • 会话超时时间由客户端指定（如 30s）
  • 服务端采用 分桶策略 管理会话，按 ExpirationTime 分组
  • 超时检测周期 = tickTime（默认 2s）

13. 服务器角色

角色 职责
Leader 处理所有写请求，协调事务，调度集群
Follower 处理读请求，参与写投票和 Leader 选举
Observer（3.0+） 处理读请求，不参与投票，提升读性能

14. 服务器状态

  • LOOKING：选举中
  • LEADING：当前是 Leader
  • FOLLOWING：当前是 Follower
  • OBSERVING：当前是 Observer

15. 数据同步机制

Learner（Follower/Observer）向 Leader 注册后，根据 peerLastZxid 选择同步方式：

同步类型 触发条件
DIFF minCommittedLog ≤ peerLastZxid ≤ maxCommittedLog
TRUNC+DIFF Learner 有 Leader 没有的事务（需先回滚）
TRUNC peerLastZxid > maxCommittedLog
SNAP peerLastZxid < minCommittedLog 或无 Proposal 缓存

✅ 保证所有节点数据最终一致。

16. 如何保证事务顺序一致性？

  • 使用全局唯一 ZXID（ZooKeeper Transaction ID）
  • ZXID = 高32位 epoch（Leader 周期） + 低32位计数器
  • 所有 Proposal 按 ZXID 严格排序，通过 ZAB 协议广播

17. 为什么需要 Master 选举？

在分布式系统中，某些任务（如定时任务、资源分配）只需 一台机器执行，避免重复计算。通过 Master 选举确保唯一性。

18. 节点宕机如何处理？

  • ZooKeeper 集群需 ≥3 节点（满足 2N+1 原则）
  • 容错能力：最多容忍 N 台宕机（3 节点可挂 1 台）
  • Follower 宕机：不影响服务
  • Leader 宕机：触发选举，选出新 Leader

❌ 2 节点集群无法容忍任何宕机（需 2 票 > 1，但只剩 1 票）

19. ZooKeeper vs Nginx 负载均衡

对比项 ZooKeeper Nginx
类型 服务注册发现 + 动态协调 HTTP/TCP 反向代理
控制能力 可编程（结合 Watcher 实现智能路由） 主要靠权重、IP Hash
吞吐量 较低（非设计目标） 极高（专为高并发设计）
适用场景 内部服务治理 对外流量分发

✅ 两者互补：ZK 管服务注册，Nginx 管流量入口。

20. 部署模式

  • 单机模式：开发测试用
  • 伪集群：单机多实例（不同端口）
  • 集群模式：多机部署（生产推荐）

21. 集群最少几台？规则？

  • 最少 3 台
  • 规则：2N+1（N≥1），确保过半存活即可用

22. 支持动态扩容吗？

  • 3.5+ 版本支持动态添加节点
  • 旧版本需：
    • 逐个重启（保证过半存活）
    • 全量重启（修改配置后重启）

五、客户端与生态

23. Watcher 是永久的吗？为什么？

❌ 不是永久的。
原因：

  • 避免高频变更导致服务端压力过大
  • 大多数场景只需最新状态，无需每次变更通知

用户需在回调中重新注册 Watcher 实现持续监听。

24. Java 客户端有哪些？

  • 原生 ZooKeeper Client（API 较底层）
  • zkclient（简化 API）
  • Apache Curator（推荐，封装完善，支持 Recipes）

25. Chubby vs ZooKeeper

项目 Chubby（Google） ZooKeeper（Apache）
协议 Paxos ZAB（Paxos 变种）
开源 ❌ 闭源 ✅ 开源
性能 侧重强一致性 侧重高吞吐、低延迟
定位 锁服务、粗粒度协调 通用分布式协调

ZooKeeper 被视为 Chubby 的开源实现。

26. 常用命令

bash

编辑

ls /            # 查看子节点
get /config     # 获取节点数据
set /config "new"  # 更新数据
create /lock "" # 创建节点
delete /lock    # 删除节点
stat /          # 查看节点状态（含 zxid、版本等）

27. ZAB 与 Paxos 联系与区别

对比项 相同点 不同点
角色 都有 Leader/Follower —
投票 需过半同意 —
应用 — ZAB：主备数据系统（如 ZK）
Paxos：通用状态机复制

ZAB 针对 ZooKeeper 场景做了优化（如 zxid 顺序、崩溃恢复）。

28. 典型应用场景

（1）配置管理（发布/订阅）
  • 配置存于 ZNode
  • 客户端启动时读取 + 注册 Watcher
  • 配置变更 → 通知所有客户端 → 动态生效
（2）命名服务
  • 全局唯一路径作为服务名（如 /services/order）
  • 存储服务地址列表，实现服务发现
（3）Master 选举
  • 所有节点创建 临时顺序节点
  • 编号最小者成为 Master
  • Master 宕机 → 临时节点消失 → 触发重新选举
（4）分布式锁
  • 独占锁：尝试创建 /lock，成功即获得锁
  • 顺序锁：创建临时顺序节点，监听前驱节点，实现 FIFO
（5）分布式队列
  • 同步队列：等待所有成员就位（通过子节点数量判断）
  • FIFO 队列：使用 PERSISTENT_SEQUENTIAL 节点，按序消费
（6）集群管理
  • 机器上线：创建临时节点
  • 机器下线：节点自动消失 → Watcher 通知其他成员
© 版权声明
文章版权归作者所有，未经允许请勿转载。

相关文章

标签云