zookeeper主要有以下几种存储类型
永久节点---- 不手动删除，就永久存在
永久有序节点---- 经过排序的永久节点
临时介电 ---- 一次会话结束后，在一定时间就会将其自动删除
临时有序节点 ---- 经过排序的临时节点
杯型节点 ---- 规定在60秒后自动删除没有子节点的数据
TTL节点 ---- 可以设定自动删除时间 （不稳定，不建议使用）
-------创建节点
因为zookeeper的存储结构为树类型
因此创建节点 create /**/** abc 以/的形式创建 要想在节点下添加数据 直接空格abc的形式
创建永久节点 create /**/**
创建永久有序节点 create -s /**/**
创建临时节点 create -e /**/**
创建临时有序节点 create -e -s /**/**
创建杯型节点 create -c /**/**
-s 有序 -e 临时 -c 杯型
------查询节点
ls /**/**
ls -R /** 查询/**下的所有字节点（递归查询）
---获取节点数据
get /**/**
get -s /**/** 获取该节点下的详细数据
------删除节点
普通删除：
delete /** 不为空不能删除
deleteall /** 可与删除以下的所有节点和数据
乐观锁删除：
delete -v dataVersion /**
dataversion为这个节点的数据版本号，数据版本号不对就不能删除。数据版本号就是节点下的数据修改次数
要想删除成功，可通过 get -s /**获取其节点下的详细数据，从而得到dataVersion 来删除
-------权限
添加权限---addauth digest 账号：密码
给节点数据添加权限：create /** abc auth:账号：密码：权限种类
例：
添加权限：addauth digest xiaoming:123456
给节点数据添加权限：create /test abc auth:xiaoming:123456:cdrwa
这样如果在别的服务中 如果向获取get /test abc获取不到，只有给别的服务也添加权限 addauth digest xiaoming:123456才能获取
----------curator客户端的使用 ：14集
----------watch监听 -w
create /test9
get -w /test9给其添加一个监听
当在另外的会话中set /test9 abc 监听的地方就可以被触发，但这个监听只能监听一次
ls -w /test3给其添加一个监听
当在另外的会话中create /test3/** 监听的地方就可以被触发，但这个监听只是监听这一级节点，如果是孙节点就监听不到
如果想在此节点以下节点全部生效就 ls -R -w /test3 ，-R会实现此节点下所有节点的监听（递归）
get 和 ls监听的不一样，get监听的节点数据ls监听的节点增删
也可用-curator客户端的实现 具体看19集
1.zk中锁的种类
zk中的分布式锁：
读锁：大家都可以读，要想上读锁的前提：之前的锁没有写锁
写锁：只有得到写锁的才能写，要想上写锁的前提是，之前没有任何锁
2.zk如何上读锁
1创建一个临时序号节点，节点的数据是read，表示是读锁
2获取当前zk中序号比自己小的所有节点
3判断最小节点是否是读锁：
如果不是读锁的话，则上锁失败，为最小节点设置监听。阻塞等待，zk的watch机制会当最小的节点发生变化时通知当前节点，于是
是再执行第二步的流程
如果是读锁的话，则上锁成功
3.zk如何上写锁
创建一个临时有序节点，节点的数据是write，表示是写锁
获取zk中所有的子节点
判断自己是否是最小的节点：
如果是，则上锁成功
如果不是，说明前面还有锁，则上锁失败，监听最小的节点，如果最小节点有变化，则回到第二步。
4.羊群效应
如果用上述的上锁方式，只要有节点发生变化，就会触发其他节点的监听事件，这样的话对zk的压力非常大，--羊群效应。可以调整成
链式监听。解决这个问题。