Zookeeper理论知识概要
数据模型
- zookeeper是(key,value)键值对，拥有一个层次的命名空间，类似于标准文件系统的树形层次结构
- zookeeper每个节点被称为 znode，zookeeper 每个节点都 拥有子节点（注：临时节点无子节点），并且同级节点具有唯一性，每个znode包含三部分: stat：此为状态信息, 描述该znode的版本, 权限等信息; data：与该znode关联的数据; children：该znode下的子节点
- znode虽然可以关联数据(byte[]类型)，但是只是为了管理调度数据，每个节点限制最多不超过1MB。
- znode的路径使用斜线分割，例如：/a/b，zookeeper中没有相对路径的说法，也即所有节点的路径都要写为绝对路径的方式；
- zookeeper定义了org.apache.zookeeper.data.Stat数据结构来存储数据的变化、ACL(访问权限)的变化和时间戳；
- 当zookeeper中节点的数据发生变化时，版本号会递增；
- 可以对Znode中的数据进行读写操作；
Zookeeper节点
节点特性
- 同级节点的唯一性 不同级不需要保证唯一性
- 临时节点和持久化节点
- 有序节点特性
- 节点有父子关系
- 临时节点下不能存在子节点(临时节点生命周期仅限于当前会话)
节点类型
ZK中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。
临时节点 该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。
虽然每个临时的Zn ode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。
另外，ZooKeeper的临时节点不允许拥有子节点。
被删除条件：
- 当创建该znode的客户端的会话因超时或主动关闭而中止时。
- 当某个客户端（不一定是创建者）主动删除该节点时。
- 永久节点 该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
节点属性
| 属性 | 说明 |
| czxid | 节点被创建的zxid |
| mzxid | 节点被修改的zxid |
| ctime | 节点被创建的时间 |
| mtime | 节点被修改的时间 |
| version | 节点的版本号 |
| cversion | 节点所拥有的子节点被修改的版本号 |
| aversion | 节点的ACL被修改的版本号 |
| ephemeralOwner | 如果此节点为临时节点，那么他的值为这个节点拥有者的会话ID；否则，他的值为0 |
| dataLength | 节点数长度 |
| numChildren | |
| pzxid | 最新修改的zxid |
集群角色
leader
Leader服务器是整个zookeeper集群的核心，主要工作任务：
- 事务请求(增/删/改)的唯一调度和处理者，保证集群事务处理的顺序性
- 集群内部各服务器的调度者
follower
- 处理客户端非事务请求、转发事务请求给leader服务器
- 参与事务请求Proposal的投票（需要半数以上服务器通知才能通知leader commit数据，leader发起的提案，需要follower投票）
- 参与leader选举的投票
observer
observer 是 zookeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当了观察者的角色。观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。Observer 的工作原理与follower 角色基本一致，而它和 follower 角色唯一的不同在于 observer 不参与任何形式的投票，包括事务请求Proposal的投票和leader选举的投票。简单来说，observer服务器只提供非事务请求服务，通常在于不影响集群事务处理能力的前提下提升集群非事务处理的能力。
remark:
请求可能会连接到任意节点 如果是读请求，可以再任意节点处理数据(所有节点数据都是一致的) 如果是事务(增删改)请求，会转发到Leader去处理
会话状态
NOT_CONNECTED -> CONNECTING -> CONNECTED -> CLOSE
- session是客户端与zookeeper服务端之间建立的长链接；
- zookeeper在一个会话中进行心跳检测来感知客户端链接的存活；
- zookeeper客户端在一个会话中接收来自服务端的watch事件通知；
- zookeeper可以给会话设置超时时间；
ZAB协议
ZAB（Zookeeper Atomic Broadcast）协议是为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议，主要用于实现分布式数据的一致性
崩溃恢复
崩溃情景：
- leader服务挂了
- 当leader失去了过半的follower节点的联系
消息广播
消息广播过程（简化版的二阶提交）：
- leader 接收到消息请求后，将消息赋予一个全局唯一的64 位自增 id，叫：zxid，通过 zxid 的大小比较既可以实现因果有序这个特征
- leader 为每个 follower 准备了一个 FIFO 队列（通过 TCP协议来实现，以实现了全局有序这一个特点）将带有 zxid的消息作为一个提案（proposal）分发给所有的 follower
- 当 follower 接收到 proposal，先把 proposal 写到磁盘，写入成功以后再向 leader 回复一个 ack
- 当 leader 接收到合法数量（超过半数节点）的 ACK 后，leader 就会向这些 follower 发送 commit 命令，同时会在本地执行该消息
- 当 follower 收到消息的 commit 命令以后，会提交该消息
remark:leader 的投票过程，不需要 Observer 的 ack，也就是Observer 不需要参与投票过程，但是 Observer 必须要同步 Leader 的数据从而在处理请求的时候保证数据的一致性
ACL(访问控制)
类似于Linux/Unix下的权限控制，有以下几种访问控制权限：
- CREATE：创建子节点的权限；
- READ：获取节点数据和子节点列表的权限；
- WRITE：更新节点数据的权限；
- DELETE: 删除子节点的权限；
- ADMIN：设置节点ACL的权限；
remark:CREATE和DELETE是针对子节点的权限控制
