1.客户端命令行操作
1.启动客户端（其中-server Cenos01 :2181为修改名称，不修改则为localhost）
[root@Cenos01 zookeeper-3.5.7]$ bin/zkCli.sh -server Cenos01 :2181
2.显示所有操作命令
[zk: Cenos01 :2181(CONNECTED) 1] help
3.查看当前znode中所包含的内容（ls /）
4.查看当前节点详细数据（ls -s /）
（1）czxid：创建节点的事务 zxid
每次修改 ZooKeeper 状态都会产生一个 ZooKeeper 事务 ID。事务 ID 是 ZooKeeper 中所 有修改总的次序。每次修改都有唯一的 zxid，如果 zxid1 小于 zxid2，那么 zxid1 在 zxid2 之 前发生。
（2）ctime：znode 被创建的毫秒数（从 1969 年开始）
（3）mzxid：znode 最后更新的事务 zxid
（4）mtime：znode 最后修改的毫秒数（从 1969 年开始）
（5）pZxid：znode 最后更新的子节点 zxid
（6）cversion：znode 子节点变化号，znode 子节点修改次数
（7）dataversion：znode 数据变化号
（8）aclVersion：znode 访问控制列表的变化号
（9）ephemeralOwner：如果是临时节点，这个是 znode 拥有者的 session id。如果不是 临时节点则是 0。
（10）dataLength：znode 的数据长度
（11）numChildren：znode 子节点数量
2.节点类型
1.创建不带序号永久节点（创建节点一定要赋值）
[zk: Centos01:2181(CONNECTED) 2] create /sanguo "hanxiandi"
[zk: Centos01:2181(CONNECTED) 4] create /sanguo/shuguo "liubei"
2.获取节点值（get -s /sanguo）
[zk: Centos01:2181(CONNECTED) 5] get -s /sanguo
3.创建带序号的永久节点（create -s /sanguo/weiguo/zahngliao "zhangliao"）
如果原来没有序号节点，序号从 0 开始依次递增。如果原节点下已有 2 个节点，则再排 序时从 2 开始，以此类推。
不带序号创建相同节点值会报错显示已存在；
4.创建不带序号的短暂节点（create -e /sanguo/wuguo "zhouyu"）
5.创建带序号的短暂节点（create -e -s /sanguo/wuguo "zhouyu"）
6.退出客户端（quit）
7.修改节点值（set /sanguo/weiguo "simayi"）
8.删除节点（delete /sanguo/jin）
9.删除递归节点（deleteall /sanguo/shuguo）
10.查看节点状态（stat /sanguo）
3.监听器
原理：
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、节点删除、子目 录节点增加删除）时，ZooKeeper 会通知客户端。监听机制保证 ZooKeeper 保存的任何的数 据的任何改变都能快速的响应到监听了该节点的应用程序。
1.节点的值变化监听（只能监听一次，就不会再监听，如果需要再次监听，需要再次注册）
（1）在 Centos02 主机上注册监听/sanguo 节点数据变化（get -w /sanguo）注册监听器
（2）在 Centos02 主机上修改/sanguo 节点的数据（set /sanguo "xisi"）
（3）观察Centos02 主机收到数据变化的监听
2.节点的子节点变化监听（路径变化）ls -w /sanguo
4.客户端API创建节点
1.启动zookeeper集群，创建meven项目，添加pom依赖
需要在项目的 src/main/resources 目录下，新建一个文件，命名为“log4j.properties”
2.创建客户端
3.创建子节点
4.获取子节点并监听变化
5.判断节点是否存在
6.客户端向服务器端写数据流程
5.服务器动态上下线监听案例
1.需求分析：
2.服务器端注册代码
3.客户端代码
4.测试
启动服务器端和客户端，创建或删除节点，查看控制台变化
6.zookeeper分布式锁
什么叫做分布式锁呢？
比如说"进程1"在使用该资源的时候，会先去获得锁，"进程1"获得锁以后会对该资源保持独占，这样其他进程就无法访问该资源，"进程1"用完该资源以后就将锁释放掉，让其他进程来获得锁，那么通过这个锁机制，我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。
1.原生zookeeper实现分布式锁案例
测试：
2.Curator 框架实现分布式锁案例
1.原生的 Java API 开发存在的问题
（1）会话连接是异步的，需要自己去处理。比如使用 CountDownLatch
（2）Watch 需要重复注册，不然就不能生效
（3）开发的复杂性还是比较高的
（4）不支持多节点删除和创建。需要自己去递归
2.案例：
添加依赖：
代码实现：
Curator 是一个专门解决分布式锁的框架，解决了原生 JavaAPI 开发分布式遇到的问题。
