[ZooKeeper]理论篇

这篇文章的背景，是因为公司需要进行kafka的研究，而虽然新版本上弱化了zookeeper的作用，新版本中移除了客户端对ZK的依赖，但是broker依然依赖于zookeeper。

一、概述

官方的解释

ZooKeeper是用于维护配置信息，命名，提供分布式同步和提供组服务的集中式服务。
ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

起源

最早起源于雅虎研究院的研究小组，由于需求问题，需要一个类似的系统进行分布式协调，因此而开发出一个无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上面。
“zookeeper”——动物管理员，因为大多数项目采用动物名字，整个分布式系统看上去像是一个大型动物园，而Zookeeper刚好用以进行分布式环境的协调。

设计目标

简单的数据模型

ZooKeeper 允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。 名称空间由 ZooKeeper 中的数据寄存器组成 - 称为znode，这些类似于文件和目录。 与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。

可构建集群

为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么zookeeper本身仍然是可用的。 客户端在使用 ZooKeeper 时，需要知道集群机器列表，通过与集群中的某一台机器建立 TCP 连接来使用服务，客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上。
ZooKeeper 官方提供的架构图：

上图中每一个Server代表一个安装Zookeeper服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态，并且每台服务器之间都互相保持着通信。集群间通过 Zab 协议（Zookeeper Atomic Broadcast）来保持数据的一致性。

顺序访问

对于来自客户端的每个更新请求，ZooKeeper 都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用 ZooKeeper 这个特性来实现更高层次的同步原语。 这个编号也叫做时间戳——zxid（Zookeeper Transaction Id）

高性能

ZooKeeper 是高性能的。 在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）

Zookeeper特点

● 顺序一致性： 从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。

● 原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。

● 单一系统映像 ： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。

● 可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

二、重要概念

概念

● ZooKeeper 本身就是一个分布式程序（只要半数以上节点存活，ZooKeeper 就能正常服务）。

● 为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么 ZooKeeper 本身仍然是可用的。

● ZooKeeper 将数据保存在内存中，这也就保证了 高吞吐量和低延迟（但是内存限制了能够存储的容量不太大，此限制也是保持znode中存储的数据量较小的进一步原因）。

● ZooKeeper 是高性能的。 在**“读”多于“写”的应用程序中尤其地高性能**，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）

● ZooKeeper有临时节点的概念。 当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在。而当会话终结时，瞬时节点被删除。持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上。

● ZooKeeper 底层其实只提供了两个功能：①管理（存储、读取）用户程序提交的数据；②为用户程序提交数据节点监听服务。

会话（session）

指的是 ZooKeeper 服务器与客户端会话。

在 ZooKeeper 中，一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。客户端启动的时候，首先会与服务器建立一个 TCP 连接，从第一次连接建立开始，客户端会话的生命周期也开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。 **Session的sessionTimeout值用来设置一个客户端会话的超时时间。**当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

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

Znode

分布式中指的节点大部分指的是组成集群的每一台机器，而zookeeper中多了znode的概念，即数据模型中的数据单元，称之为数据节点——Znode。

数据存储于内存中，数据模型是一棵树（Znode Tree），由斜杠（/）进行分割的路径，例如/foo/path1。每个数据节点上面都会保存自己的数据内容，同时保存一系列属性信息。

