zookeeper 学习笔记

基本概念

1. 角色 zookeeper 集群中的节点共有三种角色，每一个节点同时只能是一种角色。集群中的全部机器经过一个 Leader 选举过程来选定一台被称为 Leader 的机器。 Leader：接受全部 Follower 的提案请求并统一协调发起提案的投票，负责与全部的 Follower 进行内部的数据交换 Follower：直接为客户端服务并参与提案的投票，同时与 Leader 进行数据交换 Observer：直接为客户端服务但不参与提案的投票，同时也与 Leader 进行数据交换

2. 会话 zookeeper 中客户端启动时会与服务器创建一个 TCP 链接，从第一次链接创建开始，客户端会话的生命周期就开始了，经过这个链接，客户端可以经过心跳检测与服务器保持有效的会话，也可以向服务器发送请求并接受响应，还可以接收来自服务器的 watch 事件通知。

3. 节点 通常在分布式语境下的节点是指组成集群的每一台服务器，在 zookeeper 中还有另一层意思，称之为数据节点（ZNode）。  zookeeper 的整个名字空间的结构是层次化的，和 Linux 文件系统结构类似，是一颗树。名字空间的层次由斜杠（/）来进行分割，在名称空间里面的每个节点的名字空间由这个结点的路径来肯定。 每一个 ZNode 上都会保存本身的数据内容，同时还会保存一系列属性信息。

4. 版本 对于每一个 ZNode ，zookeeper 都会为它维护一个叫 Stat 的数据结构，Stat 中记录了 ZNode 的三个数据版本，version（当前ZNode数据内容的版本号）、cversion（当前ZNode子节点的版本号）、aversion（当前ZNode的ACL变动版本号）

5. watcher zookeeper 容许用户在指定节点上注册一些 watcher，而且在特定事件触发的时候，zookeeper 服务端会将事件通知到感兴趣的客户端，该机制是 zookeeper 实现分布式协调服务的重要特性。

客户端命令

这里列出经常使用的客户端命令，所谓客户端命令指使用 zkCli 链接到 zookeeper 服务器以后使用的命令，zkCli 链接的语法以下： zkCli -server host:port cmd args zkCli 是客户端可执行文件名，根据具体操做系统环境多是 zkCli.sh 或 zkCli.cmd host 是服务器IP或域名，port 是服务器端口号，若是有多个服务器地址则用逗号分隔 cmd 是具体命令、args 是命令的参数，也能够链接上服务器以后再执行命令。

1. 查看节点 ls /path 查看名为 /path 的子节点，但只能查看指定节点下的第一级的全部子节点。 ls2 /path 查看名为 /path 的子节点，而且能看到更新次数等属性信息。

2. 建立节点 create [-s] [-e] /path data 建立一个名叫 /path 的节点，并包含数据 data。加上 -s 表示建立的是顺序节点，加上 -e 表示建立的是临时节点，若是都不加则默认为建立持久节点。

3. 删除节点 delete /path 删除名为 /path 的节点

4. 设置节点数据 set /path data 设置名为 /path 的节点的数据为 data

5. 返回节点数据 get /path 返回名为 /path 的节点的数据和属性信息

6. 强制同步数据 sync /path 将名为 /path 的节点强制同步为最新的数据

7. 帮助信息 help 帮助命令，显示客户端支持的命令及语法格式

8. 退出 quit 退出当前客户端，会话结束。

运维命令

zookeeper 提供了一些四字命令用于获取 zookeeper 服务端的当前状态及相关信息，这些命令在系统运维时颇有用。用户在客户端能够经过 telnet 或 nc 向zookeeper 提交相应的命令，好比 nc 方式： echo cmd|nc host port cmd 是具体的命令（由于通常是四个字母因此又叫作四字命令），host 是zookeeper 服务器 IP 地址或域名，port 是 zookeeper 端口号

1. conf 显示服务配置的详细信息，好比数据文件目录、日志文件目录、间隔单位时间、选举算法、选举端口等。

2. cons 列出全部链接到服务器的客户端的彻底的链接／会话的详细信息。包括”接受 / 发送”的包数量、会话 id 、操做延迟、最后的操做执行等。

3. crst 重置全部链接。

4. dump 列出未经处理的会话和临时节点。

5. envi 显示关于服务器环境的详细信息，好比 zookeeper 版本、操做系统版本、jdk 地址等。

6. reqs 列出未经处理的请求。

