zookeeper 相关知识点

1.系统架构

zookeeper 分为服务器端（server）和客户端（client），客户端可以连接到整个 zooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不允许接受客户端连接）。客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断，客户端将自动尝试连接到另外的 zooKeeper 服务器。客户端第一次连接到 zooKeeper 服务时，接受这个连接的 zooKeeper 服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。
这里写图片描述
需要注意 session 机制。 client 连接 server 成功后， server 赋予该 client 一个 sessionid，client 需要不断发送心跳维持 session 有效，在 session 有效期内，可以使用 Zookeeper 提供的 API 进行操作。如果因为某些原因导致 client 无法正常发送心跳，在超时时长后， server会判断该 client 的 session 失效，此时 client 发送的任何操作都会被拒绝，并触发ExpiredException 异常，此时 KeeperState 处于 Expired 状态。但 client 有自动重连 server 的机制，如果 client 的心跳无法正常连接 server，会在 session超时前尝试连接其他 server，连接成功后可以继续操作。如果 client 取消当前连接并连接其他 server，已存在的 watches 会丢失，取而代之的是client 会生成一个特殊 WatchEvent 告诉本地 watcher 连接已经丢失。

2. zookeeper的角色

启动 zookeeper 服务器集群环境后，多个 Zookeeper 服务器在工作前会选举出一个 Leader。选举出 leader 前，所有 server 不区分角色，都需要平等参与投票（observer 除外，不参与投票），选主过程完成后，存在以下几种角色：

leader：领导者，可以接受 client 请求，也接收其他 server 转发的写请求，负责更新系统状态。
follower：可以接收 client 请求，如果是写请求将转发给 leader 来更新系统状态。
observer：同 follower，唯一区别就是不参与选主过程。observer的目的是为了扩展系统，提高读取速度。

3. 数据模型

zookeeper 提供一种类似目录树结构的数据模型，每个节点（znode）具有唯一的路径标识，而路径是由斜线分隔开的路径名序列组成，和标准的文件系统非常类似。例如对dubbo在zookeeper上存储的数据模型如下
这里写图片描述

4. znode

znode 兼具文件和目录两种特点，既像文件一样维护着数据、元信息、 ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子 znode。用户对 znode具有增、删、改、查等操作（权限允许的情况下）。znode 具有原子性操作，每个 znode 的数据将被原子性地读写，读操作会读取与 znode相关的所有数据，写操作会一次性替换所有数据。
zookeeper 并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以 KB 为大小单位。 zooKeeper 的服务器和客户端都被设计为严格检查并限制每个 znode 的数据大小至多 1M，当时常规使用中应该远小于此值。
需要额外注意以下几点：

znode 中的数据可以有多个版本，在查询该 znode 数据时就需要带上版本信息。（set path version / delete path version）
znode 可以是临时 znode（create -e 生成的节点），一旦创建这个 znode 的 client 与server 断开连接，该 znode 将被自动删除。 client 和 server 之间通过 heartbeat 来确认连接正常，这种状态称之为 session，断开连接后 session 失效。
临时 znode 不能有子 znode。
znode 可以自动编号（create -s 生成的节点），例如在 create -s /app/node 已存在时，将会生成 /app/node00***001 节点。
znode 可以被监控，该目录下某些信息的修改，例如节点数据、子节点变化等，可以主动通知监控注册的 client。事实上，通过这个特性，可以完成许多重要应用，例如配置管理、信息同步、分布式锁等等。

org.apache.zookeeper.CreateMode 中定义了四种节点类型，分别对应：

PERSISTENT：永久节点
EPHEMERAL：临时节点
PERSISTENT_SEQUENTIAL：永久节点、序列化
EPHEMERAL_SEQUENTIAL：临时节点、序列化

5. 版本

zooKeeper 的每个 znode 上都会存储数据，对应于每个 znode ，zooKeeper 都会为其维护一个叫作 Stat 的数据结构，Stat 中记录了这个 znode 的三个数据版本，分别是 version（当前znode 的版本）、cversion（当前znode 子节点的版本）和 aversion（当前 znode 的 ACL 版本）。

6. sessions

