该文章用于学习Zookeeper，记录自己学习过程中的问题与心得。
ZooKeeper是⼀个分布式的，开放源码的分布式应⽤程序协调服务，是Google的Chubby⼀个开源的实现，它是集群的管理者， 监视着集群中各个节点的状态根据节点提交的反馈进⾏下⼀步合理操作。最终，将简单易⽤的接⼝和性能⾼效、功能稳定的系统 提供给⽤⼾。
ZooKeeper就是⼀个第三⽅，也称中间⼈，它搭建了⼀个平台，让所有其它进程通过它来进⾏间接的交流。
- ZooKeeper的数据模型：ZooKeeper选择了树作为⾃⼰存储数据的结构，其实它和⽂件系统也⾮常相似，如下图所示：
2. 数据离不开增、删、改、查，对应树来说，增就是添加新的节点到树中，删就是从树中删除某个节点，改就是修 改树中某个节点上存放的数据，查就是找到树中某个节点读取它上⾯存放的数据。
总而言之，树形只是一种结构，真正的数据是在节点上，叶子节点或非叶子节点。
3. ZooKeeper提供了什么？
1、⽂件系统
2、通知机制
文件系统：Zookeeper提供⼀个多层级的节点命名空间（节点称为znode）。与⽂件系统不同的是，这些节点都可以设置关联的数据，⽽⽂ 件系统中只有⽂件节点可以存放数据⽽⽬录节点不⾏。Zookeeper为了保证⾼吞吐和低延迟，在内存中维护了这个树状的⽬录结 构，这种特性使得Zookeeper不能⽤于存放⼤量的数据，每个节点的存放数据上限为1M。
通知机制：client端会对某个znode建⽴⼀个watcher事件，当该znode发⽣变化时，这些client会收到zk的通知，然后client可以根据 znode变化来做出业务上的改变等。
Zookeeper作为中间件，需要具有盯梢能⼒和通知其它进程的能⼒。这在zookeeper中对应⼀个专业术语，叫Watch。
这个Watch是⼀次性的，即只能使⽤⼀次。另外，zookeeper还要有⼀定的会话延续能⼒，⽅便在断开时间不⻓的时候找回原来的会话。
因此zookeeper应该有，监视节点、通知进程、保持⻓连接，会话延续等这样的能⼒。
其实⼯作过程是这样的，业务进程启动后与zookeeper建⽴连接，然后在zookeeper⾥创建临时节点并写⼊⾃⼰ 的相关信息。接着通过周期性的⼼跳和zookeeper保持住连接。 ⼀旦业务进程挂掉，zookeeper将接受不到⼼跳了，那么在超过⼀定的时间后，zookeeper将会删除与之对应的临 时节点，表⽰这个业务进程不再可⽤了。
人们容易原谅别人的错误，却很难原谅别人的正确！
