《ZooKeeper》 Chapter 2 Getting to Grips with ZooKeeper

一、ZooKeeper基础

1.1、Znode节点树

1.1.1、基本介绍

ZooKeeper的基础数据结构是一棵类似于文件系统中目录树的Znode节点树，ZooKeeper对外提供操作该Znode节点树的API，分布式应用程序可以使用这些API编写解决分布式问题的功能模块。

1.1.2、Znode节点

1、Znode节点由“路径”标识，路径从“/”起始，Znode节点可以包含内容，Znode节点可以包含子Znode节点
2、Znode节点有一个版本号属性，每次Znode节点的内容改变时，这个版本号都会自动增加
3、Znode节点的类型有3种：Persistent，Ephemeral，Sequential

1. Persistent
   创建“Persistent”类型Znode节点的会话（关于“会话”，见4.2、使用ZooKeeper实现一个分布式应用程序之“会话”）结束后，Znode节点不会被自动删除，只能通过“delete”API接口进行删除。比如在如图1所示的例子中，“/assign”Znode节点下的子节点表示一个分配关系，这个子节点由“Master”在某个会话中创建，假如这个会话结束，那么这个子节点应该继续存在，以便于任务的重新分配。
2. Ephemeral
   创建“Ephemeral”类型Znode节点的会话结束后，Znode节点会被自动删除，也可以通过“delete”API接口进行删除。比如在如图1所示的例子中，“/master”Znode节点由“Master”在某个会话中创建，当“Master”挂掉，相应的会话也会结束，那么“/master”Znode节点也应该被自动删除，这样才能表明“Master”挂掉的状态。
3. Sequential
   创建“Sequential”类型Znode节点时会自动给路径增加“填充后数字形式字符串”作为后缀，数字是全局单调递增的。比如执行create -s /helloworld data命令，最终得到的Znode节点路径是“/helloworld000000000X（X表示数字）”，后缀的具体形式跟你的设置有关。

1.1.3、一棵实际的Znode树

使用ZooKeeper开发一个遵循“Master-Worker”架构体系的简单的分布式应用程序，用到的Znode节点树如图1所示，对它进行简单介绍如下：
1、“/workers”Znode节点下新增一个节点，表示新增一个“Worker”
2、“/tasks”Znode节点下新增一个节点，表示新增一个“Task”
3、“/assign”Znode节点下新增一个节点，表示新增了一个“Task”分配给“Worker”的关系
4、“/master”Znode节点不存在，表示“Master”不存在

图1

1.2、操作Znode节点树

操作Znode节点树的API有3种：Java版驱动程序库提供的API，C版驱动程序库提供的API和命令行形式提供的API（本质上还是使用了Java版驱动程序库提供的API或者C版驱动程序库提供的API）。
以命令行形式提供的API为例进行说明：
1、create path data
创建一个Znode节点，路径标识为“path”，包含内容为“data”
2、delete path
删除路径“path”标识的Znode节点
3、set path data
重新设置路径“path”标识的Znode节点的内容
4、get path
获取路径“path”标识的Znode节点的内容

另外，为了避免“采用不间断获取Znode节点内容以得到最新Znode节点内容方式带来巨大性能损耗”的情况，可以采用“监视器”。监视器的工作机制是：Client（关于“Client”见图2）在某个Znode节点上设置一个监视器后，当该Znode节点产生变化（包括节点内容的变化，节点子节点的变化，发生节点被创建和删除事件等），会发送一个通知给该Client。
需要注意的是：由于Znode节点发生变化而发送的通知是一次性的，因此如果想继续监视该Znode节点，得在收到通知后重新设置一个监视器。

二、ZooKeeper集群

“ZooKeeper集群”有两种模式：“standalone”模式和“quorum”模式。

2.1、standalone模式

整个“ZooKeeper集群”只运行一个“ZooKeeper Server进程”，Znode节点树只被该“ZooKeeper Server进程”维护。

2.2、quorum模式

整个“ZooKeeper集群”运行多个“ZooKeeper Server进程”，Znode节点树在所有“ZooKeeper Server进程”内都有本地备份。为了让使用“quorum”模式的“ZooKeeper集群”正常且更好地运转，“ZooKeeper集群”中运行的“ZooKeeper Server进程”的数量应该为奇数N。而且对于一个Client（关于“Client”见图2）的请求，只有“ZooKeeper 集群”中有[N/2]+1个“ZooKeeper Server进程”回应已经完成处理请求时，才真正认为被完成！在这种情形中，最多可以允许N-([N/2]+1)个“ZooKeeper Server进程”不能正常工作。

三、使用ZooKeeper

见《ZooKeeper安装与运行》。

四、使用ZooKeeper实现一个分布式应用程序

4.1、使用ZooKeeper实现一个分布式应用程序之“架构体系”

架构体系如图2所示，这其实跟《ZooKeeper》 Chapter 1 Introduction中的图1一致，说明也可参照《ZooKeeper》 Chapter 1 Introduction。

图2

4.2、使用ZooKeeper实现一个分布式应用程序之“会话”

4.2.1、会话的基本概念

参照图2，Client必须与Server建立会话，才能进行后续操作。具体来说是，Client通过Client Library与ZooKeeper集群中的某台Server进行连接建立会话。

4.2.2、会话的状态

会话的状态包括4种，分别是：CONNECTING，CONNECTED，CLOSED和NOT_CONNECTED。

4.2.3、会话的结束

会话的结束就是将会话的状态置为“CLOSED”，有两种途径可以结束会话。
1、会话的Client方发出指令，显式结束会话。
2、会话的Server方在“timeout”时间内没有收到来自会话的Client方的任何数据，就会认为该会话过期，将该会话结束。这个“timeout”值可以由自己进行设置。

4.3、使用ZooKeeper实现一个分布式应用程序具体案例

可以使用“命令行形式提供的API”来实现一个简单的遵循“Master-Worker”架构体系的分布式应用程序，这里不作深入阐述。
使用“Java版驱动程序库提供的API”进行实现，可参见《ZooKeeper》 Chapter 3 Getting Started with the ZooKeeper API。