概述
zookeeper从设计角度是一个基于观察者模式设计的分布式管理框架,负责存储和管理数据,接收观察者注册,一旦数据状态发生变化,zookeeper负责通知观察者做出响应
特点
- 一个领导者(leader)和多个跟随者(follower)组成集群
- 集群中只要有半数以上节点存活,zk集群均可正常服务
- 全局数据一致:每个server均保存一个数据副本
- 更新请求顺序执行
- 数据更新原子性
- 实时性,一定时间范围内,client可以读取到最新数据
数据结构
类似Unix文件系统,整体为一棵树,每个节点称作一个zNode,每个zNode默认存储1MB数据,每个ZNode可以通过路径唯一标识应用场景
- 解压安装包,
- 查看是否存在zoo.cfg文件, 不存在可以将zoo_simple.cfg更改为zoo.cfg文件
- 自定义dataDir目录并创建,在zoo.cfg中指定dataDir的路径
启动服务
每个安装服务器上的dataDir目录下创建myid文件(touch myid)
- 编辑每个服务器的myid内容,设置编号(数字且各不相同)
- 每个服务器zoo.cfg增加以下配置:server.${1}=${2}.${3}.${4}
- ${1}:每个服务器上的myid编号
- ${2}:每个服务器IP或域名
- ${3}:端口号,leader和follower的数据通信端口
- ${4}:端口号,leader和follower的选举通信端口
- 分别调用启动命令启动每台服务器上zk
参数详解
- tickTime:心跳时间(ms)
- initLimit:leader和follower初始化的的心跳次数(n * tickTime)
- syncLimit:leader和follower启动之后之间的心跳次数(n*tickTime)
- dataDir:数据目录存储路径
- clientPort:端口号
内部原理
选举机制
- 持久(Persistent):客户端与服务器断开连接,创建节点不删除
- 短暂(Ephemeral):客户端与服务器断开连接后,创建节点自己删除
- 持久与短暂临时节点都有一个顺序节点类型,即创建znode时设置顺序标识,znode名称后会附加一个值,顺序是一个单调递增的计数器,由父节点维护
Stat节点状态
- czxid- 创建节点的事务 zxid;每次修改 ZooKeeper 状态都会收到一个 zxid 形式的时间戳,也就是 ZooKeeper 事务 ID. 事务 ID 是 ZooKeeper 中所有修改总的次序。每个修改都有唯一的 zxid ,如果 zxid1 小于 zxid2 之前发生。
- ctime-zonde 被创建的毫秒数(从1970开始)
- Mzxid-zonde 最后更新的事务zxid
- Mtime-zonde 最后修改的毫秒数(从1970开始)
- pZxid-zonde 最后更新的子节点zxid
- Cversion-zonde 子节点变化号,zonde 子节点修改次数
- dataversion-znode 数据变化号
- aclVersion-znode 访问控制列表的变化号
- ephemeralOwner-如果是临时节点,这个是 znode 拥有者的 session id.如果不是临时节点则是0.
- dataLength-znode 的数据长度
-
监听过程
zk客户端启动两个线程,一个负责网络通信connect,一个监听listener
- connect线程将注册监听事件发送到zk
- zk将监听事件添加到监听列表中
- zk监听到变化,将消息发送给listener,listener调用自定义process()方法进行处理
- 监听可以监听路径数据变化以及路径下子节点变化
写数据流程
客户端命令行操作
| 命令 | 描述 | | —- | —- | | help | 显示所有操作命令 | | ls path [watch] | 使用ls命令来查看当前znode中包含内容 | | ls2 path [watch] | 查看当前节点数据并能看到更新次新等数据 | | create | 普通创建
-s:含有序列
-e:临时(重启或超时会消失) | | get path [watch] | 获得节点值 | | set | 设置节点具体值 | | delete | 删除节点 | | rmr | 递归删除节点 |