ZooKeeper底层原理

ZooKeeper 是 Apache 旗下的分布式协调服务 ，专为解决分布式系统中的一致性、容错和协调问题设计。其核心原理围绕ZAB 协议 （Zookeeper Atomic Broadcast，ZooKeeper 原子广播协议）、集群角色分工 、持久化机制 和Watcher 事件机制展开，以下从四大维度详细阐述其底层原理：

一、核心架构：Leader-Follower-Observer 角色分工

ZooKeeper 集群采用主从复制模式，节点分为三类角色，分工明确以实现高可用和性能优化：

Leader（领导者）：
- 集群的唯一写入口，负责处理所有客户端的事务请求（如创建/修改节点）。
- 将事务请求封装为事务 Proposal （包含全局唯一递增的 ZXID，用于保证顺序），并通过原子广播分发给所有 Follower。
- 协调集群状态，当半数以上 Follower 确认事务后，提交事务并通知所有节点同步。
Follower（跟随者）：
- 参与Leader 选举（当 Leader 失效时，通过投票选出新 Leader）。
- 接收 Leader 的事务 Proposal，写入本地事务日志并反馈 Ack（确认）。
- 处理客户端的非事务请求（如读取节点数据），并将写请求转发给 Leader。
Observer（观察者）：
- 不参与投票 ，仅负责同步 Leader 的数据 ，用于扩展集群的读性能（如处理大量查询请求）。
- 不影响写操作的吞吐量（因不参与投票），是集群横向扩展的关键角色。

设计目的 ：通过 Leader 集中处理写请求，Follower 参与一致性验证，Observer 扩展读能力，实现高可用 （Leader 失效可快速选举新 Leader）和高性能（读写分离）。

二、数据一致性：ZAB 协议的核心机制

ZooKeeper 的强一致性 由ZAB 协议 保证，该协议是专为 ZooKeeper 设计的原子广播协议 ，分为消息广播 （正常运行）和崩溃恢复（Leader 失效）两个阶段：

1. 消息广播阶段（正常运行）

当集群有半数以上节点（Leader + Follower）完成状态同步后，进入消息广播模式，处理客户端的写请求：

步骤 1：事务 Proposal 生成 ：Leader 接收客户端的写请求（如 create /node data），生成事务 Proposal （包含 ZXID，全局唯一递增），并将 Proposal 放入每个 Follower 的独立队列（按 FIFO 顺序发送）。
步骤 2：Follower 反馈 Ack ：Follower 接收 Proposal 后，写入本地事务日志 （确保持久化），并向 Leader 反馈 Ack（确认收到）。
步骤 3：提交事务 ：当 Leader 收到半数以上 Follower 的 Ack （如 3 节点集群需 2 个 Ack），向所有 Follower 发送 Commit 消息，要求提交事务。Follower 收到 Commit 后，应用事务到内存数据库，并向客户端返回成功响应。

关键特性：

顺序一致性 ：ZXID 保证事务按发起顺序执行（如先创建 /node再修改其数据，不会颠倒）。
原子性：事务要么全集群提交（半数以上 Ack），要么全集群回滚（未达半数）。

2. 崩溃恢复阶段（Leader 失效）

当 Leader 崩溃（如网络断开、机器宕机），集群进入崩溃恢复模式 ，核心目标是选举新 Leader 并恢复数据一致性：

步骤 1：选举新 Leader：

Follower 检测到 Leader 失效（如心跳超时），转换为 LOOKING 状态，开始投票选举新 Leader。

选举规则：
- 优先选择ZXID 最大的节点（确保新 Leader 拥有最新的事务数据）；
- 若 ZXID 相同，选择myid 最大 的节点（myid 是节点配置的唯一 ID，如 server.1=myid=1）。
步骤 2：数据同步：

新 Leader 选举成功后，与所有 Follower 进行数据同步：
- Leader 将未同步的事务 Proposal 发送给 Follower（按 ZXID 顺序）；
- Follower 应用事务到本地数据库，同步完成后向 Leader 反馈；
- Leader 确认半数以上 Follower 同步完成，集群退出恢复模式，进入消息广播阶段。

关键特性：

容错性 ：Leader 失效后，集群可在30 秒内（默认）选举新 Leader，恢复服务。
数据一致性：新 Leader 拥有最新的事务数据（ZXID 最大），同步后所有节点状态一致。

三、持久化机制：事务日志与快照

ZooKeeper 将全量数据存储在内存 （提高读性能），但为防止宕机数据丢失，采用事务日志 （WAL，Write-Ahead Logging）和数据快照（Snapshot）结合的持久化策略：

1. 事务日志（Transaction Log）

