Zookeeper服务
您目前处于:大数据  2014年07月28日

数据模型

Zookeeper维护着一个树形层次结构,树中的节点称为znode。znode可以用于存储数据,并且有一个与之相关联的ACL。Zookeeper被设计用来实现协调服务,通常是小数据文件,而不是用于大数据容器存储,因此一个znode能存储的数据被限制在1MB以内。

Zookeeper的数据访问具有原子性。客户端在读取一个znode的数据时,要么读取到所有数据,要么读操作失败,不会只读到部分数据。同样,写操作将替换znode存储额所有数据。Zookeeper会保证写操作不成功就失败,不会出现部分写之类的情况,也就是不会出现只保存客户端所写部分数据的情况。Zookeeper不支持添加操作。这些特性和HDFS不同,HDFS被设计用于大数据存储,支持流式数据访问和添加操作。

znode通过路径被引用。像Unix中文件操作路径一样,在Zookeeper中路径被表示成用斜杠分隔的Unicode字符串。与Unix中的文件系统路径不同,Zookeeper中路径必须是绝对路径,也就是说每条路径必须从一个斜杠字符开始。

短暂znode

znode有两种类型:短暂和持久的。znode的类型在创建时确定并且之后不能再修改。在创建短暂znode的客户端回话结束时,Zookeeper会将该短暂znode删除。相比之下,持久znode不依赖于客户端会话,只有当客户端明确要删除该持久znode时才会被删除,短暂znode不可以有子节点,即使是短暂子节点。

观察

znode以某种方式发生变化时,"观察"(watch)机制可以让客户端得到通知。可以针对ZooKeepr服务的操作来设置观察,该服务的其他操作可以触发观察。

观察只触发一次。为了能够多次收到通知,客户端需要重新注册所需的观察。

操作

Zookeeper服务的操作

create:创建一个znode(必须要有父节点)
delete:删除一个znode(该znode不能有任何子节点)
exists:测试一个znode是否存在并且查询它的元数据
getACL,setACL:获取/设置一个znode的ACL
getCHildren:获取一个znode的子节点列表
getData,setData:获取/设置一个znode所保存的数据
sync:将客户端的znode视图和Zookeeper同步

观察触发器

在读操作exist、getChildren和getData上可以设置观察,这些观察可以被写操作create、delete和setData出发。ACL相关的操作不参与任何观察。当一个观察被触发时会产生一个观察事件,这个观察和触发它的操作共同决定了观察时间的类型。

当所观察的znode被创建、删除或其数据被更新时,设置在exists操作上的观察将被触发。

当所观察的znode被删除或其数据被更新时,设置在getData操作上的观察将被触发。创建znode不会出发getData操作上的观察,因为getData操作成功执行的前提是znode必须已经存在。

当所观察的znode的一个子节点被创建或删除时,或所观察的znode自己被删除时,设置在getChildren操作上的观察将会被触发。你可以通过观察事件的类型来判断被删除的是znode还是其子节点:NodeDelete代表znode被删除;NodeCHildrenChanged代表一个子节点被删除。

ACL

ACL权限:

CREATE:create(子节点)
READ:getChildren、getData
WRITE:setData
DELETE:delete(子节点)
ADMIN:setACL

注意exists操作不受ACL权限的限制,因此任何客户端都可以调用exists来检查一个znode的状态或查询一个znode是否存在。

在类ZooDefs.Ids中有一些预定义的ACL,OPEN_ACL_UNSAFE是其中一只,它将所有的权限(不包括ADMIN)授予每个人。

实现

从概念上来说,Zookeeper是非常简单的:它所做的就是确保对znode数的每一个修改都会被复制到集合体中超过半数的机器上。如果少于半数的机器出现故障,则最少有一台机器会保存最新的状态。其余的副本最终也会更新到这个状态。

然而,这个简单想法的实现却并不简单。Zookeeper使用了Zab协议,该协议包含两个可以无限重复的阶段:

阶段1:领导者选举

