介绍
ZooKeeper 是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper 通过其简单的架构和 API 解决了这个问题。ZooKeeper 允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。
ZK数据模型
Zookeeper的数据模型就是一棵二叉树，和linux的目录结构一样
Zookeeper 的数据存储也同样是基于节点，这种节点叫做 Znode, Zookeeper 是为读多写少的场景所设计,Znode 并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过 1MB。
data：Znode 存储的数据信息。
ACL：记录 Znode 的访问权限，即哪些人或哪些 IP 可以访问本节点。
stat：包含 Znode 的各种元数据，比如事务 ID、版本号、时间戳、大小等等。
child：当前节点的子节点引用
基本操作
创建节点
create
删除节点
delete
判断节点是否存在
exists
获取节点数据
getData
设置节点数据
setData
获取节点下所有子节点
getChildren
exists，getData，getChildren 属于读操作。Zookeeper 客户端在请求读操作的时候，可以选择设置 Watch
ZK事件通知
可以把 Watch 理解成是注册在特定 Znode 上的触发器。当这个 Znode 发生改变，也就是调用了 create，delete，setData 方法的时候，将会触发 Znode 上注册的对应事件，请求 Watch 的客户端会接收到异步通知。
客户端调用 getData 方法，watch 参数是 true。服务端接到请求，返回节点数据，并且在对应的哈希表里插入被 Watch 的 Znode 路径，以及 Watcher 列表
当被 Watch 的 Znode 已删除，服务端会查找哈希表，找到该 Znode 对应的所有 Watcher，异步通知客户端，并且删除哈希表中对应的 Key-Value
ZK一致性
Zookeeper 身为分布式系统协调服务， 维护了一个集群。
1.Zookeeper Service 集群是一主多从结构。
2.在更新数据时，首先更新到主节点（这里的节点是指服务器，不是 Znode），再同步到从节点。
3.在读取数据时，直接读取任意从节点。
4.为了保证主从节点的数据一致性，Zookeeper 采用了 ZAB 协议，这种协议非常类似于一致性算法 Paxos 和 Raft。
ZAB
Zookeeper Atomic Broadcast，有效解决了 Zookeeper 集群崩溃恢复，以及主从同步数据的问题。
最大 ZXID 也就是节点本地的最新事务编号，包含 epoch 和计数两部分。epoch 是纪元的意思，相当于 Raft 算法选主时候的 term。
假如 Zookeeper 当前的主节点挂掉了，集群会进行崩溃恢复。ZAB 的崩溃恢复分成三个阶段：
Leader election
选举阶段，此时集群中的节点处于 Looking 状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器 ID 和最新事务 ID（ZXID）。
委婉代序。。。。。。
原文：https://www.cnblogs.com/steakliu/p/11832297.html