1、Zookeeper 的数据模型
Zookeeper 的数据模型类似于，数据结构中的树。
树是由节点所组成，Zookeeper 的数据存储也同样是基于节点，这种节点叫做 Znode
但是，不同于树的节点，Znode 的引用方式是路径引用，类似于文件路径：
/动物/猫
/汽车/宝马
这样的层级结构，让每一个 Znode 节点拥有唯一的路径，就像命名空间一样对不同信息作出清晰的隔离。
2、Znode 包含哪些元素？
- data：Znode 存储的数据信息。
- ACL：记录 Znode 的访问权限，即哪些人或哪些 IP 可以访问本节点。
- stat：包含 Znode 的各种元数据，比如事务 ID、版本号、时间戳、大小等等。
- child：当前节点的子节点引用
注：
Zookeeper 是为读多写少的场景所设计。
Znode 并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息**，每个节点的数据最大不能超过 1MB**。避免被当做数据库来使用，尽管Zookeeper具有一致性。
3、Zookeeper 的基本操作
创建节点
create
删除节点
delete
判断节点是否存在
exists
获得一个节点的数据
getData
设置一个节点的数据
setData
获取节点下的所有子节点
getChildren
这其中，exists，getData，getChildren 属于读操作。
但是，业务中一旦和写操作有了挂钩，就会和事务产生关系。
Zookeeper 客户端在请求读操作的时候，可以选择是否设置 Watch
4、Zookeeper 的事务通知
可以把 Watch 理解成是注册在特定 Znode 上的触发器。
当这个 Znode 发生改变，也就是调用了 create，delete，setData 方法的时候，将会触发 Znode 上注册的对应事件，请求 Watch 的客户端会接收到异步通知。
5、Zookeeper 的一致性
Zookeeper 身为分布式系统协调服务，如果自身挂了如何处理呢？
为了防止单机挂掉的情况，Zookeeper 维护了一个集群。（避免单点故障）
Zookeeper Service 集群是一主多从结构。
在更新数据时，首先更新到主Zookeeper Service，再同步到从Zookeeper Service。
在读取数据时，直接读取任意从Zookeeper Service。
为了保证主从节点的数据一致性，Zookeeper 采用了 ZAB 协议，这种协议非常类似于一致性算法 Paxos 和 Raft。
6、ZAB 协议
Zookeeper（动物园管理员） Atomic原子的） Broadcast（ 广播; 散布，传播），
有效解决了 Zookeeper 集群崩溃恢复，以及主从同步数据的问题。
ZAB 协议定义的三种节点状态
- Looking ：选举状态。
- Following ：Follower 节点（从节点）所处的状态。
- Leading ：Leader 节点（主节点）所处状态
ZAB 协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性（顺序一致性）。
它依靠事务 ID 和版本号，保证了数据的更新和读取是有序的。
7、Zookeeper 集群崩溃恢复
（类似于redis的主从复制，只是类似）
假如Zookeeper 集群的主Zookeeper server 挂了，集群会进行崩溃恢复。
1、选举阶段，就是所有的 子Zookeeper server 进行投票选举。（此时所有的子服务的状态都为 Looking ：选举状态）
2、选票大于半数的子Zookeeper server，成为Leader领导者,（Leading ：Leader 节点（主节点）所处状态），其他的子服务为Follower跟随者， （Following ：Follower 节点（从节点）所处的状态）
3、leader服务，从其他的子服务中，寻找发现，最新的 ZXID 和事务日志。并对自身进行更新。
4、把 Leader 刚才收集得到的最新历史事务日志，同步给集群中所有的 Follower。只有当半数 Follower 同步成功，这个准 Leader 才能成为正式的 Leader。
