概念

ZooKeeper 为我们提供了高可用、高性能、稳定的分布式数据一致性解决方案，通常被用于实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
另外，ZooKeeper 将数据保存在内存中，性能是非常棒的。 在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景）。

特点：

  1. 顺序一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到zookeeper中去。
  2. 原子性：所有事务请求地处理结果再整个集群中所有机器上地应用情况是一致地，也就是说，要么整个集群中所有地机器都成功应用了某一个事务，要么都没有应用。
  3. 单一系统映像 ： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
  4. 可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

应用场景：

  1. 分布式锁 ： 通过创建唯一节点获得分布式锁，当获得锁的一方执行完相关代码或者是挂掉之后就释放锁。
  2. 命名服务 ：可以通过 ZooKeeper 的顺序节点生成全局唯一 ID
  3. 数据发布/订阅 ：通过 Watcher 机制 可以很方便地实现数据发布/订阅。当你将数据发布到 ZooKeeper 被监听的节点上，其他机器可通过监听 ZooKeeper 上节点的变化来实现配置的动态更新。

    重要概念

    数据模型

    zookeeper数据模型采用层次化的多叉树形结构，每个节点上都可以存储数据，这些数据可以是数字、字符串或者二进制数据。每个节点还可以拥有 N 个子节点，最上层是根节点以“/”来代表。每个数据节点在 ZooKeeper 中被称为 znode，它是 ZooKeeper 中数据的最小单元。并且，每个 znode 都一个唯一的路径标识。

强调一句：ZooKeeper 主要是用来协调服务的，而不是用来存储业务数据的，所以不要放比较大的数据在 znode 上，ZooKeeper 给出的上限是每个结点的数据大小最大是 1M。

znode-structure.19119dbd.jpg

数据节点（znode）

四种类型

  1. 持久节点：一旦创建就一直存在，即使zk集群宕机，知道将其删除

  2. 临时节点：临时节点的生命周期是与客户端会话绑定的，会话消失节点消失。并且，临时节点只能做叶子节点，不能创捷子节点

    很好理解：如果临时节点可以创建子节点，那么当当前节点消失的时候怎么去维护子节点呢？

  3. 持久顺序节点：除了具有持久（PERSISTENT）节点的特性之外， 子节点的名称还具有顺序性。比如 /node1/app0000000001 、/node1/app0000000002 。

  4. 临时顺序节点：除了具备临时（EPHEMERAL）节点的特性之外，子节点的名称还具有顺序性。

    znode数据结构

    每个znode由两个部分组成：
  • state：状态信息
  • data：节点存放的数据的具体内容

可以通过get指令获取相应节点的信息

znode 状态信息 解释
cZxid create ZXID，即该数据节点被创建时的事务 id
ctime create time，即该节点的创建时间
mZxid modified ZXID，即该节点最终一次更新时的事务 id
mtime modified time，即该节点最后一次的更新时间
pZxid 该节点的子节点列表最后一次修改时的事务 id，只有子节点列表变更才会更新 pZxid，子节点内容变更不会更新
cversion 子节点版本号，当前节点的子节点每次变化时值增加 1
dataVersion 数据节点内容版本号，节点创建时为 0，每更新一次节点内容(不管内容有无变化)该版本号的值增加 1
aclVersion 节点的 ACL 版本号，表示该节点 ACL 信息变更次数
ephemeralOwner 创建该临时节点的会话的 sessionId；如果当前节点为持久节点，则 ephemeralOwner=0
dataLength 数据节点内容长度
numChildren 当前节点的子节点个数

版本控制

  • dataVersion ：当前 znode 节点的版本号
  • cversion ： 当前 znode 子节点的版本

  • aclVersion ： 当前 znode 的 ACL 的版本。

    ACL权限控制

    Zookeeper采用ACL策略进行权限控制，类似于Unix文件系统的权限控制
    对于zookeeper的操作权限，有以下五种：

  • CREATE : 能创建子节点

  • READ ：能获取节点数据和列出其子节点
  • WRITE : 能设置/更新节点数据
  • DELETE : 能删除子节点
  • ADMIN : 能设置节点 ACL 的权限

CREATE 和 DELETE 这两种权限都是针对 子节点 的权限控制。
对于身份认证，以下四种身份认证方式：

  • world ： 默认方式，所有用户都可无条件访问。
  • auth :不使用任何 id，代表任何已认证的用户。
  • digest :用户名:密码认证方式： username:password 。
  • ip : 对指定 ip 进行限制。

    事件监听器（watcher）

    ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是 ZooKeeper 实现分布式协调服务的重要特性。
    watche机制.f523bd89.jpg

    会话

    Session 可以看作是 ZooKeeper 服务器与客户端的之间的一个 TCP 长连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的 Watcher 事件通知。

