什么是zookeeper?
目录
分布式协调服务
zookeeper的数据结构
类似于文件目录
这里面的每一个方框被认为是一个节点znode。
znode里面有啥东西
data：数据信息
ACL：什么ip可以访问此znode
children:下面节点的引用
stat: znode的版本号，时间戳，等。
znodeApi操作以及watch机制
getData()：查询节点数据
exists()：判断节点是否存在
getChildren()：获取子节点信息
setData()：设置数据
create()：创建节点
delete()：删除节点
在特定的节点设置watch为true，当这个节点的数据有变化的时候异步通知watch这个节点的客户端。
zookeeper数据一致性
zk作为分布式协调服务，当自身宕机了怎么办？所以维护了一个zk集群。
但是怎么保证主从服务器之间数据一致呢？以及节点数据恢复呢？这就用到了ZAB协议。zookeeper atomic broadcast
ZAB协议
三个节点状态
Looking
Leading
Following
ZAB崩溃恢复
master宕机了怎么办？
master选举
投票时带着自己服务器id和最新事务id（ZXID）
节点1首先给自己投一票，节点11票，节点2首先给自己投一票，然后给节点1投一票带上自己的机器id和最新事务id（2 32）此时节点2的事务id大于节点1的事务id(20)重新发起投票节点1给节点2投一票，此时节点2有2票半数以上结束选举。节点2为leader 。
ZAB主从数据同步
broadcast
客户端首先发送写入数据给任意的follow节点
follow节点传播给leader节点
leader节点二阶段提交，发送propose给follow节点
follow节点接受，写入数据，成功后返回ack消息给leader节点
leader节点接收到半数的ack，返回给客户端，然后广播commit请求给follow节点
zookeeper的应用
分布式锁
利用了Znode临时顺序节点的特点
client1试图获取锁，首先 新建一个parentLock，在下面新建一个Lock1，此时查询Lock1是最靠前的节点所以client1获取锁。
此时Client1 已经获得锁了，Client2也想获取锁，首先建立一个Lock2，此时查看Lock2前面还有Lock1节点所以无法获取锁，
client2抢锁失败向排序仅比它考前的节点Lock1注册Watcher，用于监听Lock1是否存在
当任务完成，客户端显示释放锁或者故障中断因为是临时节点此时也会中断与客户端的联系
此时Client1释放锁，lock1切断与客户端的联系，由于Client2在lock1注册了Watcher,所以会收到通知，此时client2查询parentlock下面的所有节点确认自己的节点lock2是目前最小的节点，lock2就获取到了锁。
服务的注册与发现
Znode和Watcher机制，最著名的是阿里的Dubbo框架
我的理解是：服务注册时相当于注册一个znode，里面有四部分相关数据，发现有在对应的服务商注册的watcher。dubbo框架用zookeeper作为服务的注册和发现就是利用了znode和watcher机制。