第二章：了解zookeeper

zookeeper并不直接暴露原语，取而代之它暴露了由一部分调用方法组成的类似文件系统的API。以便允许应用实现自己的原语。

zookeeper操作和维护一个小型的数据节点，这些节点被称为znode，采用类似文件系统的层级树状结构进行管理。

znode节点可能包含数据，也可能不含数据，如果一个znode节点包含任何数据，那么数据存储为字节数组（byte array）。字节数组的具体格式特定于每个应用的实现。一般UTF-8或者ASCII编码的字符串已经够用了。

zookeeper的API暴露了以下方法：

create /path data

创建一个名为/path 的znode节点，并包含了数据data

delete /path

删除/path的znode节点

exist /path

判断是否存在未/path的节点

setData /path data、

设置/path的znode节点数据为data

getData /path

从/path节点获得数据

getChildren /path

从/path节点获得所有的子节点

重点注意：zookeeper不允许局部写入或者读取znode节点的数据，当设置一个znode节点的数据或者读取时，znode的节点的内容会被整体替换或者全部读取进来。

zookeeper客户端连接zookeeper服务器时，通过API调用来建立回话session。

 

当创建znode节点时，还需要指定节点类型，不同的类型决定了znode节点的行为方式。

持久节点：

persistent持久节点，可以通过持久类型的znode节点保存一些数据。即如果znode的节点已经不再属于应用系统了，数据也可以保存下来而不会丢失。

临时节点：

ephemeral临时节点，仅当创建者的回话有效时，这些信息必须有效保存。

可以用于选举主节点，如果一个节点创建成功了一个临时节点，那么这节点就主节点，如果该临时节点消失了，那么就可以重新选举主节点。

一个临时有两种情况会被删除：

当创建该znode的客户端回话因超时或者主动关闭而终止时；

当某个客户端（并不一定是创建者）主动删除该临时节点时；

有序节点：

一个znode节点可以设置为有序节点，每个有序节点都会被赋予一个递增的整数，有序类型的节点可以用于处理锁的处理。

通过以上三个类型的节点，可以组合为四种类型的节点：临时节点、持久节点、临时有序节点、持久有序节点。

 

zookeeper通过监视和通知方式来获得数据的变化（可以避免轮休zookeeper节点导致的性能问题）。需要注意的是，当使用通知机制时，由于通知机制时单次触发的操作，所有在客户端接受一个znode变更通知并设置新的监视点时，znode节点有可能已经发生了变化，例如：应用监视了节点A，A数据发生了变化，应用再次设置监视节点A之前，节点A的数据发生了变化，这种情况下就会遗漏节点A的数据变化。

通知机制的一个重要保障是：对同一个znode的操作，先向客户端传送的通知，然后再对该节点进行变更。如果客户端对一个znode设置了监视点，而该znode发生功能了两次连续更新，第一更新后，客户端在观察第二次变化前就接收到了通知，然后读取znode中的数据，主要特定在于通知截止组织了客户端所观察的更新顺序。

 

每个zookeeper的znode节点都有一个版本号，它随着每次数据变化而自增。两个API可以有序的执行：setData和delete。这两个操作都需要以版本号作为参数，只有当传入的版本号与服务器上的版本号一致时调用才会返回成功。

 

zookeeper服务器运行于两种模式下：独立模式和仲裁模式。

独立模式就是只有一个单独的服务器，zookeeper状态无法复制。

在仲裁模式下，具有一组zookeeper服务器，称为zookeeper集合，它们之间可以进行状态复制，并且同时为服务提供客户端的请求。

 

在仲裁模式下，zookeeper复制集群中的所有服务器的数据树。

zookeeper通过法定人数的方式来设置zookeeper集群中必须有效运行的服务器数量。这个法定人数一般为(N+1)/2 ，其中n为奇数。

如果法定人数小于集群数量的一般，可能导致脑裂问题发生。

 

在对zookeeper集合进行任务请求前，一个客户端必须先与服务建立会话。

当一个回话因为某种原因终止时，在这个会话期间创建的临时节点都将消失。

会话提供了顺序保障，这就意味着同一个会话中的请求是FIFO顺序执行，

但是一个客户端打开多个会话的话，FIFO顺序在多个会话之间未必保证顺序。

 

zookeeper会话的生命周期是指从会话创建到结束的时期，会话状态可以分为：connecting、connected、closed、not_connected。

注意：当一个客户端与服务器因超时而断开连接时，客户端仍然保持connecting状态，

创建一个回话时，需要设置回话超时时间这个重要的参数，这个参数设置了lzookeeper服务运行会话被声明为超时之前存活的时间。例如：如果经过了T时间之后服务接收不到这个会话的任何消息，服务就会声明会话过期，在客户端侧，如果经过三个之一的T时间未收到任何消息，客户端将向服务器发送心跳消息。如果经过了三分之二的T时间后，zookeeper客户端开始寻找其他服务器，而此时它还有三分之一的T时间去寻找。

 

zookeeper配置信息：

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/.data

clientPort=2181

server.1=127.0.0.1:2222:2223

server.2=127.0.0.1:2223:2224

server.3=127.0.0.1:2224:2225

 

每个server.n的编号为n的zookeeper服务器使用的地址和端口

后面的第一个端口为仲裁端口

后面的第二列端口为群首选举端口

 

客户端以随机顺序连接服务器，这样zookeeper可以实现简单的负载均衡；

例如：如果一个集群中有5台服务器，2台在一起，3台在一起，可以通过配置连接地址来使只访问离自己近的服务器。

 

一个主从模式例子的实现：

有三个角色：

主节点：用于监控新的从节点和任务，分配任务给可用的从节点

从节点：从节点会通过系统注册自己，以确保主节点可以看到自己，并执行任务，然后监控新任务

客户端：客户端创建新任务并等待系统的响应.

需要先创建/worker、/tasks、/assign三个znode，worker用于从节点连接后注册在znode下，assign用于从节点在worker下注册成功后，需要主节点把从节点在assign下进行新建一个可分配任务的地址，tasks用于记录任务的执行情况。

多个节点通过注册临时节点/master用来获得管理权，即变为主节点，只要任意一个节点注册了/master,那么该节点为主节点，从节点监视/master的变化，如果该znode节点方式变化，则重新开始新一轮的主节点选举。

主节点选举成功后，执行create -e /master "master1.example.com:2223"

从节点需要先通知主节点，告知主节点从节点可以执行任务，即在worker下执行create -e/workers/worker1.example.com “worker1.example.com：2223”

主节点需要监控/workers的子节点变化。

客户端向系统添加新任务，执行create -s /tasks/task- "cmd"，创建的字节点为顺序节点

主节点需要监控/tasks子节点的变化，如果有新节点加入，需要把该任务分配给/assign下的工作节点，即在/assign下执行create /assign/worker.example.com/task-0000000 ""

当从节点执行完task-0000000任务后，需要在/tasks下标记该任务执行完毕，执行create /tasks/task-0000000 "done"