# 1. Curator 框架的 InterProcessMutex 分布式锁实现 A 客户端监听锁路径下所有子节点，任一节点删除都会唤醒自己 B 锁节点是持久节点，客户端崩溃后锁不会自动释放 C 客户端只监听比自己的节点编号小的前一个节点，避免惊群效应 ✓ 正确答案 D 获取锁时直接创建节点，不存在竞争，无需排队
# 2. ZooKeeper 的 ZAB 协议与 Znode 数据模型 A 所有 Follower 必须 ACK 后 Leader 才提交事务 B Leader 收到半数以上 Follower 的 ACK 后即提交事务 ✓ 正确答案 C 写请求可以在任意节点直接执行并广播 D ZAB 协议不需要分配事务 ID，直接按时间顺序执行
# 3. ZooKeeper 的临时节点、顺序节点在分布式锁/选主的应用 A 临时节点在 Leader 崩溃后仍需手动删除才能让位 B 选主时所有节点都监听 Leader 节点，无需维护顺序 C 顺序节点编号不保证单调递增 D 编号最小的临时顺序节点成为 Leader，其余节点监听前一个节点 ✓ 正确答案
# 4. Znode 的 ACL 权限模型（world/auth/digest/ip）与生产配置 A 父节点的 ACL 会自动递归应用到所有子节点 B CREATE 和 DELETE 是同一个权限，统称为写权限 C digest 方案使用明文密码进行认证 D world 方案表示对所有用户开放，无需认证 ✓ 正确答案
# 5. 基于 ZooKeeper 实现乐观锁（version）与悲观锁 A 乐观锁通过创建临时节点实现互斥 B 乐观锁所有写操作都会阻塞其他客户端 C 乐观锁不需要读取版本号，直接写入即可 D 乐观锁利用 dataVersion 校验，版本不一致时抛出 BadVersionException ✓ 正确答案
# 6. ZooKeeper 与 etcd 在协调场景的对比 A ZooKeeper 使用 Raft 协议，etcd 使用 ZAB 协议 B 两者都是 CP 系统，提供强一致性保证 ✓ 正确答案 C etcd 使用自定义 Java 客户端协议，ZooKeeper 使用 gRPC D etcd 的数据模型是树形结构，ZooKeeper 是扁平 KV 结构
# 7. ZooKeeper 的 Quorum 与脑裂防护（半数以上） A 只要集群中有 2 个节点存活就能提交事务 B 半数以上原则保证网络分区时最多只有一个分区能形成 Quorum ✓ 正确答案 C 集群部署偶数节点比奇数节点更安全 D 3 节点集群可以容忍 2 个节点故障
# 8. ZooKeeper 的 Watch 机制的一次性与会话（Session）超时 A Watch 客户端注册后持续有效，无需重新注册 B 会话超时不会影响临时节点的存在 C 客户端收到一次事件通知后 Watch 即失效，需重新注册 ✓ 正确答案 D 一个节点只能注册一个 Watch
# 9. ZooKeeper 的 ZAB 协议，Leader 选举、崩溃恢复与事务日志如何同步？ A 新 Leader 随机选择，不关心事务数据 B 崩溃恢复后所有尚未提交的事务都会直接提交 C 崩溃恢复时新 Leader 会与 Follower 对齐事务日志，保证已提交事务不丢失 ✓ 正确答案 D 崩溃恢复阶段不进行任何数据同步
# 10. ZooKeeper 会话与会话超时，心跳、临时节点失效与客户端重连的语义如何？ A 会话超时后临时节点仍然保留 B 客户端重连一定恢复原会话，临时节点不会丢失 C 会话过期时服务器删除该会话创建的所有临时节点 ✓ 正确答案 D 会话超时由客户端单方面判定，与服务器无关
# 11. ZK 的 watch 机制，一次性通知、顺序保证与丢失事件的工程处理如何？ A Watch 是持久的，注册一次即可永远监听 B 先读取数据再注册 Watch 不会造成事件丢失 C 收到事件后应立刻重新注册 Watch，并采用先注册后读取的顺序 ✓ 正确答案 D 不同节点的 Watch 事件会乱序到达
# 12. Curator 的 LeaderLatch/LeaderSelector 选主 API 与 InterProcessMutex 的区别 A InterProcessMutex 用于选主，不具备互斥语义 B LeaderLatch 适合持续循环的 Leader 任务 C LeaderSelector 通过 takeLeadership 回调持续选主，回调返回后重新竞选 ✓ 正确答案 D 三者底层实现完全不同，无共同点
# 13. ZK 的典型应用，分布式锁、服务注册、配置管理与其在集群规模下的限制如何？ A ZK 的写性能可以水平扩展，任意加节点即可提升吞吐 B ZK 单节点可存储任意大小的数据 C ZK 所有写操作都经过 Leader 串行广播，写吞吐受限于 Leader 刷盘 ✓ 正确答案 D ZK 的连接数没有上限，可无限增长
# 14. ZK 顺序节点与分布式锁，临时顺序节点的公平锁如何实现？ A 等待者只监听自己前一个节点，实现公平与高效唤醒 ✓ 正确答案 B 每个等待者都监听锁路径下所有节点，任一节点删除即唤醒 C 顺序节点编号随机，不保证先来先得 D 持锁者释放后所有等待者同时抢锁
# 15. ZooKeeper 的 Znode 大小限制与性能注意点 A Znode 可以存储任意大小的数据而不会影响性能 B 数据越大，ZK 的写广播反而越快 C 1MB 限制只影响读操作，不影响写操作 D Znode 数据大小默认限制为 1MB，不宜存储大块数据 ✓ 正确答案
# 16. ZK 集群的读写模型，Leader/Follower/Observer 与顺序一致性（线性写）如何？ A 所有读请求都由 Leader 处理，保证读线性一致 B Observer 参与投票，可以提升写入性能 C 写请求由 Leader 统一处理并按 zxid 顺序广播，写是线性一致的 ✓ 正确答案 D Follower 只能处理写请求，不能处理读请求
# 17. ZK 在 Kafka/HDFS 中的应用，元数据管理与协调职责的边界如何？ A ZK 用于 HDFS 的 NameNode 高可用选举与故障转移 ✓ 正确答案 B ZK 存储 Kafka 的日志数据主体 C ZK 存储 HDFS 的块数据 D Kafka 始终依赖 ZK，无法移除
# 18. ZooKeeper 的 4lw 命令（stat/ruok/mntr）与运维监控 A ruok 返回 imok 表示集群整体健康 B 4lw 命令无法返回 Leader 状态 C stat 命令用于修改节点数据 D mntr 输出监控指标，适合监控系统采集 ✓ 正确答案
