分布式协调系统
配置维护、名字服务、分布式同步、组服务

最终一致性：为客户端展示一致的视图
可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。
实时性：不保证两个客户端能时得到刚更新的数据，如果需要最新数据，在读数据之前调用sync()接口。
wait-free：慢的或者失效的client不干预快速的client的请求。
原子性：更新只能成功或者失败，没有中间状态。
顺序性：所有Server，同一消息发布顺序一致。


每个Server在内存中存储一份数据；
集群启动时，从实例中选举一个leader（Paxos协议）
Leader负责处理数据更新等操作（Zab协议）
一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。

leader    发起投票和决议 ，更新系统状态
follower   接收客户端请求并返回结果，选主时参与投票
observer  不参加投票，只同步leader 状态 ， 扩展系统 ，提升读取速度
client  

实例数目一般为奇数
Leader选举算法采用Paxos协议

Paxos核心思想
当多数Server写成功，则任务数据写成功
如果有3个Server，则两个写成功即可；
如果有4或5个Server，则三个写成功即可。

3个Server，则最多允许1个Server挂掉；


层次目录结构，命名符合常规文件系统规范；
节点 znode,唯一的路径标识；
节点Znode可以包含数据和子节点（EPHEMERAL类型的节点不能有子节点）
Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据需带上版本；
客户端可以在节点上设置监视器（Watcher）；
节点不支持部分读写，而是一次性完整读写。
Znode有两种类型，短暂的（ephemeral）和持久的（persistent）；
Znode的类型在创建时确定并且之后不能再修改；
短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点；
持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除；

Znode有四种形式的目录节点，
PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL。


应用场景

统一命名服务
分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务；
类似于域名与ip之间对应关系，域名容易记住；
通过名称来获取资源或服务的地址，提供者等信息

按照层次结构组织服务/应用名称
可将服务名称以及地址信息写到Zookeeper上，客户端通过Zookeeper获取可用服务列表类

配置管理
配置文件管理和同步 
                        
集群中，所有节点的配置信息是一致的，比如Hadoop；
修改配置文件后，快速同步到各个节点上
可将配置信息写入一个znode上；
各个节点监听这个znode
znode数据修改后，通知各个节点

集群管理
实时掌握每个节点的状态 ，根据节点实时状态作出调整；
可将节点信息写入znode上，监听这个znode 获取实时状态变化
Hbase中Master状态监控与选举


分布式通知/协调
NameNode 监控 DataNode 状态
JobTracker获取各TaskTracker 状态
心跳检测 
信息推送（发布/订阅模式）。

分布式锁
                
Zookeeper 强一致
多个客户端同时在Zookeeper上创建相同znode，只有一个创建成功。
锁的独占性
控制锁的时序
创建临时znode  CreateMode.EPHEMERAL_SEQUENTIAL 掌握全局访问时序。

分布式队列

两种队列
同步队列
生产者和消费者队列
当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。

一个job由多个task组成，只有所有任务完成后，job才运行完成。
job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成。



Zookeeper部署
单机模式
伪分布式模式（在单机上启动多个zookeeper实例，模拟分布式）
分布式模式

Watcher
监控目录节点的数据变化以及子目录的变化

一次设置对应一次触发 异步触发 顺序触发

可以设置观察的操作：exists getChildren getData
可以触发观察的操作：create delete setData