ZooKeeper

Thu, 22 Mar 2018 22:21:04 +0800

ZooKeeper 核心原理

数据模型：
1. ZNode：树形结构中的节点，存储数据（<=1MB）
2. 节点类型
  1. 持久节点：手动删除
  2. 临时节点：会话结束自动删除
  3. 顺序节点：名称追加单调递增序号
3. 版本号：每个 ZNode 有版本号，用于 CAS操作
架构与角色：
1. Leader：处理写请求，发起提案
2. Follower：参与选举，处理读请求
3. Observer：拓展读性能，不参与选举
ZAB 协议（ZooKeeper Atomic Broadcast）
1. 恢复模式：选举 Leader （基于 zxid 和 myid，半数以上投票）
2. 广播模式：Leader 提出事物，半数以上 Follower 确认后提交
一致性保护：
1. 顺序一致性（客户端操作按顺序执行）
2. 原子性（事物要么全成功要么全失败）
3. 最终一致性（读请求可能返回旧值，但最终同步）
Watch 机制：
1. 客户端监听 ZNode 变化（如节点删除，数据更新）
2. 一次性触发，需要重新注册
3. 异步通知，可能存在延迟或丢失

ZooKeeper 如何保证数据一致性？
- 答：通过 ZAB 协议，写操作需要半数以上节点确认，保证顺序一致性和原子性。读请求可能来自任意节点（可能读到旧数据），但可通过 sync 操作强制读取最新值。
临时节点的作用时什么？
- 答：临时节点在会话结束后自动删除，常用于服务注册（服务下线自动清除）和分布式锁（客户端崩溃自动释放锁）。
如何处理脑裂问题？
- 答：ZAB 协议要求写操作必须由 Leader 发起，且需要半数以上节点确认。网络分区时，仅拥有多数节点的分区能选举 Leader，另一个分区无法写入，避免数据不一致。
Watcher 机制有哪些主要事项？
- 答：一次性触发、通知可能延迟、需要处理事件丢失（如 Watch 注册期间发生变更）。需在回调中重新注册 Watcher。
Leader 选举过程是怎样的？
- 答：节点启动时进入选举状态，投票优先给 zxid 最大的节点，zxid 相同则选 myid 更大的。获得半数以上投票的节点成为 Leader。
如何实现分布式锁？
- 答：客户端创建临时顺序节点，检查是否为最小序号节点。若是则获得锁；否则监听前一个节点的删除事件，使用 exists() +Watcher 避免轮询。