ZooKeeper 面试题
本页只放 ZooKeeper 面试标准回答、追问点、项目话术和原理页跳转。详细原理请跳到知识点页。
核心问题
| 问题 | 标准回答 | 原理页 |
|---|---|---|
| ZooKeeper 是什么 | ZooKeeper 是分布式协调组件，提供 znode 树、临时节点、顺序节点、Watcher、Session 和一致性写入能力，常用于注册中心、配置通知、分布式锁、选主和集群成员管理。 | ZooKeeper 总览 |
| ZooKeeper 适合做什么 | 适合做低频、关键、强协调的元数据管理，例如服务注册发现、主备选举、分布式锁、配置通知。 | ZooKeeper 总览 |
| ZooKeeper 不适合做什么 | 不适合存大量业务数据，不适合高频读写，不适合作为消息队列，也不适合承载业务流量。 | ZooKeeper 总览、运维排查 |
| ZK 为什么常作为 Dubbo 注册中心 | 传统Dubbo可用临时节点表达Provider Session所有权，Consumer通过Watch/Cache重新读取服务目录并更新Invoker快照。短暂断连不会立即删除节点，Session过期才删除；注册中心只做控制面，不转发RPC。 | Dubbo注册发现、Session失效窗口 |
数据模型追问
| 追问 | 标准回答 | 原理页 |
|---|---|---|
| znode 是什么 | znode是树形命名空间中的协调节点，可同时保存小型字节数据、直接子节点、Stat和ACL；它不是文件，通常整体读写且主要驻留内存，不适合大业务数据和事件日志。 | znode树、为什么不是文件系统 |
| 有哪些节点类型 | 常见Persistent、Ephemeral及Sequential组合；临时节点属于Session且不能有子节点。较新版本还有Container和TTL节点，但Server、Client与功能开关有版本边界，TTL也不是精确定时器。 | 节点类型、Container和TTL |
| 临时节点什么时候删除 | 临时节点属于Session而不是单条TCP连接；短暂断连可在协商Timeout内恢复原Session，服务端确认过期或客户端正常关闭后才清理临时节点。过期后旧Session不可恢复。 | Session建立、过期语义 |
| 顺序节点有什么用 | 顺序节点把并发创建请求转成稳定序号，可用于排队锁和业务选主；它提供近似FIFO，不保证按业务发起时间严格公平，也不能单独阻止过期旧客户端写外部资源。 | 锁数据模型、顺序节点作用 |
| version、cversion、aversion区别 | version记录节点数据变化，cversion记录直接子节点集合变化，aversion记录ACL变化；setData/delete/setACL应使用对应期望版本，不能混用。 | Stat字段、三类版本 |
| BadVersion怎么办 | 它是明确并发冲突，不是网络故障。应重读当前数据和version，合并业务意图后基于新version提交；不能用version=-1无条件覆盖来掩盖冲突。 | 版本CAS、排查 |
| ZooKeeper multi能和数据库一起事务吗 | 不能。multi只保证同一ZooKeeper集群中多个znode操作全部成功或全部失败，不能包含MySQL、Redis或MQ；响应丢失时仍可能结果未知。 | multi事务边界、ConnectionLoss |
| ACL权限会自动继承吗 | 不会。创建子节点时需显式提供ACL或由框架默认策略注入；CREATE和DELETE主要控制父节点下创建/删除子节点。父节点严格但子节点开放会产生漏洞。 | ACL模型、ACL不继承 |
| 顺序节点后缀能永久当Fencing Token吗 | 必须谨慎。传统顺序计数有有符号32位及溢出边界，父路径删除重建会破坏连续语义，不同父路径也不可比较。关键Token要保证父路径稳定或使用独立单调序列。 | 顺序号边界、Fencing Token |
ZAB 和一致性追问
| 追问 | 标准回答 | 原理页 |
|---|---|---|
| ZAB 是什么 | ZAB是ZooKeeper原子广播协议，完整过程包括Leader选举后的Discovery、新epoch建立、DIFF/TRUNC/SNAP历史同步和正常Broadcast，不只是“Leader把写复制给Follower”。 | ZAB三个阶段、恢复全过程 |
| 写请求怎么处理 | 写请求进入任一Server后最终由Leader校验、生成事务并分配zxid，广播Proposal；Follower持久化后ACK，Leader获得投票成员法定多数才推进Commit，各Server按zxid应用，再完成响应和Watch通知。 | 写请求全过程、Proposal与Commit |
| 为什么要过半 | N个投票成员的普通多数是floor(N/2)+1，任意两个多数集合必有交集；网络分成3和2时只有3节点侧能提交，少数派旧Leader无法获得足够ACK。交集还需配合epoch和日志规则。 | Quorum、多数派交集 |
| 为什么 ZK 集群常用奇数节点 | 普通多数派下，4节点和3节点都只能容忍1个投票节点故障，6和5都只能容忍2个；偶数节点增加确认成本却不增加对应容错，常用3或5。Observer不参与投票。 | Quorum计算、角色 |
| ZooKeeper 是 CP 还是 AP | 网络分区时只有多数派侧能选主并提交写，少数派拒绝写来保护一致性，所以通常归为CP；多数派侧仍可用，某些只读模式可能提供陈旧读，不能把CP解释为整个集群永远不可用。 | ZooKeeper与CAP |
| zxid 是什么 | zxid是ZooKeeper事务顺序标识，常由高32位epoch和低32位时期内计数组成；它用于排序与恢复，不是时间戳、业务幂等键，也不等于znode version。 | zxid、zxid边界 |
| DIFF、TRUNC、SNAP是什么 | 新Leader恢复时，Follower若只是缺少安全后缀就DIFF补齐；若保留冲突未提交尾部就TRUNC截断；差异太大或日志不足就用SNAP同步完整数据树，再进入广播。 | DIFF/TRUNC/SNAP |
| ZooKeeper读是线性一致吗 | 写事务经Quorum排序提交，但读通常由当前Server本地处理，Follower可能短暂落后，因此不能概括为任意本地读都线性一致。需要看见之前完成的写时可正确使用sync后再读，并处理连接边界。 | 读路径、sync语义 |
| 写请求ConnectionLoss能直接重试吗 | 不能。事务可能已获得多数派提交，只是响应丢失。应重连后读取数据、version和业务操作标识：目标已存在则幂等成功，仍是旧版本才条件重试，被他人推进则冲突处理。 | UNKNOWN结果 |
Watcher 和 Session 追问
| 追问 | 标准回答 | 原理页 |
|---|---|---|
| Watcher 是什么 | 标准Watch是一次性变化提示；exists、getData、getChildren观察范围不同。触发后应重新读取完整事实并重新注册，而不是根据事件次数增减业务状态。 | Watch定义、Watch类型、一次性语义 |
| Watcher 能当 MQ 吗 | 不能。Watch不保存可重放事件流，断连期间的中间变化不应依赖逐条事件恢复。ZooKeeper 3.6持久/递归Watch也只是持续监听能力，离线恢复仍需重建快照。 | 重注册窗口、持久Watch |
| 连接断开和 Session 过期区别 | Disconnected是不确定状态，Session可在Timeout内跨Server恢复；Expired是不可逆终态，旧临时节点和锁所有权失效。新连接成功不能自动恢复旧Leader或锁身份。 | 连接状态、断连与过期 |
| SessionTimeout 怎么设置 | 客户端期望值会受Server最小/最大范围协商。过短会被网络抖动、GC Pause和CPU饥饿误过期，过长会延长死实例残留；应比较协商值、最大停顿、网络和故障检测目标。 | 超时协商、GC Pause、排查 |
分布式锁和选主追问
| 追问 | 标准回答 | 原理页 |
|---|---|---|
| ZK 分布式锁怎么实现 | 客户端创建临时顺序节点，排序后最小者持锁；其他客户端只对紧邻前驱执行exists+Watch，前驱不存在就立即重排，存在才等待。每次唤醒都重新确认自己是否最小。 | 获取锁流程、前驱Watch竞态 |
| 为什么监听前一个节点 | 若所有等待者监听最小节点，释放时会同时唤醒并读取形成羊群效应；前驱链让一次释放主要唤醒下一个等待者，减少无效竞争。 | 前驱Watch |
| ZK 锁和 Redis 锁怎么选 | ZK以Session、临时顺序节点和Watch排队，适合低频关键协调；Redis通常吞吐更高，以TTL和原子命令管理所有权。两者都存在旧持有者恢复边界，都需要外部Fencing和业务幂等。 | ZK与Redis锁对比 |
| ZK 锁一定安全吗 | ZooKeeper能正确删除过期Session节点，但暂停旧线程恢复后仍可绕过ZK写数据库。必须让外部资源原子保存并比较递增Fencing Token，客户端本地判断无效。 | GC双执行窗口、Fencing Token |
| Fencing Token为什么必须在外部资源校验 | 旧客户端暂停时看不到新Token，恢复后本地仍可能认为自己有效；只有数据库、存储或设备网关在每次写入时原子拒绝小于当前Token的请求，才能强制隔离旧持有者。 | Token外部校验 |
| ZK 怎么选主 | 业务实例可创建临时顺序候选节点，最小者成为Leader；断连时暂停风险任务，Expired后永久撤销身份并重新竞争。应用Leader与ZooKeeper Server的ZAB Leader是不同概念。 | 两种Leader区别、业务选主流程 |
| LeaderLatch能保证任务只执行一次吗 | 不能。旧Leader可能执行一半后失去Session，新Leader会接管；回调和旧任务停止也有窗口。任务仍需唯一业务键、状态机、幂等、Token和接管对账。 | Leader不等于Exactly Once |
运维排查追问
| 追问 | 标准回答 | 原理页 |
|---|---|---|
ruok=imok能证明集群健康吗 | 不能，只能说明进程/命令端口有响应；还要检查Leader、Quorum、角色、磁盘fsync、Follower zxid、outstanding、Session、业务路径和Dubbo Directory。 | 分层健康检查、四字命令 |
| ZK 延迟高怎么排查 | 将写延迟拆成排队、Leader处理、txnlog fsync、Quorum网络/ACK和响应；再查outstanding、最慢Follower、GC、大multi、大znode、Snapshot IO和写流量突增。 | 写延迟Runbook、延迟指标 |
| 客户端频繁重连怎么排查 | 按应用/IP查连接建立速率，检查是否每请求创建客户端、NAT共享IP与maxClientCnxns、GC Pause、网络、文件描述符和协商Session Timeout；重连必须退避加抖动。 | 连接风暴Runbook |
| Leader反复选举怎么排查 | 检查投票成员Election/Quorum端口、网络RTT/丢包、Leader和Follower GC、CPU节流、txnlog fsync、initLimit/syncLimit，以及自动化是否同时重启多数节点。 | Leader选举Runbook |
| Follower长期同步怎么办 | 比较Follower和Leader zxid，判断DIFF/TRUNC/SNAP，检查Snapshot大小、日志保留、网络和磁盘；一次恢复一个节点并等追平，避免多个落后节点同时拖垮Leader。 | Follower同步Runbook |
| 磁盘满了能直接删除txnlog吗 | 不能。启动需要最近Snapshot及其后的事务日志，随机删除可能破坏恢复。应先保住Quorum、停止非必要写、用官方清理/已验证历史释放空间，一次处理一个Follower并修复autopurge。 | 磁盘满、autopurge |
| 节点数持续增长怎么办 | 按路径统计Persistent/Ephemeral和children，重点查Persistent Sequential、审计日志式节点、锁取消失败和注册类型错误；清理前备份并验证引用，不能直接递归删除生产父路径。 | 数据模型Runbook、容量模型 |
| 滚动升级怎样避免集群不可用 | 始终保持Quorum，一次处理一个Follower，启动后等待角色稳定和zxid追平再继续，最后处理Leader；跨版本按官方兼容矩阵验证磁盘格式、TLS、动态配置和客户端。 | 滚动升级 |
| Dubbo No Provider 和 ZK 有什么关系 | 先确认ZK有Leader/Quorum，再查Provider export/register、接口级或应用级实例和元数据、namespace/chroot与ACL、Consumer通知和Directory、Router候选，最后验证Provider数据面。 | ZooKeeper侧Runbook、Dubbo注册发现 |
项目话术
我们项目里 ZooKeeper 主要用于 Dubbo 注册中心和少量协调场景。Provider 启动后把服务地址注册成临时节点，Consumer 订阅服务目录变化并缓存 Provider 列表。对于多实例定时任务或低频关键操作，会使用 Curator 的分布式锁或 LeaderLatch 做主备协调。但核心业务不会只依赖 ZK 锁，会配合幂等号、状态机、唯一约束和补偿任务，防止 Session 过期或客户端暂停导致的数据覆盖。
常见错误回答纠正
| 错误回答 | 为什么错 | 正确说法 |
|---|---|---|
| ZK 是数据库 | ZK 不适合大量业务数据 | ZK 是协调元数据组件 |
| Watcher 是消息队列 | Watcher 是一次性通知 | 可靠消息用 MQ |
| 连接断开锁就释放 | Session 未过期锁节点仍在 | Session 过期才删除临时节点 |
| ZK 锁绝对安全 | 客户端 GC 和 Session 过期仍有风险 | 用 Fencing Token 和业务兜底 |
| 节点越多越好 | 写入投票成本更高 | 常用 3 或 5 节点 |
本章小结
ZooKeeper 面试要围绕“协调”展开：znode 数据模型提供节点能力，临时节点表达存活，顺序节点表达排队，Watcher 表达变化通知，Session 管理客户端状态，ZAB 保证写入顺序和多数派一致。再结合项目说明注册中心、锁、选主、运维排查和业务兜底，答案才完整。