Zookeeper 分布式应用

简介

这篇文章是旨在为那些想要利用zookeeper协调服务能力进行分布式应用创建的开发者的入门指导，包括一些理论性和实践性的内容。

文章的前四部分系统的介绍了zookeeper的相关概念，对于理解zookeeper的工作机制及使用都有很大帮助。

zookeeper的数据结构

zookeeper会话

zookeeper监听

一致性保障

文章的后四部分包含一些训练性的编程内容，包括：

zookeeper操作指引

绑定关系

项目结构

常见问题及解决

zookeeper数据结构

zookeeper本身是一种层次性的命名空间结构，非常类似于分布式文件系统，不同之处在于zookeeper的每个节点都可以存储节点数据及拥有子节点，既是文件又是文件夹。每个节点的路径都是用斜线分割，唯一，绝对的。没有相对路径：

ZNode

zookeeper中的节点以ZNode的形式存在，ZNode结构存储数据及确认历史变化版本号并包含时间戳。zookeeper使用版本号及时间戳来处理缓存时效及协调更新。版本号会随着每次节点数据的改变而递增，客户端查询节点数据，同时会返回数据的版本号信息，当需要执行删除或更新操作时，客户端必须提供相应的需要删除的数据版本号，如果不一致，则操作不执行。

附注：在分布式应用机制中，一个node可以代表一个host地址，一台服务器，集合中的一员，一个客户端进程等，zookeeper中znodes代表数据节点，servers对应组成zookeeper服务的机器，client代表使用zookeeper服务的任何客户端进程，quorum peers代表组成集合的服务器。

znodes是编程主要涉及的对象，主要特性如下：

监听：客户端可以设置节点监听，当节点发生变化（数据变化或者被删除等）将会触发监听并通知监听客户端，触发后删除监听。

数据访问：节点数据访问具有原子性，读取或者更新全部输的数据信息，每个节点都有一个访问控制列表，进行权限控制。

Zookeeper设计的初衷并不是用来作为常规的数据库的，相反，他维护一致性数据，包括配置信息，状态信息，会合信息等，它们共同的特点就是数据量特别小，Kbits大小，zookeeper客户端和服务端有一套健全的机制检查节点数据的大小，确保不大于1M，通常来说会大大小于1M。大体积数据操作会耗费更多的时间在网络传输上，从而会影响其它相关操作，通常不建议。如果要存储大体积的数据，通常的做法是将数据存放在文件系统，然后将指向地址存储在zookeeper节点中。

临时节点：临时节点是一种节点，它会随着创建它的会话的生命周期而存在，会话结束，则节点删除，因为这一特性，临时节点没有子节点。

顺序节点（唯一命名）：创建节点的时候，可以设置zookeeper单纯的增加路径末端的节点序号。节点序号相对于父节点是唯一的，按照10位前端补零的格式来格式化并排序，4bytes无符号整数，当节点超过2147483647是会发生溢出异常。

容器节点：3.6.0之后增加

容器节点是专门为了应用于leader选举，分布式锁等而添加的特殊节点形式。当容器节点的最后一个子节点被删除，容器节点就会被列入zookeeper服务将要删除的节点行列。

当在容器节点下创建子节点时，需要捕获NoNodeException异常，当容器节点不存在是先执行容器节点的创建。

zookeeper中的时间：

Zxid：zookeeeper的状态变化会以唯一zxid的形式印记，用以标识zookeeper的状态变化顺序，小序号先于大序号发生。

版本号：节点的变化会以几点的一种版本号变化来标记，节点包含三种版本号：version指代节点数据的变化；cversion指代节点子节点的变化；aversion指代节点的确认acl。

Ticks：当使用多服务zookeeper时，服务之间使用ticks来同步协调，例如状态上载，会话过期，终端连接的过期。

zookeeper状态结果：

czxid：节点创建

mzxid: 节点更新

pzxid：子节点更新

ctime：节点创建过去的毫秒数

mtime：节点更新过去的毫秒数

ephemeralowner：临时节点拥有者的会话id

numchildren：节点的子节点数。

zookeeper监控

节点操作包括getDate()，getChildren()，exists()都可以设置节点监听，监听有以下特点：

一次性触发：当节点数据发生变化时，服务器会向客户端发送监听事件。

接受监听事件：监听事件发送具有异步性。

节点监听的数据变化。

附注：zookeeper不保证同一时间不同客户端获取数据的一致性。因为网路延迟，可能一个客户端执行的更新操作导致的节点数据变化时间可能还没有传递到另外一个客户端。