Zookeeper 分布式应用
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 Transaction Id)的形式印记，用以标识zookeeper的状态变化顺序，小序号先于大序号发生。
-
版本号：节点的变化会以节点的一种版本号变化来标记，节点包含三种版本号：version指代节点数据的变化；cversion指代节点子节点的变化；aversion指代节点的acl变化。
-
Ticks：当使用多服务zookeeper时，服务之间使用ticks来作为基本的时间单位来同步协调，例如状态上载，会话过期，终端连接的过期。
-
Real time：zookeeper内部不适用时钟时间，唯一的用处是作为节点的时间戳数据插入和修改。
-
- zookeeper状态数据结构：
-
czxid：节点创建唯一标识
-
mzxid: 节点更新唯一标识
-
pzxid：子节点更新
-
ctime：节点创建过去的毫秒数
-
mtime：节点更新过去的毫秒数
-
version：节点数据变更的版本号
-
cversion：子节点数据变更的版本号
-
aversion：节点ACL变更的版本号
-
ephemeralowner：临时节点拥有者的会话id
-
dataLength：节点数据长度
-
numChildren：节点的子节点数。
-