7. ruok 测试服务是否处于正确状态。若是确实如此，那么服务返回“imok ”，不然不作任何相应。

8. stat 输出关于性能和链接的客户端的列表。

9. wchs 列出服务器 watch 的详细信息。

10. wchc 经过 session 列出服务器 watch 的详细信息，它的输出是一个与 watch 相关的会话的列表。

11. wchp 经过路径列出服务器 watch 的详细信息，它的输出是一个与 session 相关的路径。

上面列出的是一些经常使用的四字命令，更详细信息能够参考zookeeper的官方文档，里面的【ZooKeeper Commands】一节有具体介绍。

特性

1. 一致性 zookeeper 很好地保证在分布式高并发状况下节点的建立必定是全局惟一性，即保证客户端没法重复建立一个已经存在的数据节点。 根据 CAP 理论，分布式系统只能知足一致性（Consistence）、可用性（Availability）、分区容错性（partitioning)三项中的两项而不可能知足所有三项。对于 zookeeper 来讲，其实现了 A 可用性、P 分区容错性、C 中的写入强一致性，丧失的是 C 中的读取一致性。 更进一步解释，zookeeper 的一致性保证包括如下几点：

• 顺序一致性 一个客户端的更新将按照发送的顺序被写入到服务端。
• 原子性 更新要么成功，要么失败，没有部分结果。
• 单一系统镜像 客户端只会链接 host 列表中状态最新的那些实例。若是正在链接到的实例挂了，客户端会尝试从新链接到集群中的其余实例，那么此时滞后于故障实例的其它实例都不会接收该链接请求，只有和故障实例版本相同或更新的实例才接收该链接请求。
• 持久性 写操做完成以后将会被持久化存储，不受服务器故障影响。
• 并发一致性 zookeeper 并不保证在某个时刻两个不一样客户端具备一致的数据视图，由于网络的延迟一个客户端可能在另外一个客户端获得修改通知以前进行更新。若是不一样客户端读取到相同的值很重要，那么客户端应该在执行读取操做以前调用 sync() 方法，使得读操做的链接所连的 zookeeper 实例能与 leader 进行同步，从而能读到最新的类容。

2. watcher 监听 客户端若是对一个节点注册 watcher 监听，那么当该节点的内容或其子节点发生变动时，zookeeper 服务器会向订阅的客户端发送变动通知。

3. 临时节点 对在 zookeeper 上建立的临时节点，一旦客户端与服务器之间的会话失效，那么该临时节点就被自动清除。

4. 顺序节点 客户端申请建立该节点时 zookeeper 会自动在节点路径末尾添加递增序号

应用场景

1. 数据订阅发布 将应用中的配置信息放在 zookeeper 中集中管理。应用在启动时主动到zk服务端进行一次配置信息的获取，同时在指定节点注册一个 watcher 监听。这样只要配置信息发生变动，服务端都会实时通知到全部订阅的客户端。

2. 域名服务 将域名配置信息放在 zookeeper 上，对外提供一套域名注册、域名解析、域名可用性检测的服务。基于此提供一套动态的 DNS 服务。

3. 全局惟一 ID 能够利用顺序节点的特性生成全局惟一的 ID。

4. 分布式协调通知 利用 watcher 监听实现系统间的协调和通知，从而实现数据变动的处理。不一样客户端都对 zookeeper 上同一个数据节点进行 watcher 注册，若是数据节点发生变化，那么全部订阅的客户端都能受到通知。

5. Master 选举 利用 zookeeper 建立节点时的强一致性，由客户端集群定时往 zookeeper 上建立同一个名字的临时节点。在这个过程当中只有一个客户端可以建立成功，那么该客户端就成了 Master，同时其余没有建立成功的客户端都在该节点注册一个节点变动的 watcher，用于监控当前 Master 机器是否存活，一旦发现 Master 挂掉其他客户端从新进行 Master 选举。

6. 分布式锁

• 排他锁 利用强一致性，将 zookeeper 上的一个临时节点表示为一个排他锁，全部客户端同时建立该节点，最终只有一个客户端能建立成功，那么就认为该客户端得到了锁，同时注册该节点的 watcher 监听。当移除该节点就认为释放了锁。

• 共享锁 利用强一致性，将 zookeeper 上的一个临时顺序节点表示为一个共享锁，并注册同级子节点的 watcher 监听。判断读写顺序时根据不一样需求关注比本身序号小的同级子节点类型。