Zookeeper--起步

前言

        在平常工做中，zk的应用场景是很是多，好比rpc中挂载服务，分布式锁、配置维护、组服务、分布式消息队列、分布式通知/协调等等，zk设计之初是模仿google的chubby，提供分布式协调服务（实分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制），因此分布式锁功能是zk的基本功能。

ZK介绍

    zk性能上的特色决定了它可以用在大型的、分布式的系统当中。从可靠性方面来讲，它并不会由于一个节点的错误而崩溃。除此以外，它严格的序列访问控制意味着复杂的控制原语能够应用在客户端上。zk在一致性、可用性、容错性的保证，也是zk的成功之处，它得到的一切成功都与它采用的协议——Zab协议是密不可分的。

    zk采用了一套叫作Znode的数据结构，而后在该数据结构的基础上定义了一些原语，也就是一些关于该数据结构的一些操做。有了这些数据结构和原语还不够，由于咱们的ZooKeeper是工做在一个分布式的环境下，咱们的服务是经过消息以网络的形式发送给咱们的分布式应用程序，因此还须要一个通知机制——Watcher机制。那么总结一下，ZooKeeper所提供的服务主要是经过：数据结构+原语+watcher机制，三个部分来实现的。

    znode的结构和unix系统的目录结构很是类似，但有不彻底相同，znode结构主要有一下特色：

 引用方式

    Zonde经过路径引用，如同Unix中的文件路径。路径必须是绝对的，所以他们必须由斜杠字符来开头。除此之外，他们必须是惟一的，也就是说每个路径只有一个表示，所以这些路径不能改变。在zk中，路径由Unicode字符串组成，而且有一些限制。字符串"/zookeeper"用以保存管理信息，好比关键配额信息。

Znode结构

    zk命名空间中的Znode，兼具文件和目录两种特色。既像文件同样维护着数据、元信息、ACL、时间戳等数据结构，又像目录同样能够做为路径标识的一部分。图中的每一个节点称为一个Znode。 每一个Znode由3部分组成:

① stat：此为状态信息, 描述该Znode的版本, 权限等信息

② data：与该Znode关联的数据

③ children：该Znode下的子节点

    zk虽然能够关联一些数据，但并无被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，好比分布式应用中的配置文件信息、状态信息、聚集位置等等。这些数据的共同特性就是它们都是很小的数据，一般以KB为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并限制每一个Znode的数据大小至多1M，但常规使用中应该远小于此值。

数据访问

    zk中的每一个节点存储的数据要被原子性的操做。也就是说读操做将获取与节点相关的全部数据，写操做也将替换掉节点的全部数据。另外，每个节点都拥有本身的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点能够执行的操做。

节点类型

    zk中的节点有两种，分别为临时节点和永久节点。节点的类型在建立时即被肯定，而且不能改变。

     临时节点：该节点的生命周期依赖于建立它们的会话。一旦会话(Session)结束，临时节点将被自动删除，固然能够也能够手动删除。虽然每一个临时的Znode都会绑定到一个客户端会话，但他们对全部的客户端仍是可见的。另外，zk的临时节点不容许拥有子节点。

    永久节点：该节点的生命周期不依赖于会话，而且只有在客户端显示执行删除操做的时候，他们才能被删除。

顺序节点

    当建立Znode的时候，用户能够请求在zk的路径结尾添加一个递增的计数。这个计数对于此节点的父节点来讲是惟一的，它的格式为"%10d"(10位数字，没有数值的数位用0补充，例如"0000000001")。当计数值大于232-1时，计数器将溢出。

 观察

    客户端能够在节点上设置watch，咱们称之为监视器。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操做。当watch被触发时，zk将会向客户端发送且仅发送一条通知，由于watch只能被触发一次，这样能够减小网络流量。

 

zk节点相关

zk有多种记录时间的形式，其中包含如下几个主要属性：

(1) Zxid

导致ZooKeeper节点状态改变的每个操做都将使节点接收到一个Zxid格式的时间戳，而且这个时间戳全局有序。也就是说，也就是说，每一个对节点的改变都将产生一个惟一的Zxid。若是Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件以前。实际上，ZooKeeper的每一个节点维护者三个Zxid值，为别为：cZxid、mZxid、pZxid。

