Zookeeper（一）：基本概念讲解

Zookeeper详解

一：基本概念

下面是百度百科的解释：

• ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
• ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
• ZooKeeper包含一个简单的原语集，提供Java和C的接口。
• ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在$zookeeper_home\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。

道人自己的理解：

• Zookeeper 解决了什么需求？道人觉得最根本的原因是，微服务兴起、分布式应用的兴起导致。集群如何管理节点，微服务中如何进行服务管理（服务注册中心）。zookeeper这个中间件便是主要解决上述痛点（而且做得挺好）。

• 在道人眼中，zookeeper是一个开源的、对分布式应用进行协调服务的项目，其主要的应用场景有：统一配置维护、统一域名服务、分布式同步、服务注册中心等，这些应用基于zookeeper的树形文件系统（结构）以及其通知机制来实现。同时zookeeper在分布式锁上应用，是基于其代码版本，提供的分布式锁、队列、选举的接口来实现的。

二：关键名词解释

结构模型图

1. ZK的数据结构

• 树形文件系统：Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。
• 通知机制：client端会对某个znode建立一个watcher事件，当该znode发生变化时，这些client会收到zk的通知，然后client可以根据znode变化来做出业务上的改变等

2. 节点类型

• Znode 兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、 时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有 子 Znode。用户对 Znode 具有增、删、改、查等操作(权限允许的情况下)。
• Znode 具有原子性操作，读操作将获取与节点相关的所有数据，写操作也将 替换掉节点的所有数据。另外，每一个节点都拥有自己的 ACL(访问控制列 表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的 操作
• Znode 存储数据大小有限制。ZooKeeper 虽然可以关联一些数据，但并没有 被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据， 比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的 共同特性就是它们都是很小的数据，通常以 KB 为大小单位。ZooKeeper 的服 务器和客户端都被设计为严格检查并限制每个 Znode 的数据大小至多 1M，当 时常规使用中应该远小于此值。
• Znode 通过路径引用，如同 Unix 中的文件路径。路径必须是绝对的，因此他 们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个 路径只有一个表示，因此这些路径不能改变。在 ZooKeeper 中，路径由 Unicode 字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理 信息，比如关键配额信息。

zk节点类型的三大类：持久性节点（Persistent）、临时性节点（Ephemeral）、顺序性节点（Sequential）

• 持久节点（Persistent）：创建后会一直存在服务器，直到删除操作主动清除。
• 持久顺序节点（Persistent-Sequential）：持久性与持久节点一致，创建节点的时候，会在节点名后面加上一个数字后缀，来表示其顺序。
• 临时节点（Ephemeral）：会被自动清理掉的节点，它的生命周期和客户端会话绑在一起，客户端会话结束，节点会被删除掉。
• 临时顺序节点（Ephemeral-Sequential）：就是有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后面加上数字后缀。

3. 节点的内容信息

节点信息包括两类：节点数据内容和节点状态信息。

使用 “ls2 节点” 获取节点信息

• cZxid 就是 Create ZXID，表示节点被创建时的事务 ID。
• mZxid 就是 Modified ZXID，表示节点最后一次被修改时的事务 ID。
• ctime 就是 Create Time，表示节点创建时间。
• mtime 就是 Modified Time，表示节点最后一次被修改的时间。
• pZxid 表示该节点的子节点列表最后一次被修改时的事务 ID。只有子节点列表变更才会更新 pZxid，子节点内容变更不会更新。
• cversion 表示子节点的版本号。
• dataVersion 表示内容版本号。
• dataLength 表示数据长度。
• numChildren 表示子节点数。
• ephemeralOwner 表示创建该临时节点时的会话
• sessionID，如果是持久性节点那么值为 0。

状态信息：你可以理解其包括创建检点的事务ID，最后一次修改事务ID，创建时间，修改时间，子节点最后一次被修改的事务，版本信息，数据长度，临时节点会话信息等。

概括总结下

• 事务信息（ID）：自身节点（创建，最后一次修改）与子节点（最后一次修改）
• 时间信息：自身节点（创建，最后一次修改）
• 版本信息：自身内容版本号，子节点版本号
• 数据信息：数据长度，子节点数量
• 临时信息：针对临时节点的会话信息（会话ID）

4. Zookeeper的特点

• 顺序一致性：
  从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到ZooKeeper中。
• 原子性：
  所有事务请求的结果在集群中所有机器上的应用情况是一致的，也就是说要么整个集群所有集群都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。
• 单一视图：
  无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。
• 可靠性：
  一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。
• 实时性：
  通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

都看到这了，道友们，点个赞再走呗！