zookeeper原理Word文档下载推荐.docx
《zookeeper原理Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《zookeeper原理Word文档下载推荐.docx（14页珍藏版）》请在冰豆网上搜索。
全局有序是指如果在一台效劳器上消息a在消息b前发布，那么在所有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.Leader根据follower的zxid确定同步点；
4.完成同步后通知follower已经成为uptodate状态；
5.Follower收到uptodate消息后，又可以重新承受client的请求进展效劳了。
流程图如下所示：
2.3工作流程
Leader主要有三个功能：
1.恢复数据；
2.维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
3.Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进展不同的处理。
PING消息是指Learner的心跳信息；
REQUEST消息是Follower发送的提议信息，包括写请求与同步请求；
ACK消息是Follower的对提议的回复，超过半数的Follower通过，那么commit该提议；
REVALIDATE消息是用来延长SESSION有效时间。
Leader的工作流程简图如下所示，在实际实现中，流程要比下列图复杂得多，启动了三个线程来实现功能。
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的工作流程简图如下所示，在实际实现中，Follower是通过5个线程来实现功能的。
对于observer的流程不再表达，observer流程和Follower的唯一不同的地方就是observer不会参加leader发起的投票。
主流应用场景：
Zookeeper的主流应用场景实现思路〔除去官方示例〕
（1）配置管理
集中式的配置管理在应用集群中是非常常见的，一般商业公司部都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。
Zookeeper很容易实现这种集中式的配置管理，比方将APP1的所有配置配置到/APP1znode下，APP1所有机器一启动就对/APP1这个节点进展监控（zk.exist（"
/APP1"
true））,并且实现回调方法Watcher，那么在zookeeper上/APP1znode节点下数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可（zk.getData（"
false,null））;
以上这个例子只是简单的粗颗粒度配置监控，细颗粒度的数据可以进展分层级监控，这一切都是可以设计和控制的。
（2）集群管理
应用集群中，我们常常需要让每一个机器知道集群中〔或依赖的其他某一个集群〕哪些机器是活着的，并且在集群机器因为宕机，网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。
Zookeeper同样很容易实现这个功能，比方我在zookeeper效劳器端有一个znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创立一个EPHEMERAL类型的节点，比方server1创立/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生成ZookeeperCAPI的帮助文档。
Zookeeper中最有特色且最不容易理解的是监视（Watches）。
Zookeeper所有的读操作——getData（）,
getChildren（）,和
exists（）
都可以设置监视（watch），监视事件可以理解为一次性的触发器，官方定义如下：
awatcheventisone-timetrigger,senttotheclientthatsetthewatch,whichoccurswhenthedataforwhichthewatchwassetchanges。
对此需要作出如下理解：
〔一次性触发〕One-timetrigger
当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了getData（"
/znode1"
true）并且稍后/znode1节点上的数据发生了改变或者被删除了，客户端将会获取到/znode1发生变化的监视事件，而如果/znode1再一次发生了变化，除非客户端再次对/znode1设置监视，否那么客户端不会收到事件通知。
〔发送至客户端〕Senttotheclient
Zookeeper客户端和效劳端是通过socket进展通信的，由于网络存在故障，所以监视事件很有可能不会成功地到达客户端，监视事件是异步发送至监视者的，Zookeeper本身提供了保序性（orderingguarantee）：
即客户端只有首先看到了监视事件后，才会感知到它所设置监视的znode发生了变化（aclientwillneverseeachangeforwhichithassetawatchuntilitfirstseesthewatchevent）.网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但是不同的客户端所看到的一切具有一致的顺序。
〔被设置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结构为：
struct
Id
{
char
*
scheme;
id;
};
structACL结构为：
ACL
int32_t
perms;
structACL_vector结构为：
ACL_vector
count;
*data;
与znode访问权限有关的常量
const
int
ZOO_PERM_READ;
//允许客户端读取znode节点的值以与子节点列表。
ZOO_PERM_WRITE;
//允许客户端设置znode节点的值。
ZOO_PERM_CREATE;
//允许客户端在该znode节点下创立子节点。
ZOO_PERM_DELETE;
//允许客户端删除子节点。
ZOO_PERM_ADMIN;
//允许客户端执行set_acl（）。
ZOO_PERM_ALL;
//允许客户端执行所有操作，等价与上述所有标志的或（OR）。
与ACLIDs相关的常量
IdZOO_ANYONE_ID_UNSAFE;
//（‘world’,’anyone’）
IdZOO_AUTH_IDS;
//（‘auth’,’’）
三种标准的ACL
1、struct
ACL_vectorZOO_OPEN_ACL_UNSAFE;
//（ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE）
2、struct
ACL_vectorZOO_READ_ACL_UNSAFE;
//（ZOO_PERM_READ,ZOO_ANYONE_ID_UNSAFE）
3、struct
ACL_vectorZOO_CREATOR_ALL_ACL;
//（ZOO_PERM_ALL,ZOO_AUTH_IDS）
与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位字符的序号，如/xyz0000000000,/xyz0000000001,/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（）设置监视。
ZOO_DELETED_EVENT;
//节点被删除，通过zoo_exists（）和zoo_get（）设置监视。
ZOO_CHANGED_EVENT;
//节点发生变化，通过zoo_exists（）和zoo_get（）设置监视。
ZOO_CHILD_EVENT;
//子节点事件，通过zoo_get_children（）和zoo_get_children2（）设置监视。
ZOO_SESSION_EVENT;
//会话丧失
ZOO_NOTWATCHING_EVENT;
//监视被移除。
ZookeeperCAPI错误码介绍
ZOO_ERRORS
ZOK
正常返回
ZSYSTEMERROR
系统或效劳器端错误（Systemandserver-sideerrors），效劳器不会抛出该错误，该错误也只是用来标识错误围的，即大于该错误值，且小于ZAPIERROR都是系统错误。
ZRUNTIMEINCONSISTENCY
运行时非一致性错误。
ZDATAINCONSISTENCY
数据非一致性错误。
ZCONNECTIONLOSS
Zookeeper客户端与效劳器端失去连接
ZMARSHALLINGERROR
在
marshalling
和
unmarshalling
数据时出现错误（Errorwhilemarshallingorunmarshallingdata）
ZUNIMPLEMENTED
该操作未实现（Operationisunimplemented）
ZOPERATIONTIMEOUT
该操作超时（Operationtimeout）
ZBADARGUMENTS
非法参数错误（Invalidarguments）
ZINVALIDSTATE
非法句柄状态（Invliadzhandlestate）
ZAPIERROR
API错误（APIerrors），效劳器不会抛出该错误，该错误也只是用来标识错误围的，错误值大于该值的标识API错误，而小于该值的标识ZSYSTEMERROR。
ZNONODE
节点不存在（Nodedoesnotexist）
ZNOAUTH
没有经过授权（Notauthenticated）
ZBADVERSION
版本冲突（Versionconflict）
ZNOCHILDRENFOREPHEMERALS
临时节点不能拥有子节点（Ephemeralnodesmaynothavechildren）
ZNODEEXISTS
节点已经存在（Thenodealreadyexists）
ZNOTEMPTY
该节点具有自身的子节点（Thenodehaschildren）
ZSESSIONEXPIRED
会话过期（Thesessionhasbeenexpiredbytheserver）
ZINVALIDCALLBACK
非法的回调函数（Invalidcallbackspecified）
ZINVALIDACL
非法的ACL（InvalidACLspecified）
ZAUTHFAILED
客户端授权失败（Clientauthenticationfailed）
ZCLOSING
Zookeeper连接关闭（ZooKeeperisclosing）
ZNOTHING
并非错误，客户端不需要处理效劳器的响应（noterror,noserverresponsestoprocess）
ZSESSIONMOVED
会话转移至其他效劳器，所以操作被忽略（sessionmovedtoanotherserver,sooperationisignored）
Watch事件类型：
ZOO_CREATED_EVENT：
节点创立事件，需要watch一个不存在的节点，当节点被创立时触发，此watch通过zoo_exists（）设置ZOO_DELETED_EVENT：
节点
升级会员 