① cZxid： 是节点的建立时间所对应的Zxid格式时间戳。
② mZxid：是节点的修改时间所对应的Zxid格式时间戳。

实现中Zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个 新的epoch。低32位是个递增计数。 (2) 版本号

对节点的每个操做都将导致这个节点的版本号增长。每一个节点维护着三个版本号，他们分别为：

① version：节点数据版本号
② cversion：子节点版本号
③ aversion：节点所拥有的ACL版本号

对节点的操做包括如下：

    更新ZooKeeper操做是有限制的。delete或setData必须明确要更新的Znode的版本号，咱们能够调用exists找到。若是版本号不匹配，更新将会失败。

    更新ZooKeeper操做是非阻塞式的。所以客户端若是失去了一个更新(因为另外一个进程在同时更新这个Znode)，他能够在不阻塞其余进程执行的状况下，选择从新尝试或进行其余操做。

    尽管ZooKeeper能够被看作是一个文件系统，可是处于便利，摒弃了一些文件系统地操做原语。由于文件很是的小而且使总体读写的，因此不须要打开、关闭或是寻地的操做。

1) watch概述

ZooKeeper能够为全部的读操做设置watch，这些读操做包括：exists()、getChildren()及getData()。watch事件是一次性的触发器，当watch的对象状态发生改变时，将会触发此对象上watch所对应的事件。watch事件将被异步地发送给客户端，而且ZooKeeper为watch机制提供了有序的一致性保证。理论上，客户端接收watch事件的时间要快于其看到watch对象状态变化的时间。

(2) watch类型

ZooKeeper所管理的watch能够分为两类：

① 数据watch(data  watches)：getData和exists负责设置数据watch
② 孩子watch(child watches)：getChildren负责设置孩子watch

咱们能够经过操做返回的数据来设置不一样的watch：

① getData和exists：返回关于节点的数据信息
② getChildren：返回孩子列表

所以

① 一个成功的setData操做将触发Znode的数据watch

② 一个成功的create操做将触发Znode的数据watch以及孩子watch

③ 一个成功的delete操做将触发Znode的数据watch以及孩子watch

(3) watch注册与处触发

图 6.1 watch设置操做及相应的触发器如图下图所示：

① exists操做上的watch，在被监视的Znode建立、删除或数据更新时被触发。
② getData操做上的watch，在被监视的Znode删除或数据更新时被触发。在被建立时不能被触发，由于只有Znode必定存在，getData操做才会成功。
③ getChildren操做上的watch，在被监视的Znode的子节点建立或删除，或是这个Znode自身被删除时被触发。能够经过查看watch事件类型来区分是Znode，仍是他的子节点被删除：NodeDelete表示Znode被删除，NodeDeletedChanged表示子节点被删除。

　　Watch由客户端所链接的ZooKeeper服务器在本地维护，所以watch能够很是容易地设置、管理和分派。当客户端链接到一个新的服务器时，任何的会话事件都将可能触发watch。另外，当从服务器断开链接的时候，watch将不会被接收。可是，当一个客户端从新创建链接的时候，任何先前注册过的watch都会被从新注册。

 

(4) 须要注意的几点

Zookeeper的watch实际上要处理两类事件：

① 链接状态事件(type=None, path=null)

这类事件不须要注册，也不须要咱们连续触发，咱们只要处理就好了。

② 节点事件

节点的创建，删除，数据的修改。它是one time trigger，咱们须要不停的注册触发，还可能发生事件丢失的状况。

上面2类事件都在Watch中处理，也就是重载的process(Event event)

节点事件的触发，经过函数exists，getData或getChildren来处理这类函数，有双重做用：

① 注册触发事件

② 函数自己的功能

函数的自己的功能又能够用异步的回调函数来实现,重载processResult()过程当中处理函数自己的的功能。

总结

    zk的设计巧妙之处在于对zab和znode的结构设计上，本篇博文经过前人概括总结的zk在znode设计上的巧思，让咱们后来人对zk一开始就有比较高的高度去起步学习，对zk的api使用上能很是轻易的上手。