Zookeeper

分布式信息共享中心

基于 CAP 定理中的 CP 模型

一、应用场景

• Master 选举

  • 临时节点创建成功成为 Master，未成功者监控临时节点

• 分布式锁

  • 排他锁 : 临时节点创建成功，表示获取锁，未成功者监控临时节点

  • 共享锁 :

    • 使用临时顺序节点

    • 如果是读请求，且序号比自己小的节点都是读请求，表示获取到共享锁

    • 如果是写请求，如果自己的序号不是最小，则需等待

      为避免 羊群效应，每个节点应只关注比自己序号小 1 号的节点即可

• 发布 / 订阅 通用配置

  • 机器列表

  • 开关配置

  • 数据库配置

    数据量小、内容动态变化、各机器配置一致

• 集群管理

  • 统计 集群机器 数量

  • 获取 机器上下线 情况

  • 监控 机器 状态

• 命名服务

  • 获取唯一 ID

二、角色

• Leader
  • 提供 读/写 服务
  • 事务请求的唯一 调度 与 处理 者，保证事务处理的顺序性
• Follower
  • 提供 读 服务
  • 转发事务请求给 Leader
  • 参与事务 Proposal 投票
  • 参与 Leader 选举
• Observer
  • 提供 读 服务
  • 不参与事务 Proposal、Leader 选举

三、会话 Session

• 客户端 与 服务端 之间的一个 TCP 长连接，使用 心跳检测 保持有效会话

• 客户端 能够向 服务端 发送请求与接收响应

• 客户端 能够接收来自 服务端 的 Watch 事件的通知

四、数据节点 Znode

有两种含意 1. 机器节点 2. 数据单元

• Zookeeper 中最小的数据单位，Znode 下面可以再挂 Znode，形成 Znode Tree - Znode Tree 中，使用 / 分割路径

• 负责 保存自己的 数据内容、属性信息

• 分类

  • 持久性节点 Persistent
  • 临时性节点 Ephemeral
  • 顺序性节点 Sequential

• 具体类型

  • 持久节点
    • 一直存在，直到 手动删除
  • 持久顺序节点
    • 在节点后面加上数字后缀，用于表示顺序
  • 临时节点
    • 会被自动删除的节点
    • 与 客户端 会话绑定，当会话结束，节点删除
    • 不能创建子节点
  • 临时顺序节点
    • 有顺序的临时节点，在节点后面加上数字后缀，用于表示顺序

  

• 属性信息

  • cZxid : 节点被创建时的事务 ID

  • ctime : 节点创建时间

  • mZxid : 节点最后一次被修改的事务 ID

  • mtime : 节点最后一次被修改的时间

  • pZxid : 子节点列表【数量】最后一次被更改的事务 ID

  • cversion : 子节点版本号

  • dataVersion : 内容版本号

  • aclVersion : ACL 版本号

  • ephemeralOwner : 临时节点的会话 ID - 若为持久节点则该值为 0

  • dataLength : 数据长度

  • numChildren : 直系子节点个数

    孙子节点不算

• 版本

  • version : 当前 Znode 的版本

  • cversion : 当前 Znode 子节点的版本

  • aversion : 当前 Znode 的 ACL 版本

五、事件监听器 Watcher

○ 采用 推拉相结合 模式

○ 服务端 向 客户端 发送 Watcher 事件通知，客户端 收到通知后，主动向 服务端 获取最新数据

• 用于实现 发布/订阅 功能

• 客户端 可以在指定的 Znode 上注册 Watcher，当特定事件触发(Znode 内容 或其 子节点列表 发生变更时)时，服务端 会将事件通知到感兴趣的 客户端

• 注册 流程

  1. 客户端 向 Zookeeper 发起注册请求
  2. 客户端 将 Watcher 对象存储到 自身的 WatcherManager 中

• 通知 流程

  1. Zookeeper 触发 Watcher 事件，向 客户端 发送通知

  2. 客户端线程 从 WatcherManager 中取出对应的 Watcher 对象运行回调逻辑

六、权限控制策略 ACL

Access Control Lists

1. 权限模式 Scheme

• IP
  • 透过 IP 地址粒度进行权限控制
  • 授权对象 : IP 地址 或 IP 段
• Digest
  • 使用 "username:password" 形式配置权限标示
  • 授权对象 : 自定义，通常是 username:BASE64(SHA-1(username:password)) 。例如，zm:sdfndsllndlksfn7c=
• World
  • 最开放的权限控制模式，几乎没有作用
  • 授权对象 : 只有一个，anyone
• Super
  • 超级用户，可以对任意的 Znode 进行操作
  • 授权对象 : 超级用户

2. 权限 Permission

• CREATE : 创建【子节点】的权限
• READ : 获取 节点数据、子节点列表 的权限
• WRITE : 更新 节点数据 的权限
• DELETE : 删除【子节点】的权限
• ADMIN : 设置 节点 ACL 的权限

七、ZAB 协议

○ ZAB 相较于 Paxos 只有一个 Proposer，故不存在同一个提案有多个提案内容的问题，所以没有投票提案内容的阶段，只需要确定 Follower 是否存活，能否运行事务即可

○ Follower 响应过半则发送 Commit 消息运行事务，比较类似于 两阶段提交 2PC

1. 事务

• 能够改变 Zookeeper 服务端状态 的操作 - Znode 创建、删除、更新
• 对每个事务请求，分配一个 事务ID(ZXID) 来表示 - 64位数字，可以识别请求的全局顺序

2. 消息广播流程

1. Leader 收到客户端请求，生成对应事务的 Proposal，并将其发送给 Follower
2. Follower 收到 Proposal，将其以事务日志形式写入到硬盘中，并返回 ACK 给 Leader
3. Leader 收到过半数的 ACK 响应，就会广播 Commit 消息给所有的 Follower
4. Follower 收到 Commit 消息，就会将事务进行提交

八、崩溃恢复

1. Leader 选举

保证选举出的新 Leader 的 ZXID 最大，即可确保

1. 已经在 Leader 服务器上提交的事务，最终被所有服务器都提交

2. 丢弃只在 Leader 服务器上被【提出】(不是提交)的事务

2. 数据同步流程

1. Leader 为每个 Follower 准备一个队列

2. Leader 将没有被 Follower 同步的事务以 Proposal 消息的形式发送给 Follower

3. Leader 在每个 Proposal 消息后面紧接着再发送一个 Commit 消息

4. 当 Follower 将所有未同步事务从 Leader 同步过来后，Leader 就会将 Follower 加入到可用 Follower 列表中