Zookeeper入门

此处学习时我们配置为三台虚拟机环境

1.Zookeeper概述

ZooKeeper概念: Zookeeper是一个分布式协调服务的开源框架。本质上是一个分布式的小文件存储系统
ZooKeeper作用: 主要用来解决分布式集群中应用系统的一致性问题。
ZooKeeper结构: 采用树形层次结构，ZooKeeper树中的每个节点被称为—Znode。且树中的每个节点可以拥有子节点

2.Zookeeper集群环境

zookeeper的服务角色分别为:
leader: 管理者 ,负责管理follower,处理所有的事务请求(数据的保存,修改,删除)
follower: 追随者,负责选举(选举leader)和数据的同步及获取
observer: 观察者,负责数据的同步及获取(需要在配置文件中指定才能生效)

zookeeper应用: 搭建hadoop高可用环境时,至少需要两个hadoop服务(NameNode和ResourceManager),一主一备,主服务对外提供业务功能,备用服务等待主服务不可用时,启用备用服务器对外提供业务功能

3.Zookeeper启动和使用

3.1 配置环境变量

配置zookeeper环境变量**(注意三台都单独配置!!!)**

可以使用CRT客户端发送以下命令到三台

[root@nodex ~]# echo 'export ZOOKEEPER_HOME=/export/server/zookeeper' >> /etc/profile
[root@nodex ~]# echo 'export PATH=$PATH:$ZOOKEEPER_HOME/bin' >> /etc/profile
[root@nodex ~]# source /etc/profile

3.2 启动集群

启动zookeeper服务**(注意三台都单独需要启动!!!)**

可以使用CRT客户端发送以下命令到三台

[root@nodex ~]# zkServer.sh start

还可以查看服务状态: [root@node]# zkServer.sh status
关闭zk服务的命令是: [root@node]# zkServer.sh stop

3.3 客户端连接

连接服务
方式1:直接连接本地: [root@node1 ~]# zkCli.sh
方式2:连接其他节点: [root@node1 ~]# zkCli.sh –server 节点地址

[root@node1 ~]# zkCli.sh

3.4 Zookeeper的shell命令

help : 查看所有shell命令

create [-s] [-e] 节点绝对路径 节点数据 : 创建数据节点 注意: –s代表序列化节点 -e代表临时节点

delete 节点绝对路径 [version] : 删除一级节点 注意: 此方式如果有子节点是不能删除的
rmr 节点绝对路径 : 删多层除节点(如果有子节点也可以删除)

set 节点绝对路径 data [version] : 设置 /修改节点数据
get 节点绝对路径 [watch] : 获取数据 注意: watch是监听
ls 节点绝对路径 : 查看节点信息 举例: 查看根路径下节点 ls /
ls2 节点绝对路径 : 查看节点详情信息
history : 查看操作历史
quit : 退出

[root@node1 ~]# zkCli.sh
...
WatchedEvent state:SyncConnected type:None path:null
[zk: localhost:2181(CONNECTED) 0] ls /
[zookeeper]
[zk: localhost:2181(CONNECTED) 1] create /xinzai 666
Created /xinzai
[zk: localhost:2181(CONNECTED) 2] create /xinzai/b1 111
Created /xinzai/b1
[zk: localhost:2181(CONNECTED) 3] create /xinzai/b2 222
Created /xinzai/b2

[zk: localhost:2181(CONNECTED) 4] ls /
[xinzai, zookeeper]
[zk: localhost:2181(CONNECTED) 5] ls /xinzai
[b2, b1]
[zk: localhost:2181(CONNECTED) 6] set /xinzai 888
...
[zk: localhost:2181(CONNECTED) 7] get /xinzai
888
...

[zk: localhost:2181(CONNECTED) 8] delete /xinzai/b1
[zk: localhost:2181(CONNECTED) 9] ls /xinzai
[b2]

# 注意: delete不能删除有子节点的节点
[zk: localhost:2181(CONNECTED) 10] delete /xinzai
Node not empty: /xinzai 
# rmr可以删除多层节点
[zk: localhost:2181(CONNECTED) 11] rmr /xinzai
[zk: localhost:2181(CONNECTED) 12] ls /
[zookeeper]

[zk: localhost:2181(CONNECTED) 13] history
...
[zk: localhost:2181(CONNECTED) 14] quit
Quitting...shut down
[root@node1 ~]# 

4.Zookeeper的节点特性和分类

4.1 节点特性

ZooKeeper的数据模型，在结构上和标准文件系统的非常相似，都是采用树形层次结构，和文件系统的目录树一样，ZooKeeper树中的每个节点可以拥有子节点。