作用：记录所有修改数据的事务操作（如创建/修改节点），用于宕机后恢复数据。
实现细节：
- WAL 机制 ：事务操作先写入日志（log.2c01311231文件，后缀为 ZXID），再应用到内存数据库。确保"写日志成功"后才向客户端返回响应，避免数据丢失。
- 磁盘预分配 ：每个日志文件固定为 64MB（避免频繁扩容），未使用部分填充 0。
- 刷盘策略 ：日志写入后，通过 forceSync参数控制是否刷盘（默认 yes，确保数据持久化到磁盘）。

2. 数据快照（Snapshot）

作用：定期将内存中的全量数据 序列化到磁盘（snapshot.2c01311231文件），用于缩短宕机后的恢复时间（无需重放所有事务日志）。
实现细节：
- 触发条件 ：采用"过半随机"策略（避免所有节点同时生成快照，影响性能）：
  - 当记录的事务日志数量超过 snapCount/2 + randRoll（snapCount默认 10 万，randRoll为 0 到 snapCount/2的随机数）时，触发快照生成。
- 异步生成 ：快照生成过程由独立线程完成，不阻塞主流程（客户端请求仍可处理）。
- 文件格式 ：快照文件包含内存数据的全量序列化（如节点路径、数据、版本信息），用于宕机后快速恢复内存状态。

3. 恢复流程

当 ZooKeeper 宕机重启后，恢复过程如下：

加载快照：从最新的快照文件（ZXID 最大）加载内存数据。
重放事务日志 ：从快照对应的 ZXID 开始，按顺序重放事务日志（log.2c01311231），将未同步的事务应用到内存。
完成恢复：所有事务重放完成后，集群进入正常运行状态。

四、Watcher 事件机制：实时通知与异步回调

Watcher 是 ZooKeeper 实现事件驱动 的核心机制，允许客户端监听节点的状态变化 （如数据修改、子节点增减），并在变化时收到异步通知。

1. 核心概念

Watcher ：客户端注册的事件监听器 （实现 Watcher接口），用于监听特定节点的事件（如 NodeDataChanged、NodeChildrenChanged）。
事件类型：
- KeeperState ：客户端状态变化（如连接成功 SyncConnected、会话过期 Expired）；
- EventType ：节点事件（如创建 NodeCreated、数据修改 NodeDataChanged、子节点增减 NodeChildrenChanged、删除 NodeDeleted）。

2. 实现流程

Watcher 的工作流程分为注册、触发、通知三个阶段：

步骤 1：注册 Watcher：

客户端通过 getData()、exists()、getChildren()方法注册 Watcher（如 zk.getData("/node", true, callback)），将 Watcher 存储在客户端的 ZKWatchManager 中，并发送给 Server。
步骤 2：Server 存储 Watcher：

Server 接收 Watcher 后，将其存储在本地的 WatchManager 中（按节点路径关联，如 /node对应一组 Watcher）。
步骤 3：事件触发：

当节点状态变化（如 /node的数据被修改），Server 触发该节点的 Watcher，从 WatchManager 中移除对应的 Watcher，并向客户端发送通知事件 （WatcherEvent）。
步骤 4：客户端处理通知：

客户端收到通知后，通过 Watcher的 process()方法处理事件（如重新获取 /node的数据）。

3. 关键特性

一次性触发 ：Watcher 触发后，客户端需重新注册（如 getData()需再次设置 true），避免重复通知。
异步通知：通知通过 TCP 连接异步发送，不影响客户端的正常操作。
轻量级：通知仅包含事件类型、节点路径等最小信息（不包含数据内容），客户端需重新获取数据。

五、总结：ZooKeeper 原理的核心逻辑

ZooKeeper 的底层原理围绕**"一致性"** 和**"高可用"**展开，通过以下机制实现：

ZAB 协议：保证事务的顺序一致性和原子性，通过 Leader 广播和崩溃恢复处理写请求。
集群角色分工：Leader 处理写请求，Follower 参与一致性验证，Observer 扩展读性能，实现高可用。
持久化机制：事务日志（WAL）保证数据不丢失，快照（Snapshot）缩短恢复时间，确保宕机后数据可恢复。
Watcher 机制：实现事件驱动的实时通知，让客户端及时感知节点变化，简化分布式协调逻辑。

这些机制共同作用，使 ZooKeeper 成为分布式系统中**"协调服务"**的首选，广泛应用于配置管理、服务发现、分布式锁、集群管理等场景。

ZooKeeper底层原理

一、核心架构：Leader-Follower-Observer 角色分工

二、数据一致性：ZAB 协议的核心机制

**1. 消息广播阶段（正常运行）**​

**2. 崩溃恢复阶段（Leader 失效）**​

三、持久化机制：事务日志与快照

**1. 事务日志（Transaction Log）**​

**2. 数据快照（Snapshot）**​

3. 恢复流程​