目录

ZooKeeper的概念和基础

概述

ZK基础

ZK 操作和维护的小型数据节点称为 znode,采用类似文件系统的层级树状结构进行管理。

API概述

znode 节点可能含有数据,也可能没有,如果含有任何数据,那么数据存储为字节数组,ZK 不提供解析的支持,可以自行选择使用如 Protocol Buffers, Thrift, Avro, MessagePack 等序列化方式。

ZK 不允许局部写入或读取 znode 节点的数据,当设置一个 znode 节点的数据或读取时,znode 节点的内容会被整个替换或全部读取进来。

ZK 客户端连接到 ZooKeeper 服务,通过 API 调用来建立会话。

znode不同类型

当新建 znode 时候,还需要指定该节点的类型,不同类型决定了 znode 节点的行为方式。

持久节点和临时节点 znode 节点可以是持久节点,还可以是临时节点。持久的 znode,如 /path,只能通过 delete 进行删除,临时的 znode 与之相反,当创建该节点的客户端崩溃,或关闭了与 ZK 连接,这个节点就会被删除。

有序节点 一个 znode 还可以设置为有序节点,一个有序节点被分配唯一一个单调递增的整数,当创建一个有序 znode 节点,其路径为 /task/task-,那么 ZK 会分配一个序号,加到路径后面。

监视与通知

ZK 通常以远程服务的方式被访问,如果每次访问 znode 的时候,客户端都需要获取节点的内容,那么代价就非常大了。因为这样会导致更高的延迟,而且 ZK 需要做更多的操作。

ZK 客户端向 ZK 注册需要接收通知的 znode,通过对 znode 及诶单设置监视点来接收通知,客户端必须在每次通知后设置一个新的监视点。当节点 /tasks 发生变化的时候,客户端会收到一个通知,并从 ZK 读取一个新值。

版本

每个 znode 都有一个版本号,随着每次数据变化而自增,两个 API 操作可以有条件地执行,setData 和 delete,这两个调用以版本号作为转入参数,只有当转入参数的版本号与服务器上的版本号一致的时候才是调用成功。

ZK架构

ZK 服务器端运行两种模式,独立模式、仲裁模式。

警告
本文最后更新于 2017年2月1日,文中内容可能已过时,请谨慎参考。