1
ZooKeeper 不允许局部写入或者读取znode节点的数据，当设置一个znode节点的数据或者读取是，znode 节点的内容会被整个替换或者全部读取进来；
ZooKeeper 客户端连接到ZooKeeper服务，通过API调用来建立会话
2
znode 节点类型：持久节点和临时节点
持久节点：只能通过调用delete来删除。
临时节点：创建节点的客户端崩溃或者关闭了ZooKeeper的连接，节点会删除。
临时节点现在不允许拥有子节点
有序节点：一个有序znode节点被分配唯一一个单调递增的整数。
ZooKeeper 通知机制是单次触发的操作，所以在客户端接收一个znode变更通知并设置新的监控点。
通知机制的一个重要的保障是：对一个znode操作，先向客户端传送通知，然后再对该节点进行变更。如果客户端对一个znode设置了监控点，而该znode发生了两个连续变更。第一次更新后，客户端在观察第二次变化前就接受到了通知，然后读取znode中的数据。我们认为主要特征在于通知机制阻止了客户端所观察的更新顺序。虽然ZooKeeperde 状态变化传播给某些客户端是更慢，但是我们保障客户端以全局的顺序来观察ZooKeeper的状态。
监控类型：监控znode子节点的变化、znode的数据变化、znode的创建或者删除。watcher对象。
版本：每一个znode都有一个版本号，它随着每次数据变化而自增。两个API操作课可以有条件地执行：setData和delete。这两个调用以版本号作为传入入参。只有当传入参数的版本号与服务器的版本号一致时调用才会成功。
ZooKeeper架构：
standalone 模式和quorum 模式
standalone 模式：一台单独服务器，ZooKeeper状态无法复制
quorum 模式： 一组ZooKeeper服务器，它们之间可以进行状态的复制，并同时为服务于客户端的请求
会话：客户端通过TCP协议与服务器进行连接并通讯，但当会话无法与当前连接的服务器继续通讯是，会话就可能转移到另一个服务器上。ZooKeeper客户端库透明地转移一个会话到不同的服务器。
会话提供看顺序保障，这就意味着同一个会话中的请求会以FIFO顺序执行。通常，一个客户端只打开一个会话，因此客户端请求将全部以FIFO顺序执行。如果客户端拥有多个并发的会话，FIFO顺序在多个会话之间未必能够保持。
会话的状态和声明周期：
CONNECTING、CONNECTED、CLOSED、NOT_CONNECTED
一个会话从NOT_CONNECTED状态开始，当ZooKeeper 客户端初始化后转换到CONNECTING状态。正常情况下，成功与ZooKeeper 服务器建立连接后，会话转换到CONNECTED状态，当客户端与ZooKeeper 服务器断开连接或者无法接收到服务器的响应时，它就会转换回CONNECTING状态并尝试发现其他ZooKeeper服务器。如果可以发现 另一个服务器或重连到原来的服务器，当服务器确认会话有效后，状态又会转换回CONNECTED状态。否则他将会声明会话过期，然后转换到CLOSED状态。应用也可以显式地关闭会话。
