zookeeper使用和原理探究【转】

xinjiang

• 
  第一部分：
  

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。Zookeeper是hadoop的一个子项目，其发展历程无需赘述。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。本文简单分析zookeeper的工作原理，对于如何使用zookeeper不是本文讨论的重点。


1 Zookeeper的基本概念


1.1 角色


Zookeeper中的角色主要有以下三类，如下表所示：



系统模型如图所示：




1.2 设计目的


1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。

3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4 .等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

5.原子性：更新只能成功或者失败，没有中间状态。

6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。


2 ZooKeeper的工作原理


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的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程：

• 
  
  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会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选主的具体流程图如下所示：



fast paxos流程是在选举过程中，某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 工作流程


2.3.1 Leader工作流程


Leader主要有三个功能：

• 
  
  1 .恢复数据；
  
  
• 
  
  2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
  
  
• 
  
  3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
  
  

PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。

Leader的工作流程简图如下所示，在实际实现中，流程要比下图复杂得多，启动了三个线程来实现功能。


2.3.2 Follower工作流程


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的所有配置配置到/APP1
znode下，APP1所有机器一启动就对/APP1这个节点进行监控(zk.exist("/APP1",true)),并且实现回调方法Watcher，那么在zookeeper上/APP1
znode节点下数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可(zk.getData("/APP1",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） 简介



Zookeeper C API 的声明和描述在 include/zookeeper.h 中可以找到，另外大部分的 Zookeeper C API 常量、结构体声明也在 zookeeper.h 中，如果如果你在使用 C API 是遇到不明白的地方，最好看看 zookeeper.h，或者自己使用 doxygen 生成 Zookeeper C API 的帮助文档。

Zookeeper 中最有特色且最不容易理解的是监视(Watches)。Zookeeper 所有的读操作——getData(),getChildren(), 和exists()都
可以设置监视(watch)，监视事件可以理解为一次性的触发器， 官方定义如下： a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes。对此需要作出如下理解：

• 
  
  （一次性触发）One-time trigger
  
  当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了 getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。
  
  
• 
  
  （发送至客户端）Sent to the client
  
  Zookeeper 客户端和服务端是通过 socket 进行通信的，由于网络存在故障，所以监视事件很有可能不会成功地到达客户端，监视事件是异步发送至监视者的，Zookeeper 本身提供了保序性(ordering guarantee)：即客户端只有首先看到了监视事件后，才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set a watch until it first sees the watch event).
  网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但是不同的客户端所看到的一切具有一致的顺序。
  
  
• 
  
  （被设置 watch 的数据）The data for which the watch was set
  
  这意味着 znode 节点本身具有不同的改变方式。你也可以想象 Zookeeper 维护了两条监视链表：数据监视和子节点监视(data watches and child watches) getData() and exists() 设置数据监视，getChildren() 设置子节点监视。 或者，你也可以想象 Zookeeper 设置的不同监视返回不同的数据，getData() 和 exists() 返回 znode 节点的相关信息，而 getChildren() 返回子节点列表。因此， setData()
  会触发设置在某一节点上所设置的数据监视(假定数据设置成功)，而一次成功的 create() 操作则会出发当前节点上所设置的数据监视以及父节点的子节点监视。一次成功的 delete() 操作将会触发当前节点的数据监视和子节点监视事件，同时也会触发该节点父节点的child watch。
  
  

Zookeeper 中的监视是轻量级的，因此容易设置、维护和分发。当客户端与 Zookeeper 服务器端失去联系时，客户端并不会收到监视事件的通知，只有当客户端重新连接后，若在必要的情况下，以前注册的监视会重新被注册并触发，对于开发人员来说 这通常是透明的。只有一种情况会导致监视事件的丢失，即：通过 exists() 设置了某个 znode 节点的监视，但是如果某个客户端在此 znode 节点被创建和删除的时间间隔内与 zookeeper 服务器失去了联系，该客户端即使稍后重新连接 zookeeper服务器后也得不到事件通知。


Zookeeper C API 常量与部分结构(struct)介绍


与 ACL 相关的结构与常量：


struct Id 结构为：

structId{char*scheme;char*id;};



struct ACL 结构为：

structACL{int32_tperms;structIdid;};



struct ACL_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) 。
  
  

与 ACL IDs 相关的常量

