一、ZooKeeper概述

ZooKeeper是一个开源的分布式协调服务，由Apache维护。官网描述为“致力于开发和维护实现高度可靠的分布式协调的开源服务器”。它被广泛应用于Solr、Hadoop等分布式系统中，提供集群管理、配置维护、命名服务、分布式同步等功能。

ZooKeeper支持三种部署模式：

• 独立部署模式：单机运行，适用于学习基础功能。

• 伪分布式模式：单台机器运行多个ZooKeeper实例，模拟集群，适用于开发测试。

• 全分布式模式：多台机器部署，真正的集群模式，可投入生产环境。

---

二、ZooKeeper集群角色

ZooKeeper集群由多个Server组成，分为三种角色：

• Leader：集群的领导者，处理所有写请求，发起并完成事务投票。

• Follower：跟随者，处理读请求，参与Leader选举和写请求投票。

• Observer：观察者，处理读请求，不参与投票，用于提升集群读性能（提高伸缩性而不影响吞吐率）。

---

三、数据模型（ZNode）

ZooKeeper的数据模型类似Linux文件系统，采用层次化命名空间，每个节点称为ZNode。每个ZNode由三部分组成：

• stat：状态信息（版本、权限、时间戳等）

• data：关联的数据

• children：子节点列表

以根节点“/”为起点，展示如“/hello”、“/app1”等子节点，并用图标区分持久节点、临时节点、顺序节点。

ZNode的类型：

• 持久节点（PERSISTENT）：创建后永久存在，需主动删除。

• 临时节点（EPHEMERAL）：与客户端会话绑定，会话结束自动删除，且不能有子节点。

• 持久顺序节点（PERSISTENT_SEQUENTIAL）：持久节点基础上自动附加递增序号。

• 临时顺序节点（EPHEMERAL_SEQUENTIAL）：临时节点基础上自动附加递增序号。

用表格或分类图示展示四种节点的创建方式、生命周期、是否有序等特性。

---

四、ZooKeeper核心工作原理

1. 数据流程（写请求处理）

写请求必须由Leader处理，流程如下：

1. Client向Follower发出写请求。

2. Follower将请求转发给Leader。

3. Leader发起投票（Proposal），通知所有Follower投票。

4. Follower将投票结果返回给Leader。

5. Leader汇总结果，如果获得半数以上ACK，则提交事务（Commit）。

6. Follower将执行结果返回给Client。

用泳道图或时序图展示Client、Follower、Leader三者间的交互步骤。

2. Follower的消息循环处理

Follower在运行过程中会循环处理来自Leader的以下几种消息：

• PING消息：心跳消息。

• PROPOSAL消息：Leader发起的提案，要求Follower投票。

• COMMIT消息：服务器端最新一次提案的提交信息。

• UPTODATE消息：表明同步完成。

• REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session或允许其接受消息。

• SYNC消息：返回SYNC结果到客户端，用来强制得到最新的更新

3. Leader选举流程（Zab协议的恢复模式）

ZooKeeper的核心是原子广播（Zab协议），分为恢复模式（选主）和广播模式（同步）。当服务启动或Leader崩溃时进入恢复模式，选举过程如下：

1. 每个Server启动后都会推荐自己作为Leader（投票依据：zxid和myid）。

2. Server向其他Server询问它们要投票给谁。

3. 每个Server根据收到的回复，计算出zxid最大的Server，并将其作为下一次投票的对象。

4. 统计得票数，若某Server获得超过半数的票，则当选为Leader。

5. 当选的Leader等待Follower连接。

6. Follower连接Leader，并将自身最大的zxid发送给Leader。

7. Leader根据Follower的zxid确定同步点。

8. 完成同步后，Leader通知Follower进入uptodate状态。

9. Follower收到uptodate消息后，开始接受Client请求。

用流程图展示从启动推荐、投票比较、过半当选到状态同步的完整过程。

4. Zab协议的广播模式

选举完成后，集群进入广播模式：

• Leader接受写请求，生成事务Proposal并分配递增的zxid（64位：高32位epoch标识Leader任期，低32位递增计数）。

• Leader向所有Follower广播Proposal。

• Follower写入本地日志后返回ACK。

• 收到半数以上ACK后，Leader提交事务并通知Follower。

---

五、数据一致性与Paxos算法

分布式数据一致性的三个级别：

• 强一致性：更新成功后，客户端立即能看到最新数据。

• 弱一致性：更新成功后，客户端不一定立即看到。

• 最终一致性：经过一段时间后，客户端最终能看到更新。

ZooKeeper通过Zab协议（基于Paxos思想）实现强一致性。Paxos算法的核心是：

通过投票对写操作进行全局编号，同一时刻只有一个写操作被批准。只有获得过半数选票的写操作才会被提交。任何节点挂掉都不影响集群数据一致性（集群总节点数为2n+1，最多允许n台挂掉）。

---

六、ZooKeeper的典型操作（命令行示例）

中给出了常用命令：

操作	命令示例	说明
连接Server	bin/zkCli.sh -server 192.168.58.99:2181	建立会话
列出节点	ls /	列出根节点下的子节点
创建节点	create /hello world	创建持久节点并关联数据
创建临时节点	create -e /temp data	会话结束自动删除
创建顺序节点	create -s /seq data	自动附加递增序号
获取节点数据	get /hello	返回数据和状态信息
删除节点	delete /hello/item01	需先删除子节点
递归删除	rmr /hello	删除节点及其所有子节点
监听子节点变化	ls /path true	注册Watcher
监听节点数据变化	get /path true	注册Watcher

---

七、ZooKeeper的五大特性

总结了ZooKeeper的五个核心特性：

---

八、ZooKeeper集群部署要点

1. 集群节点数为什么一般为奇数？

• 如果有3个Server，最多允许1个挂掉（半数以上为2票）。

• 如果有4个Server，同样最多允许1个挂掉（半数以上为3票）。

• 3台和4台容灾能力相同，但4台浪费资源，因此生产环境通常使用奇数节点（3、5、7）。

2. 配置文件（zoo.cfg）与myid

• 所有节点的zoo.cfg内容相同，通过server.x=host:port1:port2指定集群成员。

• 每个节点的dataDir目录下需要有myid文件，内容为对应的数字（与server.x中的x一致）。

3. 启动与状态查看

bash

# 启动ZooKeeper
zkServer.sh start

# 查看状态
zkServer.sh status

启动后，集群会自动选举出Leader。例如在hadoop1上执行zkServer.sh status可能显示Mode: follower，在hadoop2上可能显示Mode: leader。

模拟终端输出，展示不同节点上zkServer.sh status的结果。

---

总结

ZooKeeper通过ZNode数据模型、Watcher机制、Zab原子广播协议和Leader选举，为分布式系统提供了可靠、高效的协调服务。理解其工作原理（尤其是Zab协议的恢复模式与广播模式）以及数据一致性保证，是解决配置管理、服务发现、分布式锁等实际问题的关键。