ZooKeeper 10分钟概述
历史
ZooKeeper原本是Apache Hadoop的一个组件(Hadoop 的分布式协调服务)，是Google的Chubby一个开源的实现，现在被拆分为一个Hadoop的独立子项目
设计初衷
ZooKeeper的设计目的，是为了减轻分布式应用程序所承担的协调任务，用来建立安全处理局部故障的分布式应用，它本身并不能阻止局部故障的发生
数据模型和实现
ZooKeeper本质上是通过一个类似标准文件系统的共享层次命名空间来实现分布式进程间的协调，由于是类文件系统，所以即使所有的ZooKeeper节点全部挂掉，数据也不会丢失，重启服务器之后，数据即可恢复。其中命名空间节点被称作znode，znode节点可以包含数据和孩子节点，和标准文件系统不一样的是ZooKeeper把数据保存在内存当中，因为在内存中读写数据，所以ZooKeeper可以保证高吞吐和低延时性。节点更新是原子的，也就是说更新不是成功就是失败
两种特殊的ZNode
1: Ephemeral Nodes：Ephemeral节点在创建它的会话活动期间存在。会话终止的时候，临时节点被删除，所以临时节点不能有子节点。(应用：集群管理)
2: Sequence Nodes：创建znode时，可以要求ZooKeeper在路径名后增加一个单调增加的计数器部分。这个计数器相对于znode的父节点是唯一的。计数器的格式是%010d，例如：0000000001。(应用：分布式锁，选举)
一致性
ZooKeeper采用的是ZAB (ZooKeeper Atomic Broadcast) 一致性算法
一般来说，我们说的一致性分为如下多种
1: 强一致性（strong consistency）: 任何时刻，任何用户都能读取到最近一次成功更新的数据。
2: 单调一致性（monotonic consistency）: 任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。
3: 会话一致性（session consistency）: 任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值。会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。
4: 最终一致性（eventual consistency）: 用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。
5: 弱一致性（weak consistency）: 用户无法在确定时间内读到最新更新的值。
ZooKeeper的读写数据流(多节点读，一个master节点负责写，写完之后各个节点自己同步)
1: 写: Client => Follower => Leader => Follower => Client
2: 读: Client => Follower => Client
可以很清楚的看到，在集群中写数据的时候，存在数据并没有在集群中完成写入，集群数据还未同步，就已经更新了命名空间。这个时候使用最新的名称去读取数据会读到错误的数据，解决数据不同步问题，只能通过同步机制（定时执行sync()方法）解决
ZooKeeper的一致性
1: 同一session：顺序一致性，保证版本不会退；
2: 跨session：最终一致性，你最终会读到新数据的；
提供的服务
1: 统一命名服务
2: 配置管理
3: 集群管理
4: 共享锁和队列管理
统一命名服务:通过指定的名字获取资源或者服务提供者的信息
Zookeeper提供统一的命名服务，他不对外提供数据也不存储数据，他只提供一套统一的命名规则，运行在Zookeeper之上的服务需要遵循这一套命名规则
配置管理：配置的管理包含发布和订阅两个过程，将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中管理和动态更新
集群管理：集群监控和Leader选举
传统的集群监控是通过某种手段（比如 ping）定是检测，或者机器定时向监控系统汇报
ZooKeeper的做法是
1: 客户端在示例节点A上注册一个监控者（Watcher），那么如果A的子节点变化了，会通知该客户端。
2: 创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过期，那么该节点就会消失。
共享锁和队列管理: 利用zookeeper对znode节点操作的原子性
总结
ZooKeeper可以
1: 顺序一致性：来自于客户端的更新，根据发送的先后被顺序实施。
2: 唯一的系统映像：尽管客户端连接到不同的服务器，但它们看到的一个唯一（一致性）的系统服务，client无论连接到哪个server，数据视图都是一致的。
3: 可靠性：一旦实施了一个更新，就会一直保持那种状态，直到客户端再次更新它，同时数据更新原子性，一次数据更新要么成功，要么失败。
4: 及时性：在一个确定的时间内，客户端看到的系统状态是最新的。
ZooKeeper不可以
1: 实时性：如果需要最新数据，应该在读数据之前调用sync()接口
2: 所有数据，都存储在内存中，导致不能存储太多的数据
3: 慢