集合体中的所有机器通过一个选择过程来选出一台被称为"领导者"的机器,其他的机器被称为"跟随者"。一旦半数以上的跟随者已经将其状态与领导者同步,则表明这个阶段已经完成。

阶段2:原子广播

所有的写请求都被转发给领导者,再由领导者将更新广播给跟随者。当半数以上的跟随者已经将修改持久化之后,领导者才会提交这个更新,然后客户端才会收到一个更新成功的响应。这个用来达成共识的协议被设计成具有原子性,因此每个修改要么成功要么失败。这类似于数据库中的两个阶段提交协议。

如果领导者出现故障,其余机器会选出另外一个领导者,并和新的领导者一起继续提供服务。随后,如果之前的领导者恢复正常,便成为一个跟随者。领导者选举的过程非常快,根据一个已发表的结果来看,只需要200毫秒,因此在领导者选举的过程中不会出现性能明显降低。

一致性

对于Zookeeper来说,理想的情况就是将客户端你都连接到与领导者状态一致的服务器上。每个客户端都可能被连接到领导者,但客户端对比无法控制,甚至它自己也不知道是否连接到领导者。

在Zookeeper中设计中,以下几点考虑保证了数据的一致性。

顺序一致性:来自任意特定客户端的更新都会被其发送顺序被提交。也就是说,如果一个客户端将znode z值更新为a,在之后的操作中,它又将z值更新为b,则没有客户端能够在看到z的值是b之后还能看到z值是a。

原子性:每个更新操作要么成功,要么失败。这意味着如果一个更新失败,则不会有客户端看到这个更新的结果。

单一系统映像:一个客户端无论链接到哪一台服务器,它看到的都是同样的系统视图。这意味着,如果一个客户端在同一个会话中连接到一台新的服务器,它所看到的系统状态不会比之前服务器上看到的更老。当一台服务器出现故障,导致它的一个客户端需要尝试连接集合体中其他的服务U奇时,所有滞后于鼓掌服务器的服务器都不会接受该链接请求,除非这些服务器赶上故障服务器。

持久性:一个更新一旦成功,其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。

及时性:任何客户端所有看到的系统视图的之后都是有限的,不会超过几十秒。这意味着与其允许一个客户端看到非常陈旧的数据,还不如将服务器关闭,强迫客户端连接到一个状态交心的服务器。

会话

每个Zookeeper客户端的配置中都包括集合体中服务器的列表。在启动时,客户端会尝试连接到列表中的一台服务器。如果连接失败,它会尝试连接另一台服务器,一次类推,直到成功与一台服务器建立连接或因为所有Zookeeper服务器都不可用而失败。

一旦客户端与一台Zookeeper服务器建立连接,这台服务器就会为该客户端创建一个新的会话,每个会话都会有一个超时的时间设置,这个设置由创建会话的应用来设定。如果服务器在超时时间段内没有收到任何请求,则相应的会话会过期。一旦一个会话过期,就无法重新打开,并且任何与该会话相关联的短暂znode都会丢失。会话通常长期存在,而且会话过期是一种比较罕见的事情,但对应用来说,如何处理会话过期仍是非常重要的。

Zookeeper客户端可以自动地进行故障切换,切换到另一台Zookeeper服务器,并且,关键的一点是,在另一台服务器接管故障服务器之后,所有的绘画(和相关的短暂znode)仍然有效。

在故障切换过程中,应用程序将接收到断开连接和连接至服务器的通知,当客户端断开连接时,观察通知将无法发送,但是当客户端成功恢复连接后,这些延迟的通知会被发送。当然,在客户端重新连接到另一台服务器的过程中,如果应用程序试图执行一个操作,这个操作就会失败,这充分体现了Zookeeper应用中处理连接丢失异常的重要性。

状态

Zookeeper对象在其生命周期中会经历集中不同的状态,你可以在任何时候通过getState()方法来查询对象的状态:

public states getState()

Zookeeper状态转化图:


转载请并标注: “本文转载自 linkedkeeper.com ”