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
升级会员 