Session 有一个属性叫做：sessionTimeout ，sessionTimeout 代表会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

另外，在为客户端创建会话之前，服务端首先会为每个客户端都分配一个 sessionID。由于 sessionID是 ZooKeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的，因此，无论是哪台服务器为客户端分配的 sessionID，都务必保证全局唯一。

zookeeper集群

zookeeper集群.6fdcc61e.png
上图中每一个 Server 代表一个安装 ZooKeeper 服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态，并且每台服务器之间都互相保持着通信。集群间通过 ZAB 协议（ZooKeeper Atomic Broadcast）来保持数据的一致性。
最典型集群模式： Master/Slave 模式（主备模式）。在这种模式中，通常 Master 服务器作为主服务器提供写服务，其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。

集群的角色

与传统Master/Slave不一样的是，Zookeeper没有Master/Slaver的概念，而是引入了Leader、Follwer和Observer三种角色。如下图所示：
zookeeper集群中的角色.ffff8ef5.png

ZooKeeper 集群中的所有机器通过一个 Leader 选举过程 来选定一台称为 “Leader” 的机器，Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，Follower 和 Observer 都只能提供读服务。Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。

角色 说明
Leader 为客户端提供读和写的服务，负责投票的发起和决议，更新系统状态。
Follower 为客户端提供读服务，如果是写服务则转发给 Leader。参与选举过程中的投票。
Observer 为客户端提供读服务，如果是写服务则转发给 Leader。不参与选举过程中的投票，也不参与“过半写成功”策略。在不影响写性能的情况下提升集群的读性能。此角色于 ZooKeeper3.3 系列新增的角色。
  1. Leader election（选举阶段）：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。
  2. Discovery（发现阶段） ：在这个阶段，followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。
  3. Synchronization（同步阶段） :同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成之后 准 leader 才会成为真正的 leader。
  4. Broadcast（广播阶段） :到了这个阶段，ZooKeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。

    集群服务器的状态

  • LOOKING ：寻找 Leader。
  • LEADING ：Leader 状态，对应的节点为 Leader。
  • FOLLOWING ：Follower 状态，对应的节点为 Follower。
  • OBSERVING ：Observer 状态，对应节点为 Observer，该节点不参与 Leader 选举。

    Zookeeper集群为啥最好奇数台

    ZooKeeper 集群在宕掉几个 ZooKeeper 服务器之后，如果剩下的 ZooKeeper 服务器个数大于宕掉的个数的话整个 ZooKeeper 才依然可用。假如我们的集群中有 n 台 ZooKeeper 服务器，那么也就是剩下的服务数必须大于 n/2。先说一下结论，2n 和 2n-1 的容忍度是一样的，都是 n-1，大家可以先自己仔细想一想，这应该是一个很简单的数学问题了。
    比如假如我们有 3 台，那么最大允许宕掉 1 台 ZooKeeper 服务器，如果我们有 4 台的的时候也同样只允许宕掉 1 台。 假如我们有 5 台，那么最大允许宕掉 2 台 ZooKeeper 服务器，如果我们有 6 台的的时候也同样只允许宕掉 2 台。
    综上，何必增加那一个不必要的 ZooKeeper 呢？

ZooKeeper 选举的过半机制防止脑裂

何为集群脑裂？

对于一个集群，通常多台机器会部署在不同的机房，来提高集群的可用性。保证可用性的同时，会发生一种机房网络线路故障，导致机房网络不通，而集群被割裂成几个小集群。这时候子集群各自选主导致“脑裂”的情况。
ZooKeeper 的过半机制导致不可能产生 2 个 leader，因为少于等于一半是不可能产生 leader 的，这就使得不论机房的机器如何分配都不可能发生脑裂。

ZAB协议和Paxos算法（数据一致性）

ZAB协议

ZAB（zookeeper Atomic Broadcast原子广播）协议是zookeeper专门设计的一种支持崩溃恢复的原子广播协议。在zookeeper中，主要依赖ZAB协议来实现分布式数据一致性，基于该协议，zookeeper实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

ZAB协议的两种基本模式

  • 崩溃恢复 ：当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。
  • 消息广播 ：当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。 当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。