分布式协调

hierarchal（层次）树形 数据结构 类似标准文件系统

high performance（高性能）, highly available（高可用性）, strictly ordered access（严格有序访问）

用于大型分布式系统 高可用避免出现单点故障  严格有序访问可以让Client实现复杂的同步原语

使用场景
数据发布与订阅  配置管理 命名空间服务 分布式通知/协调 分布式锁 集群管理 选主 群组成员管理


Znode 
四种节点类型 PERSISTEN PERSISTENT_SEQUENTAIL EPHEMERAL EPHEMERAL_SEQUENTAIL

持久节点(persistent)  只能通过调用delete删除
临时节点(ephemeral)   临时节点不允许有子节点  
                     删除时机 
                     创建该节点的客户端崩溃或断开连接
                     主动调用delete删除
   
有序节点(sequential)  创建时,一个序号会被追加到路径后,例如创建路径为task/task-,则最终路径为task/task-1


Session 
Client与ZooKeeper之间的通信，需要创建一个Session
当会话无法与当前连接的服务器继续通信时，客户端可能透明地将会话转移到另一个服务器上
同一个会话提供了顺序保障，即请求先进先出

会话超时设置为时间t

服务端	t	    经过时间t后，服务端接收不到这个会话的任何消息，服务端会声明会话过期
客户端	t/3	    经过t/3时间未收到服务端消息，则主动向服务器发送心跳消息
客户端	2t/3	仍未收到服务端消息，则开始寻找其它的服务器,此时它还有t/3的时间去寻找



Watcher 
Client可以在某个znode上设置一个Watcher，来Watch该znode上的变化
一次性，触发一次就会被取消，如果想继续监听，需要客户端重新设置Watcher。

事务日志和快照
dataDir 数据目录，用于存储快照文件（snapshot）
dataLogDir 事务日志目录，存放事务日志

Zookeeper角色

Leader 负责投票的发起和决议，更新系统状态
Follower
  负责接收处理请求
  选Leader的过程中参与投票

Observer 
  接收客户端的连接，将写请求转发到Leader节点，但不参与投票和选举，仅仅接收投票和选举的结果。
  主要用来扩展系统，提高读取速度。
Client 请求发起方

Server的四种状态
leading  
following 
observing 
looking 当前Server不知道leader是谁，正在搜寻。

API

create /path data
create -e /master "xxx"(-e表示临时节点)
create -s /tasks/task- "xxx"(-s创建有序节点)
delete /path	
exists /path
set /path data
get /path
getChildren /path   返回/path节点的所有子节点列表
ls /path

sync
set acl
get acl



两种运行模式

独立模式(standalone)	即单机模式
仲裁模式(quorum)	即一组集群


特性

顺序一致性：按照客户端发送请求的顺序更新数据。FIFO
原子性：更新要么成功，要么失败，不会出现部分更新。
单一系统映像 ：无论客户端连接哪个server，都会看到同一个视图。
可靠性：简单、健壮、高性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。
时效性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新数据，或者服务器失效的信息。
      但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，
      如果需要最新数据，在读数据之前调用sync()
      
   
原理

原子广播 通过Zab协议保证各个Server之间数据的同步
Zab协议有两种模式，分别是恢复模式（选举Leader）和广播模式（同步）
保证事务的顺序一致性 使用递增的事务id号（zxid）来标识事务
所有的提议（proposal）都在被提出的时候加上了zxid
zxid 64位数字，高32位是epoch ，用来标识leader关系是否改变，
每次一个leader被选出来，都会有一个新的epoch，标识当前属于那个leader的统治时期。
低32位用于递增计数。


客户端可以从任意一个ZooKeeper服务器读取数据 保证读性能
写请求Forwarder到Leader ，Leader通过原子广播协议，将请求广播给所有的Follower
Leader收到一半以上的写成功的Ack后，认为写成功，将该写持久化，并告诉客户端写成功了。

WAL(Write-Ahead-Log)
预写日志 更新内存数据 
Snapshot
定期将内存中的目录树 Snapshot，
持久化，加快重启之后的恢复速度 ，如果全部依赖WAL replay 恢复，比较慢

对于同一客户端 所有操作 按顺序执行 FIFO 
全局有序和偏序

全局有序针对服务器端  
偏序针对客户端

更新操作串行执行