ZK是什么
分布式协调服务框架：统一配置管理、统一命名服务、分布式锁、集群管理
统一配置管理
(思路)抽取公共配置-维护公共配置-修改公共配置之后不需要重新部署系统
(方案)公共配置抽取之后存于ZK中并落地数据库-修改配置后发布到ZK并落地数据库-对应用开启配置事实监听，ZK配置文件一旦被修改，应用可实时监听并获取
分布式锁
当多个系统访问同一个ZK节点的时候，会创建临时自动编号的节点(EPHEMERAL_SEQUENTIAL)，然后每个系统拿到所访问节点下的所有子节点，判断自己创建的是不是最小的子节点，如果是，拿到锁(当操作完成后，释放锁的时候，会删除创建的节点)；如果不是，就要监听比自己小1的节点的状态变化。
集群管理
一主多从结构。
在更新数据时，先更新到主节点，再同步到从节点；
在读数据时，可读取任意从节点。
C/S
CAP：Consistency(一致性)+Availability(可用性)+Partition tolerance(分区容错性)
大部分分布式系统都会在保证分区容错性的前提下，在一致性和可用性之间做取舍。
ZK：CP
任何时刻对ZK的访问都能得到一致的数据结果，同时具备对网络分割的容错性，但不保障每次服务请求的可用性。
保证数据同步/一致
用来维护和监控存储数据的状态变化
树形结构存储，ZK的数据节点成为Znode，是ZK中数据的最小单元
数据模型：树/文件系统目录，基于Znode节点进行存储，其引用方式是路径引用(类似文件路径：/clj/project)
Znode包含了数据(data，即数据信息)+子节点引用(child，即当前节点的子节点引用)+访问权限(ACL，即谁可以访问)+stat(Znode的各种元数据，包括事务ID,版本号,时间戳,大小等)
ZK应用于读多写少的场景，不会存储大规模业务数据，只会存储少量的状态和配置信息，大小一般不超过1MB
PERSISTENT：持久化Znode节点
EPHEMERAL：临时Znode节点，会随当前会话连接断开而消失
PERSISTENT_SEQUENTIAL：顺序自动编号的Znode节点
EPHEMERAL_SEQUENTIAL：临时自动编号的Znode节点
基本操作
create/delete/exists/getData/setData/getChild，其中exists/getData/getChild属于读操作。(ZK客户端在访问读操作时，可以选择配置Watch)
监听器
监听Znode节点的数据变化
监听子节点的增减变化
Zookeeper使用Watcher机制实现分布式数据的发布/订阅功能
客户端线程、客户端WatcherManager、Zookeeper服务器
客户端在向ZK服务器注册的同时，会把Watcher对象存储在客户端WatcherManager中；
当ZK服务器触发Watcher事件时，会通知客户端，客户端在得到通知后，会从客户端WatcherManager中取出对应的Watcher对象进行回调。
Zookeeper提供了一套完善的ACL权限控制机制来保障数据的安全
ACL机制：权限模式Scheme+授权对象ID+权限Permission
scheme:id:permission
Zab协议 Zookeeper Atomic BroadCast（保证主从节点数据一致性）
其他解决数据一致性算法Paxos/Raft(可以解决拜占庭将军问题)/拜占庭将军问题(有关网络通信中一致性问题)
ZK的核心是广播，保证了各个Server之间的同步
数据一致性的核心算法，为Zookeeper设计的支持崩溃恢复(状态同步，即数据同步)原子消息广播算法(有效解决ZK集群崩溃恢复(主节点挂掉时，会进行崩溃恢复)，以及主从数据同步问题)
Zab协议规定的节点状态：Looking(选举状态)/Following(Follower节点所处的状态)/Leading(Leader节点所处的状态)