但也有不同之处：
Znode兼具文件和目录两种特点: Znode没有文件和目录之分,Znode既有像文件一样存储数据,也能像目录一样作为路径标识的一部分

Znode具有原子性操作: 读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据

Znode存储数据大小有限制: 每个Znode的数据大小至多1M，当时常规使用中应该远小于此值

Znode通过路径引用: 路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。 默认有/zookeeper节点用以保存关键的管理信息。

4.2 节点分类

节点分类:
1.永久普通节点
2.临时普通节点
3.永久序列化节点
4.临时序列化节点

创建永久普通节点: create /节点 数据

创建临时普通节点: create -e /节点 数据

创建永久序列化节点: create -s /节点 数据

创建临时序列化节点: create -e -s /节点 数据

注意: 临时节点不能创建子节点

4.3 节点属性

每个znode都包含了一系列的属性，通过命令get /节点，可以获得节点的属性
注意: 对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode。
cZxid ：Znode创建的事务id。
ctime ：Znode创建时的时间戳.

mZxid ：Znode被修改的事务id，即每次对当前znode的修改都会更新mZxid。
mtime ：Znode最新一次更新发生时的时间戳.

pZxid ：Znode的子节点列表变更的事务ID，添加子节点或删除子节点就会影响子节点列表
cversion ：子节点进行变更的版本号。添加子节点或删除子节点就会影响子节点版本号

dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了 数据更新时出现的先后顺序问题。
aclVersion : 权限变化列表版本 access control list Version
ephemeralOwner : 字面翻译临时节点拥有者，永久节点值为: 0x0，临时节点值为:会话ID (不是0x0的就是临时节点)
dataLength : Znode数据长度
numChildren: 当前Znode子节点数量(不包括子子节点）

5.Zookeeper集群特点

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

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

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

4. 数据更新原子性: 一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态；

5. 实时性: Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

6.watch监听机制

ZooKeeper中，引入了Watcher机制来实现数据发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。
ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能

watch监听机制过程: 1.客户端向服务端注册Watcher 2.服务端事件发生触发Watcher 3.客户端回调Watcher得到触发事件情况
Watch监听机制注册格式: get /节点绝对路径 watch
Watch监听机制特点:
1.先注册再触发: Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端
2.一次性触发: 事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发。
3.异步发送: watcher的通知事件从服务端发送到客户端是异步的。
4.通知内容: 通知状态（keeperState），事件类型（EventType）和节点路径（path）

示例

node1上创建临时节点

[zk: localhost:2181(CONNECTED) 1] create -e /master 1111
Created /master

node2上设置监听

[zk: localhost:2181(CONNECTED) 28] get /master watch

node1退出

[zk: localhost:2181(CONNECTED) 2] quit

node2查看消息

[zk: localhost:2181(CONNECTED) 29] 
WATCHER::

WatchedEvent state:SyncConnected type:NodeDeleted path:/master

7.Zookeeper应用

1. 数据发布/订阅

数据发布/订阅系统,就是发布者将数据发布到ZooKeeper的一个节点上，提供订阅者进行数据订阅，从而实现动态更新数据的目的，实现配置信息的集中式管理和数据的动态更新。

主要用到知识点: 监听机制

2. 提供集群选举

在分布式环境下，不管是主从架构集群，还是主备架构集群，要求在服务的时候有且有一个正常的对外提供服务，我们称之为master。
当master出现故障之后，需要重新选举出的新的master。保证服务的连续可用性。zookeeper可以提供这样的功能服务。
主要用到知识点: znode唯一性、临时节点短暂性、监听机制。

选举概述:
选举要求: 过半原则,所以搭建集群一般奇数,只要某个node节点票数过半立刻成为leader

集群第一次启动: 启动follower每次投票后,他们会相互同步投票情况,如果票数相同,谁的myid大,谁就当选leader,一旦确定了leader,后面来的默认就是follower,即使它的myid大,leader也不会改变(除非leader宕机了)

leader宕机后启动: 每一个leader当老大的时候,都会产生新纪元epoch,且每次操作完节点数据都会更新事务id(高32位_低32位) ,当leader宕机后,剩下的follower就会综合考虑几个因素选出最新的leader,先比较最后一次更新数据事务id(高32位_低32位),谁的事务id最大,谁就当选leader,如果更新数据的事务id都相同的情况下,就需要再次考虑myid,谁的myid大,谁就当选leader

代码007普通

打赏 收藏 海报 链接