zookeeper原理Word格式.docx
- 文档编号:20802262
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:14
- 大小:25.08KB
zookeeper原理Word格式.docx
《zookeeper原理Word格式.docx》由会员分享,可在线阅读,更多相关《zookeeper原理Word格式.docx(14页珍藏版)》请在冰豆网上搜索。
发布,则在所有Server上消息a都将在消息b前被发布;
偏序是指如果一个消息b在消息a
后被同一个发送者发布,a必将排在b前面。
2ZooKeeper的工作原理
Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。
实现这个机制的
协议叫做Zab协议。
Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。
当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举岀来,且大多数
Server完成了和leader的状态同步以后,恢复模式就结束了。
状态同步保证了leader和
Server具有相同的系统状态。
为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。
所有的提议(proposal)都在被提岀的时候加上了zxid。
实现中zxid是一个64位的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选岀来,它都会有一个新的epoch,标识当前属于那个leader的统治时期。
低32位用于递增计数。
每个Server在工作过程中有三种状态:
LOOKING:
当前Server不知道leader是谁,正在搜寻
LEADING:
当前Server即为选举出来的leader
FOLLOWING:
leader已经选举出来,当前Server与之同步
2.1选主流程
当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举岀一个新的leader,让所有的Server都恢复到一个正确的状态。
Zk的选举算法有
两种:
一种是基于basicpaxos实现的,另外一种是基于fastpaxos算法实现的。
系统默认
的选举算法为fastpaxos。
先介绍basicpaxos流程:
1.选举线程由当前Server发起选举的线程担任,其主要功能是对投票结果进行统计,并选岀
推荐的Server;
2.选举线程首先向所有Server发起一次询问(包括自己);
3.选举线程收到回复后,验证是否是自己发起的询问(验证zxid是否一致),然后获取对方的
id(myid),并存储到当前询问对象列表中,最后获取对方提议的leader相关信息(id,zxid),并
将这些信息存储到当次选举的投票记录表中;
4.收到所有Server回复以后,就计算出
zxid最大的那个Server,并将这个Server相关信
息设置成下一次要投票的
Server;
5.线程将当前zxid最大的Server设置为当前Server要推荐的Leader,如果此时获胜的
Server获得n/2+1的Server票数,设置当前推荐的leader为获胜的Server,将根据获胜
的Server相关信息设置自己的状态,否则,继续这个过程,直到leader被选举出来。
通过流程分析我们可以得岀:
要使Leader获得多数Server的支持,则Server总数必须是奇
数2n+1,且存活的Server的数目不得少于n+1.
每个Server启动后都会重复以上流程。
在恢复模式下,如果是刚从崩溃状态恢复的或者刚启
动的server还会从磁盘快照中恢复数据和会话信息,zk会记录事务日志并定期进行快照,方
便在恢复时进行状态恢复。
选主的具体流程图如下所示:
fastpaxos流程是在选举过程中,某Server首先向所有Server提议自己要成为leader,当
其它Server收到提议以后,解决epoch和zxid的冲突,并接受对方的提议,然后向对方发
送接受提议完成的消息,重复这个流程,最后一定能选举岀Leader。
其流程图如下所示:
2.2同步流程
选完leader以后,zk就进入状态同步过程。
1.leader等待server连接;
2.Follower连接leader,将最大的zxid发送给leader;
3丄eader根据follower的zxid确定同步点;
4.完成同步后通知follower已经成为uptodate状态;
5.Follower收到uptodate消息后,又可以重新接受client的请求进行服务了
流程图如下所示:
2.3工作流程
2.3.1Leader工作流程
Leader主要有三个功能:
1•恢复数据;
2.维持与Learner的心跳,接收Learner请求并判断Learner的请求消息类型;
|
3丄earner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息,
根据不同的消息类型,进行不同的处理。
PING消息是指Learner的心跳信息;
REQUEST消息是Follower发送的提议信息,包括
写请求及同步请求;
ACK消息是Follower的对提议的回复,超过半数的Follower通过,
则commit该提议;
REVALIDATE消息是用来延长SESSION有效时间。
Leader的工作流程简图如下所示,在实际实现中,流程要比下图复杂得多,启动了三个
线程来实现功能
232Follower工作流程
Follower主要有四个功能:
1.向Leader发送请求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息);
2.接收Leader消息并进行处理;
3.接收Client的请求,如果为写请求,发送给Leader进行投票;
4.返回Client结果。
Follower的消息循环处理如下几种来自Leader的消息:
1.PING消息:
心跳消息;
2.PROPOSAL消息:
Leader发起的提案,要求Follower投票;
3.COMMIT消息:
服务器端最新一次提案的信息;
4.UPTODATE消息:
表明同步完成;
5.REVALIDATE消息:
根据Leader的REVALIDATE结果,关闭待revalidate的session
是允许其接受消息;
6.SYNC消息:
返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制得到最新的
更新
Follower是通过5个线程来实现功
Follower的工作流程简图如下所示,在实际实现中,
能的。
对于observer的流程不再叙述,observer流程和Follower的唯一不同的地方就是
observer不会参加leader发起的投票。
主流应用场景:
Zookeeper的主流应用场景实现思路(除去官方示例)
(1)配置管理
(2)集中式的配置管理在应用集群中是非常常见的,一般商业公司内部都会实现一套集
中的配置管理中心,应对不同的应用集群对于共享各自配置的需求,并且在配置变更
时能够通知到集群中的每一个机器。
(3)
(4)Zookeeper
很容易实现这种集中式的配置管理,比如将
APP1的所有配置配置到
/APP1znode
下,APP1所有机器一启动就对/APP1
这个节点进行监控
(zk.exist(
"
/APP1"
true)),并且实现回调方法
Watcher,那么在
zookeeper
上/APP1znode
节点下数据发生变化的时候,每个机器都会收到通知,
Watcher方
法将会被执行,
那么应用再取下数据即可(zk.getData(
false,null
));
以上这个例子只是简单的粗颗粒度配置监控,细颗粒度的数据可以进行分层级监控,这一切都是可以设计和控制的。
(5)集群管理(6)应用集群中,我们常常需要让每一个机器知道集群中(或依赖的其他某一个集群)哪些机器是活着的,并且在集群机器因为宕机,网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。
⑺
(8)Zookeeper同样很容易实现这个功能,比如我在zookeeper服务器端有一个
znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创建一
个EPHEMERAL类型的节点,比如serverl创建/APP1SERVERS/SERVER1(可以使用ip,保证不重复),server2创建/APP1SERVERS/SERVER2,然后SERVER1禾口SERVER2都watch/APP1SERVERS这个父节点,那么也就是这个父节点下数据或
者子节点变化都会通知对该节点进行watch的客户端。
因为EPHEMERAL类型节点有
一个很重要的特性,就是客户端和服务器端连接断掉或者session过期就会使节点
消失,那么在某一个机器挂掉或者断链的时候,其对应的节点就会消失,然后集群中
所有对/APP1SERVERS进行watch的客户端都会收到通知,然后取得最新列表即可。
另外有一个应用场景就是集群选
master,一旦master
挂掉能够马上能从
slave
中
选岀一个master,实现步骤和前者
样,只是机器在启动的时候在
APP1SERVERS
创建
的节点类型变为EPHEMERAL_SEQUENTIAL类型,这样每个节点会自动被编号
我们默认规定编号最小的为
master,所以当我们对
/APP1SERVERS节点做监控的
时候,得到服务器列表,只要所有集群机器逻辑认为最小编号节点为
master,那么
master就被选岀,而这个
master宕机的时候,相应的
znode会消失,然后新的服务
器列表就被推送到客户端,然后每个节点逻辑认为最小编号节点为
master,这样就做到
动态master选举。
Zookeeper监视(Watches)简介
ZookeeperCAPI的声明和描述在include/zookeeper.h中可以找到,另外大部分的
ZookeeperCAPI常量、结构体声明也在zookeeper.h中,如果如果你在使用CAPI是
遇到不明白的地方,最好看看zookeeper.h,或者自己使用doxygen生成ZookeeperC
API的帮助文档。
Zookeeper中最有特色且最不容易理解的是监视(Watches)。
Zookeeper所有的读操作一
—getData(),getChildren(),和exists。
都可以设置监视(watch),监视事件可以理解为
一次性的触发器,官方定义如下:
awatcheventisone-timetrigger,senttotheclient
thatsetthewatch,whichoccurswhenthedataforwhichthewatchwassetchanges<
对此需要作出如下理解:
(一次性触发)One-timetrigger
当设置监视的数据发生改变时,该监视事件会被发送到客户端,例如,如果客户端调用了
getData("
/znode1"
true)并且稍后/znode1节点上的数据发生了改变或者被删除了,客
户端将会获取到/znode1发生变化的监视事件,而如果/znode1
再一次发生了变化,除非
客户端再次对/znode1设置监视,否则客户端不会收到事件通知。
(发送至客户端)Senttotheclient
Zookeeper客户端和服务端是通过socket进行通信的,由于网络存在故障,所以监视事件
很有可能不会成功地到达客户端,监视事件是异步发送至监视者的,Zookeeper本身提供了
保序性(orderingguarantee):
即客户端只有首先看到了监视事件后,才会感知到它所设置监
视的znode发生了变化(aclientwillneverseeachangeforwhichithassetawatch
untilitfirstseesthewatchevent).网络延迟或者其他因素可能导致不同的客户端在不同的|
时刻感知某一监视事件,但是不同的客户端所看到的一切具有一致的顺序。
(被设置watch的数据)Thedataforwhichthewatchwasset
这意味着znode节点本身具有不同的改变方式。
你也可以想象Zookeeper维护了两条监视
链表:
数据监视和子节点监视(datawatchesandchildwatches)getData()andexists()设
置数据监视,getChildren()设置子节点监视。
或者,你也可以想象Zookeeper设置的不
同监视返回不同的数据,getData()和exists()返回znode节点的相关信息,而
getChildren()返回子节点列表。
因此,setData()会触发设置在某一节点上所设置的数据监
视(假定数据设置成功),而一次成功的create()操作则会出发当前节点上所设置的数据监视
以及父节点的子节点监视。
一次成功的delete()操作将会触发当前节点的数据监视和子节点
监视事件,同时也会触发该节点父节点的childwatch。
Zookeeper中的监视是轻量级的,因此容易设置、维护和分发。
当客户端与Zookeeper服
务器端失去联系时,客户端并不会收到监视事件的通知,只有当客户端重新连接后,若在必
要的情况下,以前注册的监视会重新被注册并触发,对于开发人员来说这通常是透明的。
只
有一种情况会导致监视事件的丢失,即:
通过exists()设置了某个znode节点的监视,但
是如果某个客户端在此znode节点被创建和删除的时间间隔内与zookeeper服务器失去
了联系,该客户端即使稍后重新连接zookeeper服务器后也得不到事件通知。
ZookeeperCAPI常量与部分结构(struct)介绍
与ACL相关的结构与常量:
structId结构为:
structId{char*scheme;
char*id;
};
structACL结构为:
structACL{int32_tperms;
structIdid;
structACL_vector结构为:
structACL_vector{int32_tcount;
structACL*data;
与znode访问权限有关的常量
constintZOO_PERM_READ;
//允许客户端读取znode节点的值以及子节点列表。
constintZOO_PERM_WRITE;
〃允许客户端设置znode节点的值。
constintZOO_PERM_CREATE;
//允许客户端在该znode节点下创建子节点。
constintZOO_PERM_DELETE;
〃允许客户端删除子节点。
constintZOO_PERM_ADMIN;
//允许客户端执行set_acl()。
constintZOO_PERM_ALL;
〃允许客户端执行所有操作,等价与上述所有标志的或(OR)
与ACLIDs相关的常量
structIdZOO_ANYONE_ID_UNSAFE;
//(‘world'
,‘anyone'
)
structIdZOO_AUTH_IDS;
//(‘auth'
,'
‘)
三种标准的ACL
1、structACL_vector
ZOO_OPEN_ACL_UNSAFE;
//(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE)
2、structACLvectorZOOREADACLUNSAFE;
〃(ZOOPERMREAD,
ZOO_ANYONE_ID_UNSAFE)
3、structACL_vectorZOO_CREATOR_ALL_ACL;
〃(ZOO_PERM_ALL,ZOO_AUTH」DS)
与Interest相关的常量:
ZOOKEEPER_WRITE,ZOOKEEPER_READ
这两个常量用于标识感兴趣的事件并通知zookeeper发生了哪些事件。
Interest常量可以
进行组合或(OR)来标识多种兴趣(multipleinterests:
write,read),这两个常量一般用于
zookeeper_interest()禾口zookeeper_process()两个函数中。
与节点创建相关的常量:
ZOO_EPHEMERAL,ZOO_SEQUENCE
zoo_create函数标志,ZOO_EPHEMERAL用来标识创建临时节点,ZOO_SEQUENCE用
来标识节点命名具有递增的后缀序号(一般是节点名称后填充10位字符的序号,如
/xyzOOOOOOOOOO,/xyzOOOOOOOOOl,/xyz0000000002,…),同样地,
ZOO_EPHEMERAL,ZOO_SEQUENCE可以组合。
与连接状态Stat相关的常量
以下常量均与Zookeeper连接状态有关,他们通常用作监视器回调函数的参数。
ZOOAPIconstint
ZOO_EXPIRED_SESSION_STATE
ZOO_AUTH_FAILED_STATE
ZOO_CONNECTING_STATE
ZOO_ASSOCIATING_STATE
ZOO_CONNECTED_STATE
与监视类型(WatchTypes)相关的常量
以下常量标识监视事件的类型,他们通常用作监视器回调函数的第一个参数。
ZOO_CREATED_EVENT;
//节点被创建(此前该节点不存在),通过zoo_exists()设置监视。
ZOODELETEDEVENT;
//节点被删除,通过zooexists()和zooget()设置监视。
ZOO_CHANGED_EVENT;
//节点发生变化,通过zoo_exists()和zoo_get()设置监视。
ZOO_CHILD_EVENT;
//子节点事件,通过zoo_get_children()和zoo_get_children2()设
置监视。
ZOOSESSIONEVENT;
//会话丢失
ZOONOTWATCHINGEVENT;
//监视被移除。
ZookeeperCAPI错误码介绍zoo_errors
ZOK
正常返回
ZSYSTEMERROR
系统或服务器端错误(Systemandserver-side
errors),服务器不会抛出该错误,该错误也只是用来标识错误范围的,即大于该错误值,且小于ZAPIERROR都是系统错误。
ZRUNTIMEINCONSISTENCY
运行时非一致性错误。
ZDATAINCONSISTENCY
数据非一致性错误。
ZCONNECTIONLOSS
Zookeeper客户端与服务器端失去连接
ZMARSHALLINGERROR
在marshalling禾口unmarshalling数据时出现
错误(Errorwhilemarshallingor
unmarshallingdata)
ZUNIMPLEMENTED
该操作未实现(Operationisunimplemented)
ZOPERATIONTIMEOUT
该操作超时(Operationtimeout)
ZBADARGUMENTS
非法参数错误(1nvalidarguments)
ZINVALIDSTATE
非法句柄状态(1nvliadzhandlestate)
ZAPIERROR
API错误(APIerrors),服务器不会抛出该错误,
该错误也只疋用来标识错误范围的,错误值大于该值的标识API错误,而小于该值的标识ZSYSTEMERROR。
ZNONODE
节点不存在(Nodedoesnotexist)
ZNOAUTH
没有经过授权(Notauthenticated)
ZBADVERSION
版本冲突(Versionconflict)
ZNOCHILDRENFOREPHEMERALS
临时节点不能拥有子节点(Ephemeralnodes
maynothavechildren)
ZNODEEXISTS
节点已经存在(Thenodealreadyexists)
ZNOTEMPTY
该节点具有自身的子节点(Thenodehas
children)
ZSESSIONEXPIRED
会话过期(Thesessionhasbeene
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- zookeeper 原理
![提示](https://static.bdocx.com/images/bang_tan.gif)