如何理解ZOOKEEPER及其在大数据中的地位

一、ZooKeeper基本介绍

1.1、何为ZooKeeper

ZooKeeper是一个分布式协调服务的开源框架,核心功能是解决分布式集群中应用系统的一致性问题(超赞的功能)。

ZooKeeper的本质可以理解为一个分布式的小文件存储系统,结构类似于文件系统的目录树,在目录树节点进行数据存储、维护和管理,通过监控对这些数据状态的变化,从而实现基于数据的集群管理。

分布式系统
分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务,但是对于系统的用户来说,就像是一台计算机在提供服务一样。
分布式意味着可以采用更多的普通计算机(相对于昂贵的大型机)组成分布式集群对外提供服务。计算机越多,CPU、内存、存储资源等也就越多,能够处理的并发访问量也就越大。

互联网网站常用的架构:
请添加图片描述

1.2、ZooKeeper的优势

全局数据一致性
ZK集群中每台服务器均会保存相同的一份数据副本,对于client来说,无论连接至哪台服务器,数据都是相同的;
集群中数据同步采用ZAB协议,即Zookeeper Atomic Broadcast(Zookeeper 原子广播协议):
请添加图片描述

可靠性
ZK集群各服务器之间消息同步,只要有一台服务器接收消息成功,则ZK集群接收消息成功;

顺序性
ZK集群中,消息存在先后顺序,具体又细分为全局有序和偏序两种;全局有序–指如果在一台服务器上消息a在消息b前发布,则在所有服务器上消息a都将在消息b前被发布;偏序–指如果消息b在消息a后被同一个发送者发布,a必将排在b前面;

数据更新原子性
数据更新要么成功(半数以上节点成功),要么失败;

实时性
client在一定时间范围内,获得服务器的更新信息。

1.3、ZooKeeper地位

大数据集群的心脏

大数据生态里面,hadoop、hbase、hive…等组件都是分布式部署,这些组件利用Zookeeper的服务做了一些维持自身平衡的事情,比如集群管理、master选举、消息发布订阅、数据存储、分布式锁等。

分布式锁机制
分布式锁的定义:在分布式系统中,应用可能部署在多台机器上,应用不在同一个jvm里面,这个时候还需要维护一个互斥排他的策略,需要一个跨jvm的锁同步,为了解决跨系统、跨jvm的锁,我们就必须引入分布式锁。

  • 排他锁(写锁/独占锁)
    核心:保证当前有且仅有一个事务获得锁,并且锁释放之后,所有正在等待获取锁的事务都能够被通知到;
    保证在分布式高并发情况下节点的创建一定能够保证全局唯一性(全局数据一致性)

  • 共享锁(读锁)
    加了共享锁之后,数据对象对所有事务都可见;
    如果事务T1对数据对象O1加上了共享锁,那么当前事务只能对O1进行读取操作,其他事务也只能对这个数据对象加共享锁,直到该数据对象上的所有共享锁都被释放。

二、ZooKeeper集群

Zookeeper集群通常由2n+1台servers组成。这是因为为了保证Leader选举(基于Paxos算法的实现)能够得到多数的支持,所以ZooKeeper集群的数量一般为奇数。超过半数有效。

2.1、ZooKeeper集群介绍

ZK集群图示:
请添加图片描述

2.2、集群角色对比:

请添加图片描述

ZK集群假设有100台服务器,可设定Leader 1台,Follower 4台,Observer 95台。

角色对比节点名称事务请求(写操作)非事务请求(读操作)Leader选举投票是否必须存在
Leader主节点唯一可处理,保证顺序性,调度集群服务器不处理参与
Follower从节点转发事务请求给Leader处理非事务(读操作)请求参与
Observer观察者转发事务请求给Leader处理非事务(读操作)请求不参与针对访问量比较大的zookeeper集群,负责观察Zookeeper集群的最新状态变化并将这些状态同步过来,通常用于提升集群的非事务处理能力

Server:服务器,所有的节点都是一台服务器;
Client:客户端;

