zookeeper特性
-
全局数据一致：集群中每个服务器保存一份相同的数据副本，client无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征；
-
可靠性：如果消息被其中一台服务器接受，那么将被所有的服务器接受。
-
顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
-
数据更新原子性：一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态；
-
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。
集群角色
过半且权值大，就是leader，其他集群就是follower。observer观察状态。
Leader:
Zookeeper 集群工作的核心
事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。
对于 create，setData，delete 等有写操作的请求，则需要统一转发给
leader 处理，leader 需要决定编号、执行操作，这个过程称为一个事务。
Follower:
处理客户端非事务（读操作）请求，转发事务请求给 Leader；参与集群 Leader 选举投票。
此外，针对访问量比较大的 zookeeper 集群，还可新增观察者角色。
Observer:
观察者角色，观察 Zookeeper 集群的最新状态变化并将这些状态同步过
来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader服务器进行处理。
不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务
处理能力的前提下提升集群的非事务处理能力。
zookeeper shell
运行 /export/server/zookeeper/bin/zkCli.sh –server ip进如命令行
创建节点
create [-s] [-e] path data acl
其中，-s或-e分别指定节点特性，顺序（序列化可以创建相同文件名）或临时节点，（会话结束，会自动删除）
若不指定，则表示持久节点；acl用来进行权限控制。
读取节点
与读取相关的命令有ls 命令和get 命令，ls命令可以列出Zookeeper指定节点下的所有子节点，只能查看指定节点下的第一级的所有子节点；get命令可以获取Zookeeper指定节点的数据内容和属性信息。
ls path [watch]
get path [watch]
ls2 path [watch]
更新节点
set path data [version]
data就是要更新的新内容，version表示数据版本。
删除节点
delete path [version]
若删除节点存在子节点，那么无法删除该节点，必须先删除子节点，再删除父节点。
Rmr path
可以递归删除节点。
对节点增加限制
setquota -n|-b val path
n:表示子节点的最大个数
b:表示数据值的最大长度
val:子节点最大个数或数据值的最大长度
path:节点路径
其他命令
history : 列出命令历史
zookeeper数据模型
采用树形层次结构，树中每个节点被称为一个Znode。和文件系统的目录树一样，ZooKeeper 树中的每个节点可以拥有子节点。
但也有不同之处：
- Znode 兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子 Znode。用户对 Znode 具有增、删、改、查等操作（权限允许的情况下）。
- Znode 具有原子性操作，读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的 ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。
- Znode 存储数据大小有限制。ZooKeeper 虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以 KB 为大小单位。ZooKeeper 的服务器和客户端都被设计为严格检查并限制每个 Znode 的数据大小至多 1M，当时常规使用中应该远小于此值。
- Znode 通过路径引用，如同 Unix 中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在 ZooKeeper 中，路径由Unicode 字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。
数据结构图
图中的每个节点称为一个 Znode。 每个 Znode 由 3 部分组成:
① stat：此为状态信息, 描述该 Znode 的版本, 权限等信息
② data：与该 Znode 关联的数据
③ children：该 Znode 下的子节点
节点类型
Znode 有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。
- 临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。
- 永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
Znode 还有一个序列化的特性，如果创建的时候指定的话，该 Znode 的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10 位数字，没有数值的数位用 0 补充，例如“0000000001”)。
这样便会存在四种类型的 Znode 节点，分别对应：
- PERSISTENT：永久节点
- EPHEMERAL：临时节点
- PERSISTENT_SEQUENTIAL：永久节点、序列化
- EPHEMERAL_SEQUENTIAL：临时节点、序列化
节点属性
每个 znode 都包含了一系列的属性，通过命令 get，可以获得节点的属性。
- dataVersion：数据版本号，每次对节点进行 set 操作，dataVersion 的值都会增加 1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。
- cversion ：子节点的版本号。当 znode 的子节点有变化时，cversion 的值就会增加 1。
- cZxid ：Znode 创建的事务 id。
- mZxid ：Znode 被修改的事务 id，即每次对 znode 的修改都会更新 mZxid。对于 zk 来说，每次的变化都会产生一个唯一的事务 id，zxid（ZooKeeperTransaction Id）。通过 zxid，可以确定更新操作的先后顺序。例如，如果 zxid1小于 zxid2，说明 zxid1 操作先于 zxid2 发生，zxid 对于整个 zk 都是唯一的，即使操作的是不同的 znode。
- ctime：节点创建时的时间戳.
- mtime：节点最新一次更新发生时的时间戳.
- ephemeralOwner:如果该节点为临时节点, ephemeralOwner 值表示与该节点绑定的 session id. 如果不是, ephemeralOwner 值为 0.
- 在 client 和 server 通信之前,首先需要建立连接,该连接称为 session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接,连接便处于 CLOSED状态, 此时 session 结束。
监听机制
- ZooKeeper 中 ， 引 入 了 Watcher 机 制 来 实 现 这 种 分 布 式 的 通 知 功 能 。ZooKeeper 允许客户端向服务端注册一个 Watcher 监听，当服务端的一些事件触发了这个 Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
- 触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。总 的 来 说 可 以 概 括 Watcher 为 以 下 三 个 过 程 ： 客 户 端 向 服 务 端 注 册Watcher、服务端事件发生触发 Watcher、客户端回调 Watcher 得到触发事件情况.
Watch 机制特点
一次性触发
事件发生触发监听，一个 watcher event 就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发。
事件封装
ZooKeeper 使用 WatchedEvent 对象来封装服务端事件并传递。WatchedEvent 包含了每一个事件的三个基本属性：
通知状态（keeperState），事件类型（EventType）和节点路径（path）
event 异步发送
watcher 的通知事件从服务端发送到客户端是异步的。
先注册再触发
Zookeeper 中的 watch 机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。