Watcher 通知次数
Watcher 只会通知一次，并且没有重试机制以及事务回滚。
意味着Watcher 只关心“通知"这个动作，而不关心客户端是否处理成功。
如果想继续获取事件通知，例如节点变更通知
那么在getData 时需要将watch 参数设置为true
Zookeeper 中心化架构
同一时刻只有一个节点可以处理写操作，就是Leader。
所以在ZooKeeper集群里，总有一个Leader被选举。
ZooKeeper 节点类型
Leader - 被选举出来的节点，主要处理写操作，及同步数据到各个子Follower节点
Follower - 子节点，主要提供读操作,并在Leader挂掉时参与选举(Election)
Observer - 观察者节点， 除了不能参与选举以外，跟Follower功能一样，
??主要用于扩展节点时(新增节点时会重新选举，需要使用一段时间)，提供不间断的读操作??。
ZooKeeper 数据节点类型
分 持久化ZNode 和 临时ZNode 两大类
每个类型的ZNode 又分顺序ZNode 和 非顺序ZNode
即系以下四种:
a. 持久化ZNode
b. 持久化顺序ZNode
c. 临时ZNode
d. 临时顺序ZNode
临时节点会在session会话断开时销毁
zoo.cfg配置
tickTime (默认:2000毫秒)
表示 一个时间单位，即系后续其他配置项所配置的时间的基数。initLimit(默认:10)
表示一个节点重新加入到群集后，同步数据所花的时间，
该时间的值的计算为initLimit * tickTime, 例如 10*2000 = 20000;syncLimit(默认:5)
表示节点之间的心跳时间,
该时间的值的计算为 syncLimit * tickTime,例如 5 * 2000=10000;
新增ZooKeeper节点(不是数据ZNode)后的操作
同步数据
如果数据同步失败，则该节点加入群集失败，不会标记成正常节点。
同步数据所需要的时间为zoo.cfg配置里的 initLimit * tickTime。重新选举??(还没确认这个事实)
重新参与选举。
写入数据特性
当发起写入数据操作时，Leader会将数据同步到一半以上的节点之后就返回操作结果。
乐观锁性质
ZooKeeper的ZNode节点数据都包含一个dataVersion，这个dataVersion 可以在执行setData时指定一个修改前获取的dataVersion作为version参数,来尝试是否设置成功，跟数据乐观锁的概念是一样的。
Zookeeper 四字命令
通过TCP发送四个字母的命令到Zookeeper端口可以查看一些相关信息。
发送TCP包命令如下:
echo 'conf' | nc localhost 2181
conf
输出相关服务配置的详细信息。
cons
列出所有连接到服务器的客户端的完全的连接 /会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操作延迟、最后的操作执行等等信息。
dump
列出未经处理的会话和临时节点。
envi
输出关于服务环境的详细信息（区别于 conf命令）。
reqs
列出未经处理的请求
ruok
测试服务是否处于正确状态。如果确实如此，那么服务返回“imok ”，否则不做任何相应。
stat
输出关于性能和连接的客户端的列表。
wchs
列出服务器 watch的详细信息。
wchc
通过 session列出服务器 watch的详细信息，它的输出是一个与watch相关的会话的列表。
wchp
通过路径列出服务器 watch的详细信息。它输出一个与 session相关的路径。