事务
一个对于写操作(create,setData,delete等)的请求,统一转给Leader处理,并由其决定编号、执行操作的过程;
事务型请求只能有一个,保证数据的一致性。

2.3、Master的选举

很多应用都是master-slave架构,master必须7*24小时工作,但是每次只能一个master在工作,这时需要一个选举机制,确定一个active状态的master,当active的master出现故障挂掉的时候,standby的master顶上去,这里主要讲zk这端的实现。

Master选举的功能
各个master注册到zk的目录下,创建临时节点,成功在zk创建临时节点的目录,也就被选举为Master,其它备用的Master就会收到监听zk里面临时节点的变化,一旦删除,就会争夺创建临时节点的权利成为新的Master。

本质其实是利用zookeeper的临时节点的特性:临时节点随着会话的消亡而消亡,同一个临时节点只能创建一个,创建失败的节点(从master)对创建成功节点(主master)进行监控,一旦创建成功的节点(主master)会话消失,之前创建失败的节点(从master)就会监听到去抢夺创建临时节点

三、ZooKeeper集群选举机制

zookeeper集群选举默认的算法是FastLeaderElection,采用投票数大于半数则胜出的逻辑。

3.1、概述

服务器ID:
每台服务器都有编号,编号越大在选择算法中的权重越大。

选举状态:

状态描述
LOOKING竞选状态,很短暂
LEADING领导者状态
FOLLOWING随从状态,同步leader状态,参与投票
OBSERVING观察状态,同步leader状态,不参与投票

数据ID/事务id:

  • 服务器中存放的最新数据version;
  • 值越大说明数据越新,在选举算法中数据越新权重越大。

逻辑时钟:

  • 也叫投票的次数,同一轮投票过程中的逻辑时钟值是相同的;
  • 每投完一次票这个数据就会增加,然后与接收到的其它服务器返回的投票信息中的数值相比,根据不同的值做出不同的判断。

3.2、全新集群选举流程

以5台服务器为例,每台服务器均没有数据,编号为1、2、3、4、5,按编号依次启动,选举过程如下:

  • 服务器1启动,给自己投票,然后发投票信息,由于其它机器还未启动所以它收不到反馈信息,服务器1的状态为LOOKING ;

  • 服务器2启动,给自己投票,同时与服务器1交换投票信息结果,由于服务器2的编号大所以服务器2胜出,但此时投票数没有大于半数,所以服务器1、2的状态依然是LOOKING;

  • 服务器3启动,给自己投票,同时与服务器1、2交换投票信息结果,由于服务器3的编号最大所以服务器3胜出,此时投票数正好大于半数,所以服务器3成为Leader,服务器1,2成为Follower ;

  • 服务器4启动,给自己投票,同时与服务器1、2、3交换投票信息结果,尽管服务器4的编号大,但之前服务器3已经胜出,所以服务器4只能成为Follower ;

  • 服务器5启动,后面的逻辑同服务器4成为Follower 。
    请添加图片描述

3.3、非全新集群选举

正常运行的zookeeper集群,中途会存在有机器down掉的情况,在需要重新选举时,选举过程就需要加入事务ID服务器ID逻辑时钟

  • 事务ID(zxid):即数据ID,数据越新,version就大,数据每次更新都会更新version。
  • 服务器ID:机器编号,就是我们配置的myid中的值,每个机器一个。
  • 逻辑时钟:这个值从0开始递增,每次选举对应一个值。 如果在同一次选举中,这个值是一致的。

Leader选举标准:

  • 逻辑时钟小的选举结果被忽略,重新投票;
  • 统一逻辑时钟后,事务ID大的胜出;
  • 事务ID相同的情况下,服务器ID大的胜出;

四、ZooKeeper数据模型

ZooKeeper的数据模型,在结构上和标准文件系统相似:拥有一个层次的命名空间;采用树形层次结构。

4.1、数据结构

请添加图片描述
图中ZooKeeper树的每个节点称为一个Znode, 每个Znode由3部分组成:

  • stat:此为状态信息, 描述该Znode的版本, 权限等信息
  • data:与该Znode关联的数据
  • children:该Znode下的子节点

