本章定位：将 11 个章节的面试考点系统汇总，按主题分类，每道题配有核心要点提示。
分布式协调基础
Q1：分布式协调的核心挑战是什么？
- 时钟不可靠（不能依赖物理时钟排序事件）
- 网络不可靠（消息延迟、丢失、乱序）
- 部分失败（某个节点失败不等于全部失败）
Q2：ZooKeeper 在 CAP 中属于什么？ [详见 Q22 对比表格]
- CP：保证强一致性和分区容错性
- 牺牲可用性：Leader 宕机后选举期间集群不可用（通常 200ms 以内）
数据模型与 ZNode
Q3：ZooKeeper 的数据模型是怎样的？ [详见 ZNode.md]
- 树形命名空间（类似文件系统）
- 每个 ZNode 既是路径也是数据容器
- 支持 Sequential 和 Ephemeral 特性
- 数据通常 < 1KB，单节点上限 1MB
Q4：持久节点和临时节点的区别？ [详见 节点类型对比.md]
- Persistent：手动创建手动删除，生命周期独立于 Session
- Ephemeral：Session 结束自动删除，不能有子节点
- Persistent Sequential / Ephemeral Sequential：自动附加 10 位递增序号
Q5：版本号的作用是什么？ [详见 ZNode.md]
- version：数据修改次数
- cversion：子节点修改次数
- aversion：ACL 修改次数
- 用于乐观锁：setData 时指定预期 version，不一致则失败
Q6：如何设计 ZooKeeper 的 ACL？ [详见 ACL.md]
- Scheme：world / auth / digest / ip
- 五种权限：CREATE、READ、WRITE、DELETE、ADMIN
- 子节点不继承父节点 ACL
会话与 Watcher
Q7：Session 的生命周期是怎样的？ [详见 Session.md]
- CONNECTING → CONNECTED → （可能 Disconnected → CONNECTED）→ （可能 Expired）
- Session Timeout 由客户端提议，服务端决定（范围 2 × tickTime ~ 20 × tickTime）
- Session 迁移：重连到其他节点后继续使用原 Session
Q8：Watcher 机制的核心特点？ [详见 Watcher.md]
- 一次性触发（One-time Trigger）
- 串行处理（客户端保证顺序）
- 轻量级设计（只通知事件类型，不含新旧数据）
- 服务端发送通知后才删除 Watcher，保证送达
Q9：如何处理 Watcher 丢失？
- 收到通知后立即 getData 重新注册 Watcher
- 定时轮询作为兜底（如每 30s 全量同步）
- Curator 的 NodeCache / TreeCache 自动处理
ZAB 协议与一致性
Q10：ZAB 协议的四个阶段？ [详见 ZAB协议.md]
- Leader Election（Leader 选举）
- Discovery（发现阶段，确定最新 epoch）
- Synchronization（同步阶段，Follower 追上 Leader）
- Broadcast（广播阶段，正常处理事务）
Q11：ZooKeeper 如何保证顺序一致性？ [详见 一致性保证.md]
- 全局 ZXID 递增：高 32 位 epoch + 低 32 位计数器
- TCP 顺序传输确保客户端按序接收
- 单个客户端看到的操作顺序与全局顺序一致
Q12：ZAB 和 Raft 的区别？ [详见 Q22 ZK vs etcd 对比]
- ZAB 针对主备场景，Raft 更通用
- ZAB 选举优先有最新数据的节点（max ZXID）
- Raft 引入 Term 概念，选举更结构化
- 两者核心思想相似：Leader 驱动 + 多数派确认
Leader 选举
Q13：Leader 选举的投票规则？ [详见 Leader选举.md]
- 比较 epoch（大的优先）
- 比较 ZXID（大的优先）
- 比较 myid（大的优先）
- 收到过半数选票后切换为 Leader
Q14：为什么需要奇数节点？
- 选举需要过半数（quorum = floor(n/2) + 1）
- 3 节点容忍 1 台故障，4 节点同样容忍 1 台 → 浪费资源
- 偶数节点增加故障概率而不增加容错能力
Q15：如何避免脑裂？
- Quorum 机制：必须有超过半数节点认可才成为 Leader
- 旧 Leader 发现自己失去多数派支持后自动降级为 Follower
- epoch 递增保证旧 Leader 提案被拒绝
分布式锁
Q16：ZooKeeper 分布式锁的实现原理？ [详见 分布式锁.md]
- Ephemeral Sequential 节点
- 公平锁：Watch 前驱节点
- 非公平锁：Watch 根节点（惊群效应）
- 释放：delete 节点 或 Session 超时
Q17：ZooKeeper 锁和 Redis 锁的选择？
- ZK：强一致性 + 公平排队 + 自动释放 → 适合金融、核心业务流程
- Redis：高性能 + 简单 SET NX + EXPIRE → 适合高吞吐互联网场景
配置中心与服务发现
Q18：如何用 ZooKeeper 做配置中心？ [详见 配置中心.md]
- ZNode 存储配置，Watcher 推送变更
- 配置树：/config/{env}/{app}/{key}
- 需自行实现配置回滚和灰度发布
Q19：ZooKeeper 服务发现和 Eureka 的区别？ [详见 Q22 对比表格]
- ZK（CP）：网络分区时少数派不可用
- Eureka（AP）：网络分区时各分区独立服务
- 选型：强一致性场景用 ZK；高可用场景用 Eureka
运维与性能
Q20：ZooKeeper 的性能瓶颈在哪里？
- 事务日志的磁盘 fsync（受限于磁盘 IOPS）
- Session 数量（每个 Session 消耗内存和心跳带宽）
- 读可以水平扩展（Follower），写不能（必须经过 Leader）
Q21：如何优化 ZooKeeper 的磁盘 IO？ [详见 监控.md]
- 事务日志和快照分盘存储（dataLogDir vs dataDir）
- 使用 SSD 存放事务日志
- 调整 snapCount（默认 100000）平衡日志大小和恢复速度
Q22：ZooKeeper vs etcd vs Consul 对比（CAP 角度） [详见 设计思想.md]
| 维度 | ZooKeeper | etcd | Consul |
|---|---|---|---|
| 一致性协议 | ZAB（自研） | Raft | Raft（自研实现） |
| CAP 分类 | CP（强一致） | CP（强一致） | CA（默认，弱一致） |
| 数据模型 | 树形 ZNode（类文件系统） | 扁平 K-V（支持前缀范围查询） | 扁平 K-V + 健康检查 + DNS |
| Watch 机制 | 一次性 Trigger（注册→触发→删除） | Watch（gRPC 长连接流，持续推送） | HTTP Long Polling（阻塞查询） |
| 语言栈 | Java | Go | Go |
| 服务发现 | 需自行实现注册/注销逻辑 | 支持 Lease 机制（TTL） | 内置服务发现 + DNS / HTTP API |
| 健康检查 | 无内置（通过 Ephemeral 间接实现） | Lease 心跳 | 内置 TCP/HTTP/gRPC/脚本多种检查 |
| 多数据中心 | 无原生支持（Observer 可辅助） | 无原生支持 | 第一公民特性（WAN Federation） |
| 生态成熟度 | 极成熟（Hadoop/Kafka/HBase 依赖） | Kubernetes 标准后端 | HashiCorp 生态（Nomad/Vault/Terraform） |
| 密码体系 | Digest ACL / x509（3.5+） | 证书 + RBAC | ACL Token + TLS |
| 适用场景 | 分布式协调、配置中心、分布式锁 | K8s 配置存储、共享状态、Leader 选举 | 服务发现、健康检查、Multi-DC |
三者的定位差异：
- ZooKeeper：偏 CP 强一致协调。节点树模型适合表达层级关系和顺序，锁语义天然完备。但重型（Java 运行开销大）且 Watch 为一次性触发需自行续注册。适合 Hadoop/HBase/Kafka 等强一致性协调场景。
- etcd：偏 CP K-V 存储。扁平 K-V + Watch 长连接 + gRPC 生态简单高效，Kubernetes 的标准配置后端。相比 ZK，Watch 持续推送更省心，但数据模型不如 ZK 树直观。
- Consul：偏 CA 服务发现。内置健康检查、DNS 接口、多数据中心联邦，开箱即用的服务网格能力。但默认弱一致性（通过 DNS TTL 控制），一致性保证不如 ZK/etcd。
选型建议：
- 强一致性协调 / 分布式锁 / 存量 Hadoop 生态 → ZooKeeper
- Kubernetes 场景 / 新项目键值存储 / 简单 Leader 选举 → etcd
- 异构服务发现 / 多数据中心 / 健康检查 → Consul
以上考点覆盖了 ZooKeeper 核心机制的所有高频问答，建议结合对应章节深入理解原理后再作答。