zookeeper 要义简述

ZooKeeper 是一款面向分布式应用的高性能协调服务。

它通过一个简单的接口来提供常用服务：命名、配置管理、同步和组服务（例如节点注册和发现）

它本质上是一个强一致性的分布式键值存储系统，但用途并不限于存储，更在于协调和管理。

能力

ZooKeeper 核心原理（怎么做到的）

ZooKeeper 通过以下核心机制实现其功能：

数据模型（类似文件系统）

所有数据节点称为 ZNode，路径类似于文件系统，如 /config/app1/db_url

节点分为 持久节点 和 临时节点，也可设置为顺序节点

一致性协议：Zab（ZooKeeper Atomic Broadcast）

自研协议，类似 Raft/Paxos，用于实现分布式一致性

1. 写操作：只能由 Leader 发起
2. 所有写操作都通过 广播（Broadcast）+ 多数确认 实现提交
3. 新 Leader 选举会保证选出日志最完整的节点，防止数据丢失

Watcher 机制（事件通知）

客户端可以对节点设置 Watcher

节点变更（数据变化、节点上下线）时通知客户端

实现了分布式系统的 事件监听/回调机制

高可用集群机制

ZooKeeper 集群通过奇数台机器组成（推荐 3/5/7 节点）

通过多数机制（Quorum）容错

节点间通信通过 TCP，端口默认 2888 和 3888

ZooKeeper 自身的 Leader 选举（内部使用 Zab 协议）

ZooKeeper 集群中所有 写操作（create、delete、setData）只能由 Leader 处理，Follower 只负责转发请求、参与投票。

因此，ZooKeeper 的 Leader：

1. 处理所有客户端的写请求
2. 负责数据同步（广播事务日志）
3. 负责调度事务提交
4. 保证集群顺序一致性（强一致性）

Leader 选举的触发时机

1. 集群首次启动
2. 当前 Leader 节点宕机或失联
3. 集群半数以上节点重新启动或网络恢复

每个节点都维护了两个值，用于选举使用

选举步骤：

1. 所有节点进入 “Looking” 状态，开始选举
2. 每个节点广播自己的选票，包括 sid、zxid
3. 选举原则（优先级）： zxid（最新事务 ID）大者优先 sid（服务器 ID）大者优先 当竞选者识别到自己更小时，就会将选票投给另外一个，自己记录并广播出去
4. 投票达成“法定多数”（quorum）后： 所有节点认定同一个节点为胜出者 胜出者变为 Leader，状态变为 LEADING 其他节点变为 Follower，状态变为 FOLLOWING
5. 新 Leader 启动数据同步阶段，Follower 同步数据 对于 txid，每当选举出一个新的 Leader 后，新的 Leader 就从本地事务日志中取出 ZXID， 然后解析出高 32位的周期编号，进行加 1，再将低32位的全部设置为0，重新开始记数 ZXID。

应用举例

分布式锁的实现步骤（公平锁）

ZooKeeper 实现分布式锁主要基于两个机制：

1. 临时节点（Ephemeral Node）
2. 顺序节点（Sequential Node）

以“公平排队式分布式锁”为例：

使用临时的顺序节点

/lock/lock-00000001 
/lock/lock-00000002
...

1. 客户端尝试在某个路径（比如 /lock）下 创建一个临时顺序节点：
2. 客户端调用 getChildren("/lock") 获取所有节点列表，并按顺序排序。
3. 如果自己创建的是最小编号的节点（如 lock-00000001），即获得锁。
4. 如果不是最小节点，监听自己前一个节点（比如你是 lock-00000003，就监听 lock-00000002 的删除事件）。
5. 当前一个节点被删除（前一个客户端释放锁），触发 watcher，当前客户端再次判断自己是否为最小节点，若是则获得锁。
6. 处理完任务后，删除自己的节点，释放锁。

基于 ZooKeeper 实现业务系统中的 Leader 选举（开发者使用）

核心逻辑和分布式锁类似：

1. 所有候选节点（客户端）都往某个路径下创建临时顺序节点
2. 编号最小的节点即为 Leader
3. 所有其他客户端监听比自己小的前一个节点，一旦前者下线，触发选举