Znode特性

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

4.2、zookeeper的文件系统

zk的所有Znode不管父子节点都能带数据,但linux的目录不能,所以zk里面的路径不能叫文件夹也不能叫文件,统一称为Znode。

zookeeper的文件系统的特点:
zk的文件系统和Linux的文件系统目录结构一样,从/开始;
zk的访问路径只有绝对路径,没有相对路径;
zk中没有文件和目录的概念,只有znode节点,Znode既有文件的功能,又有目录的功能。

4.3、节点类型

Znode节点类型可分为两种:临时节点和永久节点。ZK的数据类型类似一棵树,所有的节点都称为Znode,节点的类型在创建时被确定,不能改变。

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

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

序列化特性
Znode节点有序性,Znode节点创建时,若指定序列化特性,该Znode的名字后面会自动追加一个不断增加的序列号;
序列号对于此节点的父节点来说是唯一的,这样便会记录每个子节点创建的先后顺序,它的格式为“%10d”(10位数字,没有数值的数位用0补充,例如“0000000001”)。

序列化特性下的四种Znode节点类型:

  • PERSISTENT:永久节点
  • EPHEMERAL:临时节点
  • PERSISTENT_SEQUENTIAL:永久节点、序列化
  • EPHEMERAL_SEQUENTIAL:临时节点、序列化

4.4、节点属性

znode包含了一系列的属性,通过命令get,可以获得节点的属性:
请添加图片描述
属性介绍:

属性描述
cZxidZnode创建的事务id
ctime节点创建时的时间戳
mZxidZnode被修改的事务id,即每次对znode的修改都会更新mZxid。
mtime节点最新一次更新发生时的时间戳
pzxid事务id,增删改的序号
cversion子节点的版本号。当znode的子节点有变化时,cversion 的值就会增加1。
dataVersion数据版本号,每次对节点进行set操作,dataVersion的值都会增加1(即使设置的是相同的数据),有效避免了数据更新时出现的先后顺序问题。
aclVersion表示对此znode的acl版本
ephemeralOwner
dataLengthznode数据字段的长度

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

4.5、节点的加入和退出

首先,在zk中创建持久节点 /GroupMembers 作为父节点,父节点监听子节点的变化,client通过注册到zk,会在/GroupMembers下创建临时节点,临时节点的特性时当客户端与zk断开连接时会自动删除,不论是创建和删除,zk server都会监听,通过Watcher监听与通知机制,并且会把变动的结果通知到到其它client,这样,其它所有client都知道了其它兄弟们的存活情况。

#连接客户端
zkCli.sh -server node01
#命令提示
help

create [-s][-e] path data acl
# -s 顺序节点
# -e 临时节点,若不指定,则表示持久节点
# acl用来进行权限控制。

#永久节点需要显示的删除:
delete
rmr
#临时节点可显示删除,也可断开时自动消失

节点的类型一共以四种
	临时
	永久
	有序的临时节点
	有序的永久节点
 
#创建顺序节点:
create -s /test 123
#创建永久节点:
create /test-p 123p

#读取节点
#路径下的子节点列表:ls path [watch]
ls /
#获取节点信息:get path [watch]
get /test
#获取路径节点信息和路径下子节点列表	ls2 path [watch]
ls2 /test

#更新节点:set path data [version]
#data就是要更新的新内容,version表示数据版本。
set /test abc

#删除节点
#delete path [version]
#若删除节点存在子节点,那么无法删除该节点,必须先删除子节点,再删除父节点。
delete /test

#rmr path
#可以递归删除节点。
rmr /test

#quota
#setquota -n|-b val path  对节点增加限制。
# n:表示子节点的最大个数
# b:表示数据值的最大长度
# val:子节点最大个数或数据值的最大长度
# path:节点路径
setquota -n 2 /quota #设定test下只能有一个子节点
setquota -b 20 /quota	#设定test节点只能存放20b数据
listquota path  #列出指定节点的quota
listquota /quota