会话对于ZooKeeper的操作非常重要。会话中的请求按FIFO顺序执行。一旦客户端连接到服务器，将建立会话并向客户端分配会话ID 。客户端以特定的时间间隔发送心跳以保持会话有效。如果ZooKeeper集合在超过服务器开启时指定的期间（会话超时）都没有从客户端接收到心跳，则它会判定客户端死机。会话超时通常以毫秒为单位。当会话由于任何原因结束时，在该会话期间创建的临时节点也会被删除。

7. watche机制

Zookeeper 客户端在数据节点上设置监视，则当数据节点发生变化时，客户端会收到提醒。 Zookeeper 中的各种读请求，如 getDate()， getChildren()，和 exists()，都可以选择加“监视点”(watch)。 “监视点”指的是一种一次性的触发器(trigger)，当受监视的数据发生变化时，该触发器会通知客户端。
监视机制有三个关键点：
a) “监视点”是一次性的，当触发过一次之后，除非重新设置，新的数据变化不会提醒客户端。
b) “监视点”将数据改变的通知客户端。如果数据改变是客户端 A 引起的，不能保证“监视点”通知事件会在引发数据修改的函数返回前到达客户端 A。对于“监视点”，Zookeeper 有如下保证：客户端一定是在接收到“监视”事件（watch event）之后才接收到数据的改变信息。
c) getData() 和 exists()设置关于节点数据的 “监视点”，并返回节点数据信息；getChildren()设置关于节点的“监视点”，并返回子节点信息。 setData()会触发关于节点数据的“监视点”。成功的 create()会触发所建立节点的数据“监视点”，和父节点的子节点“监视点”。成功的 delete()会触发所删除节点的数据“监视点”，和父节点的子节点“监视点”。
d) “监视点”保留在 Zookeeper 服务器上，则当客户端连接到新的 Zookeeper 服务器上时，所有需要被触发的相关“监视点”都会被触发。当客户端断线后重连，与它的相关的“监视点”都会自动重新注册，这对客户端来说是透明的。在以下情况， “监视点”会被错过：客户端 B 设置了关于节点 A 存在性的“监视点”，但 B 断线了，在B 断线过程中节点 A 被创建又被删除。此时， B 再连线后不知道 A 节点曾经被创建
过。
Zookeeper 的“监视”机制保证以下几点：
a) 监视”事件的触发顺序和分发顺序与事件触发的顺序一致。
b) 客户端将先接收到“监视”事件，然后才收到新的数据
c) 监视”事件触发的顺序与 Zookeeper 服务器上数据变化的顺序一致
关于 Zookeeper“监视”机制的注意点：
a) 监视点”是一次性的
b) 由于“监视点”是一次性的，而且，从接收到“监视”事件到设置新“监视点”是有延时的，所以客户端可能监控不到数据的所有变化
c) 一个监控对象，只会被相关的通知触发一次。如，一个客户端设置了关于某个数据点 exists 和 getData 的监控，则当该数据被删除的时候，只会触发“文件被删除”的通知。
d) 当客户端断开与服务器的连接时，客户端不再能收到“监视”事件，直到重新获得连接。所以关于 Session 的信息将被发送给所有 Zookeeper 服务器。由于当连接断开时收不到“监视”时间，所以在这种情况下，模块行为需要容错方面的设计。

8. ACL 控制

znode 还具有原子性操作的特点：命名空间中，每一个 znode 的数据将被原子地读写。读操作读出与数据节点相关联的所有数据，写则替换该节点上的所有数据。每个节点上的“访问控制链”(ACL, Access Control List)保存了各客户端对于该节点的访问权限。
zookeeper 利用访问控制链机制（Access Control List）控制客户端访问数据节点的权限，类似于 UNIX 文件的访问控制。但 zookeeper 对于用户类别的区分，不止局限于所有者(owner)、组 (group)、所有人(world)三个级别。 zookeeper 中，数据节点没有“所有者”的概念。访问者利用 id 标识自己的身份，并获得与之相应的不同的访问权限。
ZooKeeper 定义了如下5种权限。

CREATE: 创建子节点的权限。
READ: 获取节点数据和子节点列表的权限。
WRITE：更新节点数据的权限。
DELETE: 删除子节点的权限。
ADMIN: 设置节点ACL的权限。