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 开发分布式遇到的问题。