delquota [-n|-b] path  #删除quota
delquota -n /quota
delquota -b /quota

history  #列出命令历史

redo  #该命令可以重新执行指定命令编号的历史命令,命令编号可以通过history查看
redo 11

4.6、权限控制ACL

zookeeper有ACL( Access Control List )权限控制,可以控制节点的读写操作,保证数据的安全性。
ACL权限设置三部分组成,分别是权限模式、授权对象、权限信息。
权限设置:setAcl
权限查看:getAcl

权限模式
zookeeper服务器进行权限验证的方式,比如手机的指纹解锁、密码解锁。
权限模式分为两类:

  • 范围验证: 范围就是zookeeper可以针对一个ip或者一段ip地址授予权限,相当于手机的指纹解锁;
  • 口令验证: 可以理解为用户名密码的方式,相当于手机的密码解锁,知道了用户名密码后所有的人都相当于授予了权限。

授权对象
授权对象就是给用户授予权限,如果是范围验证,那么授权对象就是ip地址,如果是口令验证,授权对象就是用户名。

授权信息
授权信息就是指用户具体有什么权力,比如我们手机解锁成功后,可以选择打电话、发微信或者上网查资料。

4.7、数据的持久化

zookeeper的数据存储在内存中,数据的持久化有记录事务日志和快照两种方式。

记录事务日志:
在配置文件zoo.cfg中,利用dataDir来指定事务日志存放位置。
随着磁盘不断进行IO操作,事务日志也会不断增多,占用的磁盘空间会不断增加,为避免磁盘空间的占用影响系统性能,可以通过参数zookeeper.preAllocSize来对磁盘进行设置。

五、ZooKeeper Watcher机制

ZooKeeper中引入了Watcher机制的概念,实现了分布式数据发布/订阅功能,定义了一种一对多的订阅关系,能让多个订阅者同时监听某一个主题对象,当这个主题对象自身状态变化时,会通知所有订阅者,使他们能够做出相应的处理。

5.1、Watcher机制

Watcher机制流程:

  • 客户端向服务端注册一个Watcher监听;
  • 服务端的一些事件触发Watcher监听;
  • 向指定客户端发送一个事件通知。

Watcher机制特点:

特点描述
事件封装ZooKeeper使用WatchedEvent对象来封装服务端事件并进行传递
事件属性通知状态(keeperState);事件类型(EventType);节点路径(path)
先注册再触发Watcher机制,必须客户端先去服务端注册监听,事件发送才会触发监听,通知给客户端
一次性触发事件发生触发监听,一个watcher event就会被发送到设置监听的客户端,这种效果是一次性的,后续再次发生同样的事件,不会再次触发
event异步发送watcher的通知事件从服务端发送到客户端是异步的
触发event种类节点创建,节点删除,节点改变,子节点改变等

5.2、通知状态和事件类型

同一个事件类型在不同的通知状态中代表的含义有所不同:

Keeper StateEventType触发条件说明
None(-1)客户端与Zookeeper服务端建立连结成功
Disconnected(0))None(-1)客户端与Zookeeper服务器断开连结
AuthFailed(4))None(-1)通常有2种情况:1.使用错误的schema进行权限检查;2.SASL权限检查失败同时也会收到AuthFailedException异常
Expired(-112))Node(-1)会话超时客户端会话失效,通常同时会收到SessionExpiredException异常
SyncConnected(0)NodeCreated(1)Watcher监听的对应数据节点被创建
NodeDeleted(2)Watcher监听的对应数据节点被删除此时客户端与服务端处于连结状态
NodeDataChanged(3)Watcher监听的对应数据节点的数据内容发生变更
NodeChildChanged(4)Watcher监听的对应数据节点的子节点列表发生变更

5.3、用途

master选举的Znode监听
当备用的master发现Znode已经被其它master创建后,这时备用master会注册监听这个Znode的变化。

锁机制
基于监听机制上才能实现,比如释放锁的时候,需要告诉其它访问的应用这个Znode代表的锁已经释放,通知其它应用可以获取锁以进行下一步操作。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值