$$Znode\{\begin{array}{r}持久节点——一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，\\ 否则这个ZNode将<一直保存在Zookeeper上>\\ 临时节点——它的<生命周期和客户端会话绑定>，一旦客户端会话失效，\\ 那么这个客户端创建的所有临时节点都会被移除\end{array}$$
另外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL.一旦节点被标记上这个属性，那么在这个节点被创建的时候，Zookeeper会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。

ACL

Zookeeper采用ACL（AccessControlLists）策略来进行权限控制，类似于 UNIX 文件系统的权限控制。

Zookeeper 定义了如下5种权限。

权限说明

在传统的文件系统中，ACL分为两个维度，一个是属组，一个是权限，一个属组包含多个权限，一个文件或目录拥有某个组的权限即拥有了组里的所有权限，文件或子目录默认会继承自父目录的ACL。
在Zookeeper中，znode的ACL没有继承关系，每个znode的权限都是独立控制的，只有客户端满足znode设置的权限要求时，才能完成相应的操作。

ZooKeeper权限说明

Zookeeper的ACL，分为三个维度：scheme、id、permission，通常表示为：scheme：id：permission。
schema代表授权策略，id代表用户，permission代表权限。

schema

schema对应采用哪种方案进行权限管理。

world:下面只有一个id，名为anyone，world:anyone代表任何人，zookeeper中对所有人的权限的节点即world:anyone。
auth:后面不需要带id，只要是通过authentication的user都有权限（zookeeper支持通过kerberos来进行authencation, 也支持username/password形式的authentication)
digest:是最常用的权限控制模式，也更符合我们对权限控制的认识，其类似于"username:password"形式的权限标识进行权限配置。它对应的id为username:BASE64(SHA1(password))，即对密码先做SHA1加密然后再进行BASE64摘要。必须是密文密码。
可以通过shell命令算出加密的密文：

[app@test13 bin]$ echo -n young:123456 | openssl dgst -binary -sha1 | openssl base64
rfYX13aeDCwuzgR151LcBVP9b2U=

ip:它对应的id为客户机的IP地址，设置的时候可以设置一个ip段，比如ip:192.168.1.0/16, 表示匹配前16个bit的IP段，也可以设置为某一个具体的ip
super:在这种scheme情况下，对应的id拥有超级权限，可以做任何事情(cdrwa)

说明：橙色为常用 蓝色为不常用

id

验证模式，不同的schema有不同策略。

schema =>id对应关系

schema	对应的id
world	anyone
digest	username:BASE64(SHA1(password))
ip	ip 或者 ip段

permission

---

权限	说明
create	创建权限，可在当前ZNode下创建子节点
delete	删除权限，可以删除当前ZNode
read	读权限，可以获取当前ZNode数据，可以列出所有节点下面的子节点
write	写权限，对当前ZNode写数据
admin	管理权限，可以设置当前ZNode的permission

版本

对于每个ZNode，ZK都会为其维护一个名为stat的数据结构，其中记录了这个ZNode三个数据版本：version（当前znode版本）、cversion（当前znode子节点版本）和aclVersion(当前Znode的ACL版本)。实际上Stat记录的东西远远不止这些：

• cZxid：这是导致创建znode更改的事务ID。
• mZxid：这是最后修改znode更改的事务ID。
• pZxid：这是用于添加或删除子节点的znode更改的事务ID。
• ctime：表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode创建时间。
• mtime：表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode最近修改时间。
• dataVersion：表示对该znode的数据所做的更改次数。
• cversion：这表示对此znode的子节点进行的更改次数。
• aclVersion：表示对此znode的ACL进行更改的次数。
• ephemeralOwner：如果znode是ephemeral类型节点，则这是znode所有者的 session ID。
  如果znode不是ephemeral节点，则该字段设置为零。
• dataLength：这是znode数据字段的长度。
• numChildren：这表示znode的子节点的数量。
  

Watcher

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

三、Zookeeper集群

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

为什么最好使用奇数台服务器构成 ZooKeeper 集群？

在Zookeeper中 Leader 选举算法采用了Zab协议¹。Zab核心思想是当多数 Server 写成功，则任务数据写成功。

①如果有3个Server，则最多允许1个Server 挂掉。

②如果有4个Server，则同样最多允许1个Server挂掉。

既然3个或者4个Server，同样最多允许1个Server挂掉，那么它们的可靠性是一样的，所以选择奇数个ZooKeeper Server即可，这里选择3个Server。

---

1. Zab协议：并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法， 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性。 ↩︎