黑马程序员技术交流社区

标题: [杭州校区][技术笔记]大数据基础增强之zookeeper（一） [打印本页]

作者: 小江哥 时间: 2018-7-16 14:59
标题: [杭州校区][技术笔记]大数据基础增强之zookeeper（一）
大家好啊，今天继续来看大数据开始阶段要了解的基础：zookeeper。

1. ZooKeeper概述

Zookeeper 是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性问题，例如怎样避免同时操作同一数据造成脏读的问题。

ZooKeeper 本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。诸如：统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。

2. ZooKeeper集群角色

Leader: Zookeeper 集群工作的核心，主要工作如下

事物请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。

对于 create ， setData ， delete 等有写操作的请求，则需要统一转发给leader 处理， leader 需要决定编号、执行操作，这个过程称为一个事务。

Follower:

处理客户端非事物（读操作）请求，转发事物请求给 Leader；

参与集群 Leader 选举投票。

Observer:

充当观察者角色，观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader 服务器进行处理。

不会参与任何形式的投票只提供非事物服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事物处理能力。

3．zookeeper 特性

1. 全局数据一致：每个 server 保存一份相同的数据副本，client 无论连接到哪个 server，展示的数据都是一致的，这是最重要的特征；

2. 可靠性：如果消息被其中一台服务器接受，那么将被所有的服务器接受。

3. 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息 a 在消息 b 前发布，则在所有 Server 上消息 a 都将在消息 b 前被发布；偏序是指如果一个消息 b 在消息 a 后被同一个发送者发布，a 必将排在 b 前面。

4. 数据更新原子性：一次数据更新要么成功（半数以上节点成功），要么失

败，不存在中间状态；

5. 实时性：Zookeeper 保证客户端将在一个时间间隔范围内获得服务器的

更新信息，或者服务器失效的信息。

4. zookeeper 数据模型

ZooKeeper 的数据模型，在结构上和标准文件系统的非常相似，拥有一个层次的命名空间，都是采用树形层次结构，ZooKeeper树中的每个节点被称为Znode。和文件系统的目录树一样，ZooKeeper树中的每个节点可以拥有子节点。但也有不同之处：

1. Znode 兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子 Znode。用户对 Znode 具有增、删、改、查等操作（权限允许的情况下）。

2. Znode 具有原子性操作，读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的 ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。

3. Znode 存储数据大小有限制。ZooKeeper虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB 为大小单位。ZooKeeper 的服务器和客户端都被设计为严格检查并限制每个Znode 的数据大小至多 1M，当时常规使用中应该远小于此值。

4. Znode 通过路径引用，如同Unix 中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在ZooKeeper 中，路径由Unicode 字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。

4.1．数据结构图

（见下图）

图中的每个节点称为一个 Znode。每个 Znode 由 3 部分组成:

① stat：此为状态信息, 描述该 Znode 的版本, 权限等信息

② data：与该 Znode 关联的数据

③ children：该 Znode 下的子节点

3.2．节点类型

Znode 有两种，分别为临时节点和永久节点。

节点的类型在创建时即被确定，并且不能改变。

临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。

永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

Znode 还有一个序列化的特性，如果创建的时候指定的话，该 Znode 的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10 位数字，没有数值的数位用 0 补充，例如“0000000001”)这样便会存在四种类型的 Znode 节点，分别对应：

PERSISTENT：永久节点

EPHEMERAL：临时节点

PERSISTENT_SEQUENTIAL：永久节点、序列化

EPHEMERAL_SEQUENTIAL：临时节点、序列化

3.3．节点属性

每个 znode 都包含了一系列的属性，通过命令 get，可以获得节点的属性。

dataVersion：数据版本号，每次对节点进行 set 操作，dataVersion 的值都会增加 1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。

cversion ：子节点的版本号。当 znode 的子节点有变化时，cversion 的值就会增加 1。

aclVersion ：ACL 的版本号。

cZxid ：Znode 创建的事务 id。

mZxid ：Znode 被修改的事务id，即每次对 znode 的修改都会更新 mZxid。

对于 zk 来说，每次的变化都会产生一个唯一的事务 id，zxid（ZooKeeperTransaction Id）。通过 zxid，可以确定更新操作的先后顺序。例如，如果 zxid1小于 zxid2，说明 zxid1 操作先于 zxid2 发生，zxid 对于整个 zk 都是唯一的，即使操作的是不同的znode。

ctime：节点创建时的时间戳.

mtime：节点最新一次更新发生时的时间戳.

ephemeralOwner:如果该节点为临时节点, ephemeralOwner 值表示与该节点绑定的 sessionid. 如果不是, ephemeralOwner 值为 0.

在 client 和 server 通信之前,首先需要建立连接,该连接称为 session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接,连接便处于 CLOSED状态, 此时 session 结束。

2018-07-16_143702.png (25.14 KB, 下载次数: 16)

欢迎光临黑马程序员技术交流社区 (http://bbs.itheima.com/)

黑马程序员IT技术论坛 X3.2