java面试-zookeeper

关注

原创最新推荐文章于 2026-08-12 05:29:25 发布 934 阅读 AI 写同款· GEO 优化 ›

Java高级架构面试真题汇总：Nginx、 Netty、Zookeeper、Tomcat、Dubbo （一）Nginx是什么——相关面试题 Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器，并在一个BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等。 1、请列举Nginx的一些特性。 2、解释Nginx是... 阅读详情

1、什么是zap协议

ZAB 协议总共包含以下两部分内容：

ZAB 协议通过两阶段提交的方式来确保分布式系统的一致性。这两阶段分别是：准备阶段和提交阶段。在准备阶段，一个节点（称为 Leader）向其他节点（称为 Follower）发送提案，Follower 接受并确认提案。在提交阶段，Leader 将提案发送给所有节点，并等待多数节点的确认。一旦多数节点发送确认消息，Leader 就可以将提案确定为最终结果，然后通知所有节点进行更新。
ZAB 协议还包括了崩溃恢复机制，当 Leader 节点崩溃时，系统会选择一个新的 Leader 来取代原先的 Leader 节点。新的 Leader 通过比对已完成的事务日志和未完成的临时提案来进行恢复。

所以，ZAB 协议通过原子广播的方式，在分布式系统中实现了一致性和可靠性，保证了数据的一致性和正确性。

2、Zookeeper的选举过程是怎么样的

Zookeeper的选举过程大致如下：

无论何种原因导致进行Leader选举，集群的所有机器都处于试图选举出一个Leader的状态，即LOOKING状态，LOOKING机器会向所有其他机器发送消息，该消息称为投票（每台机器首次都是投票给自己）。
每台机器发出投票后，也会收到其他机器的投票，每台机器会根据一定规则来处理收到的其他机器的投票，并以此来决定是否需要变更自己的投票，这个规则也是整个Leader选举算法的核心所在。
在检查投票有效性时，会确保投票是否来自LOOKING状态的服务器的投票等。
本轮选举中，如果有服务器的得票数超过半数，那么该服务器就成为了本轮选举的Leader。例如在示例中，zk2得到了超过半数的票数，因此成为Leader。
如果集群中已经有了Leader，那么选举结束，其他机器不再参与选举。

3、zookeeper选举过程中为什么要停止服务

Zookeeper在选举过程中会停止服务，是因为选举Leader的过程中需要保证一致性。在这个阶段，Zookeeper集群中的所有节点都会参与选举，并且需要确保最终选出的Leader是正确的。为了达到这个目标，Zookeeper会暂停服务的执行，直到选举过程结束并选出Leader。这样可以避免在选举期间出现不一致的状态，从而保证Zookeeper服务的可用性和一致性。

4、ZooKeeper 如何进行崩溃修复？

在 ZooKeeper 中有三种节点类型，它们分别是：

Leader（主节点）：能够处理读写请求，也同时负责同步写事务请求给其他节点且需要保证事务的顺序性，是整个集群的老大。
Follower（跟随者）：只负责处理读请求，无权写，因此收到写请求需要转发给 Leader 处理，待 Leader 写完后再同步给 Follower。如果 Leader 挂了，那么 Follower 是有资格参与竞选的。
Observer（观察者）：和 Follower 一样，唯一不同的是，不参与 Leader 的选举，可以利用不参与 Leader 选举的特性用来线性扩展读的 QPS。

也就是说，所有写操作会先到 Leader 节点，然后 Leader 节点在通过 2PC（两阶段提交：预提交、ACK、确认提交等流程）来进行数据同步，当写入成功过半就认为信息写入成功。而跟随者和观察者是为了增加读性能的，只不过跟随者还可以通过竞选主节点来保证集群的稳定性。

了解了这些之后，我们再来看 ZooKeeper 崩溃修复的流程（也就是当主节点崩溃后的流程），咱们先假设 ZooKeeper 集群有两个节点，ServerA 和 ServerB，它的崩溃修复的选举流程如下：

各自投票：
1. ServerA 先投票给自己，投票信息包含节点 sid 和 zxid，sid 就是 myid（集群 ID，启动集群时必须设置的 ID，是在配置文件当中配置死的，整个集群内唯一），zxid 是事务 id，自增（每次写入操作时生成）。假设 ServerA 将票投给自己，那么投票信息就为 (1,1)。
2. ServerB 也投票给自己，假设 ServerB 的 sid 为 2 ，那么此时 ServerB 投票信息为 (2,1)。
投票广播：
1. 接下来 ServerA 和 ServerB 分别将自己的投票信息广播给集群中其他节点。也就是 ServerA 将（1,1）广播给 ServerB， ServerB 将（2,1）广播给 ServerA。
2. ServerA 收到 ServerB 的投票信息后，检查下 ServerB 的状态是否是本轮投票，以及是否是 LOOKING 寻主的状态。反之，ServerB 收到 ServerA 的投票信息后也是一样的。
投票对比：优先对比 zxid，其次对比 sid。ServerA 会将自己的投票和 ServerB 的投票进行对比，先对比 zxid 发现 zxid 一样，然后对比 sid，发现 ServerB 的 sid 大于 ServerA 的 sid，所以此时 ServerA 就会更改投票信息为 (2,1)，然后将投票信息再次发送出去。而 ServerB 不需要更新投票信息，但是下一轮还需要再次将投票发出去。
统计投票：每一轮投票都会统计每台节点的投票信息，判断是否有过半的节点收到了相同的投票信息，如果过半，则将投票过半的节点升级为 Leader。ServerA 和 ServerB 收到的投票信息都为 (2,1)，且数量来说，大于一半节点的数量，所以将 ServerB 选出来作为 Leader。
更新节点状态：ServerA 作为 Follower，更新状态为 FOLLOWING，ServerB 作为 Leader。