2.1 ZooKeeper基础

2018-05-23 11:22:15.0

2.1.1 API概述

ZooKeeper的API暴露了以下方法:

API描述
create /path data创建一个名为/path的znode节点,并包含数据data
delete /path删除名为/path的znode
exists /path检查是否存在名为/path的节点
setData /path data设置名为/path的节点的znode的数据为data
getData /path获取名为/path的节点的数据信息
getChildren /path获取/path节点的所有子节点列表

2.1.2 znode的不同类型

持久节点和临时节点

持久节点(persistent):只能通过delete来删除

临时节点(ephemeral):当创建节点的客户端崩溃或关闭了与zk的连接时,或调用delete,就会被删除。因为临时节点在其创建者的会话过期时被删除,因此不允许临时节点拥有子节点。

有序节点

有序节点(sequential):一个有序znode节点被分配唯一一个单调递增的整数。当创建有序节点时,一个序号会被追加到路径之后。

总之,znode一共有4种类型:持久的(persistent)、临时的(ephemeral)、持久有序的(persistent_sequential)和临时有序的(ephemeral_sequential)

2.1.3 监视和通知

zookeeper通常以远程服务的方式被访问,如果每次访问znode时,客户端都需要获得节点中的内容,这样的代价就非常大。(例如通过轮询来判断节点内容是否变化)。这样的话延迟会很高。

一种更好的方式是通知机制:客户端向ZooKeeper注册需要接收通知的znode,通过对znode设置监视点(watch)来接收通知。

当使用通知机制时,因为通知机制是单次触发的操作,所以客户端接收一个znode变更通知并设置新的监视点的时间中间,znode节点也许发生了新的变化。

那通知机制会不会错过变化呢?如果在接收通知并设置监视点之前,其他客户端改变了数据,因为设置监视节点前,都会伴随一次读取操作,因此不会错过。

通知机制的一个重要保障是,先向客户端传送通知,再对该节点进行变更操作。

2.1.4 版本

    基于版本的乐观锁