• 
  
  structId ZOO_ANYONE_ID_UNSAFE; //(‘world’,’anyone’)
  
  
• 
  
  structId ZOO_AUTH_IDS;// (‘auth’,’’)
  
  

三种标准的 ACL

• 
  
  structACL_vector ZOO_OPEN_ACL_UNSAFE; //(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE)
  
  
• 
  
  structACL_vector ZOO_READ_ACL_UNSAFE;// (ZOO_PERM_READ, ZOO_ANYONE_ID_UNSAFE)
  
  
• 
  
  structACL_vector ZOO_CREATOR_ALL_ACL; //(ZOO_PERM_ALL,ZOO_AUTH_IDS)
  
  

与 Interest 相关的常量：ZOOKEEPER_WRITE,ZOOKEEPER_READ



这 两个常量用于标识感兴趣的事件并通知 zookeeper 发生了哪些事件。Interest 常量可以进行组合或（OR）来标识多种兴趣(multiple interests: 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 连接状态有关，他们通常用作监视器回调函数的参数。

ZOOAPI const int	ZOO_EXPIRED_SESSION_STATE
ZOOAPI const int	ZOO_AUTH_FAILED_STATE
ZOOAPI const int	ZOO_CONNECTING_STATE
ZOOAPI const int	ZOO_ASSOCIATING_STATE
ZOOAPI const int	ZOO_CONNECTED_STATE

与监视类型(Watch Types)相关的常量


以下常量标识监视事件的类型，他们通常用作监视器回调函数的第一个参数。

• 
  
  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; // 监视被移除。
  
  

Zookeeper C API 错误码介绍ZOO_ERRORS

ZOK	正常返回
ZSYSTEMERROR	系统或服务器端错误(System and server-side errors)，服务器不会抛出该错误，该错误也只是用来标识错误范围的，即大于该错误值，且小于 ZAPIERROR 都是系统错误。
ZRUNTIMEINCONSISTENCY	运行时非一致性错误。
ZDATAINCONSISTENCY	数据非一致性错误。
ZCONNECTIONLOSS	Zookeeper 客户端与服务器端失去连接
ZMARSHALLINGERROR	在marshalling和unmarshalling数据时出现错误(Error while marshalling or unmarshalling data)
ZUNIMPLEMENTED	该操作未实现(Operation is unimplemented)
ZOPERATIONTIMEOUT	该操作超时(Operation timeout)
ZBADARGUMENTS	非法参数错误(Invalid arguments)
ZINVALIDSTATE	非法句柄状态(Invliad zhandle state)
ZAPIERROR	API 错误(API errors)，服务器不会抛出该错误，该错误也只是用来标识错误范围的，错误值大于该值的标识 API 错误，而小于该值的标识 ZSYSTEMERROR。
ZNONODE	节点不存在(Node does not exist)
ZNOAUTH	没有经过授权(Not authenticated)
ZBADVERSION	版本冲突(Version conflict)
ZNOCHILDRENFOREPHEMERALS	临时节点不能拥有子节点(Ephemeral nodes may not have children)
ZNODEEXISTS	节点已经存在(The node already exists)
ZNOTEMPTY	该节点具有自身的子节点(The node has children)
ZSESSIONEXPIRED	会话过期(The session has been expired by the server)
ZINVALIDCALLBACK	非法的回调函数(Invalid callback specified)
ZINVALIDACL	非法的ACL(Invalid ACL specified)
ZAUTHFAILED	客户端授权失败(Client authentication failed)
ZCLOSING	Zookeeper 连接关闭(ZooKeeper is closing)
ZNOTHING	并非错误，客户端不需要处理服务器的响应(not error, no server responses to process)
ZSESSIONMOVED	会话转移至其他服务器，所以操作被忽略(session moved to another server, so operation is ignored)

Watch事件类型：


ZOO_CREATED_EVENT：节点创建事件，需要watch一个不存在的节点，当节点被创建时触发，此watch通过zoo_exists()设置
ZOO_DELETED_EVENT：节点删除事件，此watch通过zoo_exists()或zoo_get()设置
ZOO_CHANGED_EVENT：节点数据改变事件，此watch通过zoo_exists()或zoo_get()设置
ZOO_CHILD_EVENT：子节点列表改变事件，此watch通过zoo_get_children()或zoo_get_children2()设置
ZOO_SESSION_EVENT：会话失效事件，客户端与服务端断开或重连时触发
ZOO_NOTWATCHING_EVENT：watch移除事件，服务端出于某些原因不再为客户端watch节点时触发

• 第二部分
  

　　zookeeper介绍
zookeeper是一个为分布式应用提供一致性服务的软件，它是开源的Hadoop项目中的一个子项目，并且根据google发表的<The Chubby lock service for loosely-coupled distributed systems>论文来实现的，接下来我们首先来安装使用下这个软件，然后再来探索下其中比较重要一致性算法。

zookeeper安装和使用
zookeeper的安装基本上可以按照 http://hadoop.apache.org/zookeeper/docs/current/ zookeeperStarted.html 这个页面上的步骤完成安装，这里主要介绍下部署一个集群的步骤，因为这个官方页面似乎讲得并不是非常详细(Running Replicated Zookeeper)。


由于手头机器不足，所以在一台机器上部署了3个server,如果你手头也比较紧，也可以这么做。那么我建了3个文件夹，如下
server1 server2 server3


然后每个文件夹里面解压一个zookeeper的下载包，并且还建了几个文件夹，总体结构如下,最后那个是下载过来压缩包的解压文件
datadataLoglogszookeeper-3.3.2

那么首先进入data目录，创建一个myid的文件，里面写入一个数字，比如我这个是server1,那么就写一个1，server2对应myid文件就写入2，server3对应myid文件就写个3


然后进入zookeeper-3.3.2/conf目录，那么如果是刚下过来，会有3个文件，configuration.xml, log4j.properties,zoo_sample.cfg,这3个文件我们首先要做的就是在这个目录创建一个zoo.cfg的配置文件，当然你可以把zoo_sample.cfg文件改成zoo.cfg，配置的内容如下所示：
tickTime=2000
initLimit=5
syncLimit=2
dataDir=xxxx/zookeeper/server1/data
dataLogDir=xxx/zookeeper/server1/dataLog
clientPort=2181
server.1=127.0.0.1:2888:3888

server.2=127.0.0.1:2889:3889

server.3=127.0.0.1:2890:3890


标红的几个配置应该官网讲得很清楚了，只是需要注意的是clientPort这个端口如果你是在1台机器上部署多个server,那么每台机器都要不同的clientPort，比如我server1是2181,server2是2182，server3是2183，dataDir和dataLogDir也需要区分下。


最后几行唯一需要注意的地方就是 server.X 这个数字就是对应 data/myid中的数字。你在3个server的myid文件中分别写入了1，2，3，那么每个server中的zoo.cfg都配server.1,server.2,server.3就OK了。因为在同一台机器上，后面连着的2个端口3个server都不要一样，否则端口冲突，其中第一个端口用来集群成员的信息交换，第二个端口是在leader挂掉时专门用来进行选举leader所用。


进入zookeeper-3.3.2/bin 目录中，./zkServer.sh start启动一个server,这时会报大量错误？其实没什么关系，因为现在集群只起了1台server，zookeeper服务器端起来会根据zoo.cfg的服务器列表发起选举leader的请求，因为连不上其他机器而报错，那么当我们起第二个zookeeper实例后，leader将会被选出，从而一致性服务开始可以使用，这是因为3台机器只要有2台可用就可以选出leader并且对外提供服务(2n+1台机器，可以容n台机器挂掉)。


接下来就可以使用了，我们可以先通过 zookeeper自带的客户端交互程序来简单感受下zookeeper到底做一些什么事情。进入zookeeper-3.3.2/bin（3个server中任意一个）下，./zkCli.sh–server127.0.0.1:2182,我连的是开着2182端口的机器。


那么，首先我们随便打个命令，因为zookeeper不认识，他会给出命令的help,如下图


ls(查看当前节点数据),

ls2(查看当前节点数据并能看到更新次数等数据) ,

create(创建一个节点) ,

get(得到一个节点，包含数据和更新次数等数据),

set(修改节点)

delete(删除一个节点)


通过上述命令实践，我们可以发现，zookeeper使用了一个类似文件系统的树结构，数据可以挂在某个节点上，可以对这个节点进行删改。另外我们还发现，当改动一个节点的时候，集群中活着的机器都会更新到一致的数据。

zookeeper的数据模型
在简单使用了zookeeper之后，我们发现其数据模型有些像操作系统的文件结构，结构如下图所示




(1) 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识，如/SERVER2节点的标识就为/APP3/SERVER2

(2) Znode可以有子znode，并且znode里可以存数据，但是EPHEMERAL类型的节点不能有子节点

(3) Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本。

(4) znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和 服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了

(5) znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2

(6) znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个功能是zookeeper对于应用最重要的特性，通过这个特性可以实现的功能包括配置的集中管理，集群管理，分布式锁等等。

通过java代码使用zookeeper
Zookeeper的使用主要是通过创建其jar包下的Zookeeper实例，并且调用其接口方法进行的，主要的操作就是对znode的增删改操作，监听znode的变化以及处理。


以下为主要的API使用和解释

//创建一个Zookeeper实例，第一个参数为目标服务器地址和端口，第二个参数为Session超时时间，第三个为节点变化时的回调方法
ZooKeeperzk=newZooKeeper("127.0.0.1:2181",500000,newWatcher(){
//监控所有被触发的事件
publicvoidprocess(WatchedEventevent){
//dosomething
}
});
//创建一个节点root，数据是mydata,不进行ACL权限控制，节点为永久性的(即客户端shutdown了也不会消失)
zk.create("/root","mydata".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.PERSISTENT);

//在root下面创建一个childoneznode,数据为childone,不进行ACL权限控制，节点为永久性的
zk.create("/root/childone","childone".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.PERSISTENT);

//取得/root节点下的子节点名称,返回List<String>
zk.getChildren("/root",true);

//取得/root/childone节点下的数据,返回byte[]
zk.getData("/root/childone",true,null);

//修改节点/root/childone下的数据，第三个参数为版本，如果是-1，那会无视被修改的数据版本，直接改掉
zk.setData("/root/childone","childonemodify".getBytes(),-1);

//删除/root/childone这个节点，第二个参数为版本，－1的话直接删除，无视版本
zk.delete("/root/childone",-1);

//关闭session
zk.close();




Zookeeper的主流应用场景实现思路（除去官方示例）


(1)配置管理
集中式的配置管理在应用集群中是非常常见的，一般商业公司内部都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。


Zookeeper很容易实现这种集中式的配置管理，比如将APP1的所有配置配置到/APP1 znode下，APP1所有机器一启动就对/APP1这个节点进行监控(zk.exist("/APP1",true)),并且实现回调方法Watcher，那么在zookeeper上/APP1
znode节点下数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可(zk.getData("/APP1",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类型，这样每个节点会自动被编号，例如
zk.create("/testRootPath/testChildPath1","1".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);

zk.create("/testRootPath/testChildPath2","2".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);

zk.create("/testRootPath/testChildPath3","3".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);

//创建一个子目录节点
zk.create("/testRootPath/testChildPath4","4".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);

System.out.println(zk.getChildren("/testRootPath",false));



打印结果：[testChildPath10000000000, testChildPath20000000001, testChildPath40000000003, testChildPath30000000002]


zk.create("/testRootPath","testRootData".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.PERSISTENT);

//创建一个子目录节点
zk.create("/testRootPath/testChildPath1","1".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);

zk.create("/testRootPath/testChildPath2","2".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);

zk.create("/testRootPath/testChildPath3","3".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);

//创建一个子目录节点
zk.create("/testRootPath/testChildPath4","4".getBytes(),Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);

System.out.println(zk.getChildren("/testRootPath",false));



打印结果:[testChildPath2, testChildPath1, testChildPath4, testChildPath3]


我们默认规定编号最小的为master,所以当我们对/APP1SERVERS节点做监控的时候，得到服务器列表，只要所有集群机器逻辑认为最小编号节点为master，那么master就被选出，而这个master宕机的时候，相应的znode会消失，然后新的服务器列表就被推送到客户端，然后每个节点逻辑认为最小编号节点为master，这样就做到动态master选举。


总结　　我们初步使用了一下zookeeper并且尝试着描述了几种应用场景的具体实现思路，接下来的文章，我们会尝试着去探究一下zookeeper的高可用性与leaderElection算法。

转载:

http://cailin.iteye.com/blog/2014486

http://www.blogjava.net/BucketLi/archive/2010/12/21/341268.html