博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
zookeeper
阅读量:5100 次
发布时间:2019-06-13

本文共 3127 字,大约阅读时间需要 10 分钟。

简介

ZooKeeper 是一个开源的分布式协调服务。

  分布式应用程序可以基于 ZooKeeper 实现诸如命名服务、分布式锁、集群管理、Master 选举、数据发布/订阅、负载均衡、分布式协调/通知、配置维护、分布式同步、分布式锁和分布式队列等功能。

数据结构-ZNode

  znode和系统的文件系统非常像的,都是树形结构。每一个节点被称之为Znode。

Znode结构

兼具文件和目录两种特点。

  stat: 状态信息:版本、权限等。

  data:与该Znode关联的数据

  children:该Znode下的子节点

节点类型

ZooKeeper中的节点有两种,分别为临时节点永久节点。节点的类型在创建时即被确定,并且不能改变。

 ① 临时节点:该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束,临时节点将被自动删除,当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话,但他们对所有的客户端还是可见的。另外,ZooKeeper的临时节点不允许拥有子节点

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

顺序节点

  当创建Znode的时候,用户可以请求在ZooKeeper的路径结尾添加一个递增的计数。这个计数对于此节点的父节点来说是唯一的,它的格式为"%10d"(10位数字,没有数值的数位用0补充,例如"0000000001")。当计数值大于232-1时,计数器将溢出。

节点中的属性:

时间

致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳,并且这个时间戳全局有序。也就是说,每个对节点的改变都将产生一个唯一的Zxid。如果Zxid1的值小于Zxid2的值,那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。实际上,ZooKeeper的每个节点维护者三个Zxid值,为别为:cZxid、mZxid、pZxid。

① cZxid: 是节点的创建时间所对应的Zxid格式时间戳。

② mZxid:是节点的修改时间所对应的Zxid格式时间戳。

③ pZxid: 是与 该节点的子节点(或该节点)的最近一次 创建 / 删除 的时间戳对应

版本号

对节点的每一个操作都将致使这个节点的版本号增加。每个节点维护着三个版本号,他们分别为:

① version:节点数据版本号

② cversion:子节点版本号

③ aversion:节点所拥有的ACL版本号(每一个节点都拥有自己的ACL(访问控制列表),这个列表规定了用户的权限,即限定了特定用户对目标节点可以执行的操作)

zookeeper的操作

更新ZooKeeper操作是有限制的。delete或setData必须明确要更新的Znode的版本号,我们可以调用exists找到。如果版本号不匹配,更新将会失败。

  更新ZooKeeper操作是非阻塞式的。因此客户端如果失去了一个更新(由于另一个进程在同时更新这个Znode),他可以在不阻塞其他进程执行的情况下,选择重新尝试或进行其他操作。

监听机制

 观察

  客户端可以在节点上设置watch,我们称之客户端为监视器(watcher)。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时,ZooKeeper将会向客户端发送且仅发送一条通知,因为watch只能被触发一次,这样可以减少网络流量。

(1) watch概述

ZooKeeper可以为所有的读操作设置watch,这些读操作包括:exists()、getChildren()及getData()。watch事件是一次性的触发器,当watch的对象状态发生改变时,将会触发此对象上watch所对应的事件。watch事件将被异步地发送给客户端,并且ZooKeeper为watch机制提供了有序的一致性保证。理论上,客户端接收watch事件的时间要快于其看到watch对象状态变化的时间。

(2) watch类型

ZooKeeper所管理的watch可以分为两类:

① 数据watch(data  watches):getData和exists负责设置数据watch

② 孩子watch(child watches):getChildren负责设置孩子watch

我们可以通过操作返回的数据来设置不同的watch:

① getData和exists:返回关于节点的数据信息

② getChildren:返回孩子列表

因此

① 一个成功的setData操作将触发Znode的数据watch

② 一个成功的create操作将触发Znode的数据watch以及孩子watch

③ 一个成功的delete操作将触发Znode的数据watch以及孩子watch

(3) watch注册与处触发

exists操作上的watch,在被监视的Znode创建、删除或数据更新时被触发。

getData操作上的watch,在被监视的Znode删除或数据更新时被触发。在被创建时不能被触发,因为只有Znode一定存在,getData操作才会成功。

getChildren操作上的watch,在被监视的Znode的子节点创建或删除,或是这个Znode自身被删除时被触发。可以通过查看watch事件类型来区分是Znode,还是他的子节点被删除:NodeDelete表示Znode被删除,NodeDeletedChanged表示子节点被删除。

监听工作原理:

ZooKeeper 的 Watcher 机制主要包括客户端线程、客户端 WatcherManager、Zookeeper 服务器三部分。客户端在向 ZooKeeper 服务器注册的同时,会将 Watcher 对象存储在客户端的 WatcherManager 当中。当 ZooKeeper 服务器触发 Watcher 事件后,会向客户端发送通知, 客户端线程从 WatcherManager 中取出对应的 Watcher 对象来执行回调逻辑。

选举

通过集群进行Master选举,来解决分布式系统中的单点故障。(主从模式,主节点挂了,即单点故障)

1) Master启动

在引入了Zookeeper以后我们启动了两个主节点,"主节点-A"和"主节点-B"他们启动以后,都向ZooKeeper去注册一个节点。我们假设"主节点-A"锁注册地节点是"master-00001","主节点-B"注册的节点是"master-00002",注册完以后进行选举,编号最小的节点将在选举中获胜获得锁成为主节点,也就是我们的"主节点-A"将会获得锁成为主节点,然后"主节点-B"将被阻塞成为一个备用节点。那么,通过这种方式就完成了对两个Master进程的调度。

(2) Master故障

如果"主节点-A"挂了,这时候他所注册的节点将被自动删除,ZooKeeper会自动感知节点的变化,然后再次发出选举,这时候"主节点-B"将在选举中获胜,替代"主节点-A"成为主节点。

(2) Master恢复

如果主节点恢复了,他会再次向ZooKeeper注册一个节点,这时候他注册的节点将会是"master-00003",ZooKeeper会感知节点的变化再次发动选举,这时候"主节点-B"在选举中会再次获胜继续担任"主节点","主节点-A"会担任备用节点。

 

转载于:https://www.cnblogs.com/RobertLionLin/p/11466534.html

你可能感兴趣的文章
druid数据源的加密解密工具
查看>>
swfupload详解
查看>>
php模拟多线程
查看>>
交叉熵
查看>>
python-微博模拟登陆
查看>>
Python【11】【前端编程】- HTML基础
查看>>
nump库的简单函数介绍
查看>>
好程序员大数据点睛:Hadoop基础篇
查看>>
JVM内存模型和GC机制
查看>>
201571030323/201571030334《小学生四则运算练习软件需求说明》结对项目报告
查看>>
SequenceFile介绍
查看>>
安卓 代码混淆与打包
查看>>
AT&T汇编语言及其寻址方式
查看>>
ubuntu下 java、mysql、tomcat(ssl认证) 配置
查看>>
linux命名详解及其软件安装实例
查看>>
查看iOS沙盒(SanBox)文件
查看>>
数据结构与算法
查看>>
顺时针打印矩阵
查看>>
[转载]Chrome 与 Chrome OS 各版本下载集合
查看>>
面试微软前必须要读的十本书
查看>>