ZooKeeper保证只要大多数服务器可用((N+1)/(2N+1))，整个服务就是可用的
guarantees
- 顺序一致性(Sequential Consistency): 客户端的更新会按照发送顺序进行操作。
- 原子性(Atomicity): 更新操作只会是成功或失败，不存在其他异常结果。
- 单一视图(Single System Image): 客户端无论连接到哪个server，看到的都是相同的视图。
- 可靠性(Reliability): 当更新操作被执行后，它将一直有效，直到下一次更新操作的执行。
- 及时性(Timeliness): client的视图保证在一定时间内能得到更新。
znode
ZNode由两部分组成：协调数据和状态数据
- 协调数据: 业务相关的数据
- 状态结构数据包含: 数据变更的版本号， ACL(Access Control List)变更，时间戳，以用来缓存验证和协调更新。每次Znode数据发生变化，版本号就会自增。
znode type
zookeeper 类似于一个文件系统, 数据以文件路径节点的方式存储, 但是节点有4种类型, 由 1,2,1+3,2+3组合而成
- Ephemeral, ephemeral节点是临时性的, 如果创建该节点的session结束了, 该节点就会被自动删除. ephemeral节点不能拥有子节点
- Persistent, persistent节点不和特定的session绑定, 不会随着创建该节点的session的结束而消失, 而是一直存在, 除非该节点被显式删除.
-
Sequence, sequence并非节点类型中的一种. sequence节点既可以是ephemeral的, 也可以是persistent的. 创建sequence节点时, ZooKeeper server会在指定的节点名称后加上一个数字序列, 该数字序列是递增的. 因此可以多次创建相同的sequence节点, 而得到不同的节点
- 该计数器是由父节点控制, 直接对下级节点生效
- 每个父节点都会负责维护其子节点创建的先后顺序，并且如果创建的是顺序节点（SEQUENTIAL）的话，父节点会自动为这个节点分配一个整形数值，以后缀的形式自动追加到节点名中，作为这个节点最终的节点名。
sessions
client通过TCP连接到单个server，通过该连接发送请求，获取响应，获取监视事件以及发送心跳，当该TCP连接断开后，client会自动连接到其他server
ZK Client通过ZooKeeper提供的client binding 代码（官方提供：C/Java两种Client API）创建一个handle来和ZooKeeper服务建立Session连接。创建一个handle进行连接后，client会处于CONNECTING状态，然后client library会进行尝试对ZK服务集群中的server发起连接，成功后client会置为CONNECTED状态。当发生不可恢复的错误，例如会话过期，鉴权失败，或者client主动进行关闭，handle会切换为CLOSED状态
当client session state从CONNECTED由于disconnected事件变成CONNECTING后，不建议创建新的session对象进行连接，因为ZK client library会自动进行重连，特别ZK client lib中内置了一些启发式方法来处理“羊群效应”之类的事情。在使用过程中，仅需要在收到会话到期通知时进行新会话的创建？？？(这里要看client的实现)
- 会话的超时管理是由ZK server负责的，不是由client负责。当ZK client 创建一个session时传入了一个合法的timeout，ZK集群就会根据该值对client的session进行过期管理。当集群在设定的timeout时间段内没有收到client的请求(心跳)，集群就会认定该session过期了，集群就会将session拥有的ephemeral nodes全部删除，并通知到所有监听被删除nodes的clients(CONNECTED)，如果此时该过期session的client仍然是未连接状态，将不会通知到该client，且该client将一直处于disconnected状态直到该TCP连接重连成功，重连成功后其将会收到SESSION_EXPIRED的通
- session的保活是通过client来发送请求来实现，当在一段时间内session处于空闲状态，client会发送PING请求来使session保活，PING请求不仅可以让ZK集群直到client是活的，也能让client知道到ZK集群的连接是否是活的
- 总结就是, keepalive是由client发送的, 至于是否timeout则由服务端来判断
watch
客户端可以在znodes上设置监听，ZooKeeper中所有的read操作：getData()，getChildren()和exists()，都提供了参数来设置watch。关于watch的定义：watch事件是一个一次性的触发器，当watch的Znode发生变更的时候，ZooKeeper会向客户端发送通知
watch三个特性:
一次性触发, 当监听的Znode发生变化时，会向client发生一个watch event, 但是客户端注册的watch就失效了, 如果需要继续监听, 需要主动注册监听。例如：client调用getData(“/znode1”, true)，之后/znode1发生了变化或者删除，client会收到一个watch event，但当/znode1再次发生变化时，client不会在收到watch event，除非client再次调用read操作来设置监听。
watch event发送的顺序性, 发送给client的watch event，在更改操作成功的返回代码到达发起更改的客户端之前，可能无法到达client。监听事件是异步发送给watcher。但ZK提供了顺序性保证：client不会发现其监听的znode发生变化直到它收到watch event。即client会先收到watch event，然后才会看到Znode的数据。Watch events的顺序和ZK集群中的对于更新的顺序是严格一致的。
监听的分类, ZooKeeper中存在两种watches：data watches和child watches。getData() and exists() 接口会设置data watches。getChildren() 接口会设置child watches。之所以这么设计是因为，getData() and exists() 接口是用来返回Znode的data，而getChildren() 是返回Znode所有的children列表。setData() 会触发data watch，create() 会触发data watch和父节点的child watch，delete()也同样会触发data watch和父节点的child watch
Created event：
existsDeleted event：
exists, getData, and getChildrenChanged event：
exists, getDataChild event：
getChildren
warning. 由于watch的一次性触发特性，在获取watch event和发送新的请求来再次进行znode的监听之间是有延迟的，所以这中间ZNode可能发生了多次变化，但client不会有watch event的通知.
羊群效应
注册监听, 来做分布式锁. 普通的方法是在 parent znode上注册监听, 当parent znode下的字节点发生变更, 就判断watcher者是否是最小的节点, 以此来做抢锁. 这个方法的问题在, 绝大多数情况下, watch到的事件都是无效的(自己并不是最小的). 这个在集群规模大的时候, 引发羊群效应（Herd Effect）. 解决方案是使用exist, 只注册在比自己小一位的那个节点上, 只有这个节点发生变更才会有watch.
