ZooKeeper面试题及答案.docx

ZooKeeper面试题及答案

一、基础篇（考察ZK核心认知）

问：什么是ZooKeeper？它最核心的作用是什么？

答：ZK是分布式协调服务，简单说就是帮分布式系统里的多个节点“传话、记状态、定规则”。核心作用有三个实际场景：一是服务注册发现（比如微服务里服务上线后在ZK建节点，客户端去读节点获取服务地址）；二是分布式锁（多个节点抢着建同一个临时顺序节点，谁建的节点序号最小谁拿到锁）；三是状态同步（比如集群里主节点挂了，通过ZK选新主，同步节点状态）。它的关键是保证“强一致性”，比如多个客户端同时读同一个节点，拿到的结果肯定一样。

问：ZK的数据节点（ZNode）有哪些类型？实际用的时候怎么选？

答：主要分4种，选的时候看业务场景：

持久节点：建了之后除非手动删，不然一直在。比如存静态配置（像数据库地址），配置不变就不用频繁动。

临时节点：跟客户端会话绑死，会话断了（比如客户端挂了、网络断了）节点自动删。适合服务注册，服务下线了节点自己消失，不用手动清理。

持久顺序节点：持久+节点名带自增序号（比如/node0000000001）。比如存分布式任务的执行记录，要按顺序排，还得长期保留日志。

临时顺序节点：临时+序号。最常用在分布式锁，比如多个节点抢锁时，每个节点建一个临时顺序节点，判断自己是不是最小的，是就拿锁，不是就等前一个节点删了再试；而且就算节点挂了，临时节点会删，锁不会僵住。

问：ZK集群为什么推荐奇数个节点？最少几个能正常工作？

答：因为ZK靠“过半投票”决定Leader（主节点）和数据写入，奇数节点能减少资源浪费，还能避免“脑裂”。比如3个节点，只要2个活的就能过半；4个节点也得3个活的才过半，比3个节点多浪费1个资源。最少得3个节点能正常工作——1个节点没法集群（单点故障），2个节点如果1个挂了，剩下1个没到“过半”（2的过半是2），没法选Leader，集群用不了。

二、进阶篇（考察核心机制理解）

问：ZK的Watcher机制是什么？用的时候有什么坑要注意？

答：Watcher是ZK的“事件监听”机制，比如客户端监听某个节点，节点数据变了、子节点增删了，ZK会给客户端发通知。比如服务注册发现里，客户端监听服务节点的父目录，服务上下线（子节点增删）时，客户端能实时收到通知。

坑点有两个：一是Watcher是“一次性的”，触发一次后就失效了，想继续监听得重新注册（比如客户端收到通知后，要再调用一次watch方法）；二是“惊群效应”，比如很多客户端都监听同一个节点，节点一变所有客户端都收到通知，可能导致服务压力大——解决办法是用Curator客户端的Cache机制（比如PathChildrenCache），它会自动重注册Watcher，还能批量处理通知，减少压力。

问：ZK的ZAB协议是干嘛的？崩溃恢复阶段怎么选Leader？

答：ZAB是ZK的核心协议，负责集群的数据同步和Leader选举，分两种场景：一是“消息广播”（Leader正常时，写请求先到Leader，Leader再同步给所有Follower，过半Follower确认后，再告诉客户端写成功）；二是“崩溃恢复”（Leader挂了，选新Leader，同步数据）。

崩溃恢复选Leader的规则：先比“zxid”（每个写操作的唯一ID，越大说明数据越新），zxid大的节点优先；如果zxid一样，再比“myid”（节点配置里的唯一ID，比如1、2、3），myid大的当选。比如节点Azxid=100、myid=2，节点Bzxid=99、myid=3，还是A当选，因为zxid更重要——要保证新Leader的数据是必威体育精装版的，避免数据回滚。

问：ZK的会话超时时间怎么设置？设太短或太长有什么问题？

答：会话超时是客户端和ZK集群的连接超时时间，默认是30秒，实际要按业务来定。设置依据是“客户端能接受的最大断连时间”——比如客户端是服务调用的消费者，服务调用超时是5秒，那会话超时可以设5-10秒，别太长。

问题：设太短的话，客户端网络波动一下（比如卡1秒），会话就断了，临时节点会被删（比如服务注册的节点没了，会被误判为服务下线）；设太长的话，客户端真的挂了（比如进程崩了），ZK要等很久才释放临时节点（比如设1分钟，就会有1分钟的“僵尸节点”），导致分布式锁僵住、服务列表里有无效地址。

三、实战篇（考察实际应用能力）

问：用ZK实现分布式锁的步骤是什么？怎么避免“羊群效应”？

答：步骤分四步：①客户端请求锁时，