Zookeeper面试常见问题解析

ZAB协议详解

ZAB（Zookeeper Atomic Broadcast）协议是专为Zookeeper设计的支持崩溃恢复的原子广播协议，确保了分布式环境下的数据一致性。ZAB协议主要包含两个阶段：崩溃恢复和消息广播。

在崩溃恢复阶段，当Zookeeper集群启动或Leader节点发生故障时，所有节点将进入此阶段以选举新的Leader，并完成数据同步。一旦超过半数的节点完成了与新Leader的数据同步，集群将切换至消息广播阶段，此时Leader开始处理客户端的事务请求。

ZooKeeper节点类型

• PERSISTENT: 持久节点，除非显式删除，否则始终存在。
• EPHEMERAL: 临时节点，与创建它的客户端会话绑定，会话结束时自动删除。
• PERSISTENT_SEQUENTIAL: 带有序号的持久节点，创建时自动添加一个递增的序号。
• EPHEMERAL_SEQUENTIAL: 带有序号的临时节点，同样在创建时添加序号。

ACL权限控制机制

ACL（Access Control List）用于定义对ZooKeeper节点的访问权限，包括多种权限模式如IP、Digest、World等，其中Digest是最常用的模式，通过用户名和密码进行身份验证。ACL权限分为CREATE（创建）、DELETE（删除）、READ（读取）、WRITE（写入）和ADMIN（管理）五种。

ZooKeeper的角色

• Leader: 负责处理事务请求，保证事务的顺序性和集群内部的调度。
• Follower: 处理非事务请求，参与Leader选举和事务提案投票。
• Observer: 从3.3.0版本开始引入，主要处理非事务请求，不参与任何投票过程，提高了集群的非事务处理能力。

ZooKeeper服务器状态

ZooKeeper服务器具有四种工作状态：LOOKING（寻找Leader）、FOLLOWING（跟随者）、LEADING（领导者）和OBSERVING（观察者）。每种状态反映了服务器在集群中的角色和行为。

Watch机制

Watch机制不是永久的，它是一次性的触发器，当监控的数据发生变化时，客户端会收到一次通知，之后Watch即失效。

常用客户端

常见的ZooKeeper客户端包括Java客户端zkclient和Apache Curator，这些客户端提供了丰富的API来简化ZooKeeper的操作。

分布式锁实现

在ZooKeeper中实现分布式锁通常有两种方法：基于临时顺序节点和基于临时节点。具体实现细节可参考相关课程代码。

默认通信框架

ZooKeeper默认使用NIO作为通信框架，但也可以配置为使用Netty。

消息广播流程

消息广播流程包括：Leader接收消息请求，分配唯一的zxid，将提案分发给所有Follower；Follower接收到提案后写入磁盘并返回ACK；Leader接收到足够多的ACK后发送COMMIT命令，Follower执行消息。

领导选举流程

领导选举流程涉及每个服务器发起投票、收集投票、处理投票、统计投票结果以及改变服务器状态。选举过程中优先级高的服务器（根据ZXID和myid决定）更有可能成为新的Leader。