一、Zookeeper基本概念
1、集群角色
Zookeeper集群中的角色主要有以下三类:
- 领导者(Leader):为客户端提供读写服务,负责进行投票的发起和决议,并维护更新集群状态,它是由集群选举所产生;
- 学习者(learner):包括跟随者(Follower)和观察者(Observer)
- Follower:为客户端提供读写服务,用于接受客户端请求并向客户端返回结果,并定期向Leader汇报自己的节点状态。同时也参与写操作“过半写成功”的策略和Leader的投票选举过程;
- Observer:为客户端提供读写服务,可以接受客户端连接,将写请求转发给 leader,并定期向Leader汇报自己的节点状态。但是 Observer参与写操作“过半写成功”的策略和Leader的投票选举过程,只同步了 Leader的状态。Observer的目的是为了在不影响写性能的情况下提升集群的读性能。
- 客户端(client):请求发起方
2、会话(Session)
会话(Session):是指客户端会话,是客户端连接服务端的一个TCP长连接。服务端的 Watch事件通知也是通过该 TCP连接。
Zookeeper客户端通过 TCP长连接连接到服务集群,会话(Session)从第一次连接开始就已经建立,之后通过心跳检测机制来保持有效的会话状态。通过这个连接,客户端可以发送请求并接收响应,同时也可以接收到 Watch事件的通知。
关于会话中另外一个核心的概念是 sessionTimeOut(会话超时时间)
,当由于网络故障或者客户端主动断开等原因,导致连接断开,此时只要在会话超时时间之内重新建立连接,则之前创建的会话依然有效。
会话状态:
会话(session)是 zookepper 非常重要的概念,客户端和服务端之间的任何交互操作都与会话有关。
看下这图,Zk 客户端和服务端成功连接后,就创建了一次会话,ZK 会话在整个运行期间的生命周期中,会在不同的会话状态之间切换,这些状态包括:
- CONNECTING
- CONNECTED
- RECONNECTING
- RECONNECTED
- CLOSE
一旦客户端开始创建 Zookeeper 对象,那么客户端状态就会变成 CONNECTING 状态。
同时客户端开始尝试连接服务端,连接成功后,客户端状态变为 CONNECTED。
通常情况下,由于断网或其他原因,客户端与服务端之间会出现断开情况,一旦碰到这种情况,Zookeeper 客户端会自动进行重连服务,同时客户端状态再次变成 CONNCTING,直到重新连上服务端后,状态又变为 CONNECTED。
在通常情况下,客户端的状态总是介于 CONNECTING 和 CONNECTED 之间。但是,如果出现诸如会话超时、权限检查或是客户端主动退出程序等情况,客户端的状态就会直接变更为 CLOSE 状态。
3、数据节点(Znode)
Zookeeper数据模型是由一系列基本数据单元 Znode(数据节点)组成的节点树(Znode Tree),其中根节点为 / ,子节点由 /
斜杆进行分割的路径。
每个节点上都会保存自己的数据内容和节点属性信息,每个节点称做一个 Znode。
Zookeeper中节点可以分为两大类:
- 持久节点(persistent):节点一旦创建,除非被主动删除,否则会一直在Zookeeper中存在。即使发生ZooKeeper集群宕机或者client宕机也不会丢失。
- 临时节点 (ephemeral):一旦创建该节点的客户端会话失效,则所有该客户端创建的临时节点都会被删除。即临时节点它的生命周期是跟会话绑定,一旦客户端会话失效,临时节点将会删除。
另外,Zookeeper可以为每个节点(临时节点/持久节点)添加SEQUENTIAL属性
,一旦有这个属性,那么节点就是一个有序节点。
SEQUENTIAL(有序属性):代表该节点是否具有递增属性。
如果指定该属性,那么在这个节点创建时,Zookeeper会自动在其节点名称后面追加一个由父节点维护的递增数字。即顺序号是一个单调递增的计数器,由父节点维护。
所以,Znode可分为 4种类型:
- 持久的(persistent)
- 临时的(ephemeral)
- 持久有序的(persistent_sequential)
- 临时有序的(ephemeral_sequential)
Container节点(3.5.3版本新增):Container容器节点,当容器中没有任何子节点, 该容器节点会被zk定期删除(定时任务默认60s 检查一次)。 和持久节点的区别是 ZK 服务端启动后,会有一个单独的线程去扫描,所有的容器节点,当发现容器节点的子节点数量为 0 时,会自动删除该节点。可以用于 leader 或者锁的场景中。
TTL节点: 带过期时间节点,默认禁用,需要在zoo.cfg中添加 extendedTypesEnabled=true 开启。 注意:ttl不能用于临时节点 。
#创建持久节点
create /servers xxx
#创建临时节点
create ‐e /servers/host xxx
#创建临时有序节点
create ‐e ‐s /servers/host xxx
#创建容器节点
create ‐c /container xxx
# 创建ttl节点
create ‐t 10 /ttl
节点状态属性信息:
4、版本号
Zookeeper会对每一个Znode维护一个Stat的数据结构,Stat中记录了 Znode的三个数据版本,分别是:
- version:当前Znode的版本
- cversion:当前Znode子节点的版本
- aversion:当前Znode的ACL版本
这些版本号,它会随着每次数据变化而自增。使用版本来阻止并行操作的不一致性。
5、事件监听器(Watcher)
Zookeeper中一个常用的功能是 Watcher(事件监听器),它允许用户在指定节点上注册 Watcher(可针对感兴趣的事件注册监听),,并且在一些感兴趣的特定事件发生的时候,Watcher会被触发,Zookeeper服务端会将事件通知到感兴趣的客户端上去,该机制是Zookeeper实现分布式协调服务的重要特性。
6、ACL策略
Zookeeper采用 ACL(Access Control Lists)策略来进行权限控制,类似于UNIX文件系统的权限控制。用来保障数据的安全。
它定义了如下五种权限:
- CREATE :允许创建子节点;
- READ :允许从节点获取数据并列出其子节点;
- WRITE :允许为节点设置数据;
- DELETE :允许删除子节点;
- ADMIN :允许为节点设置权限。
二、Zookeeper数据模型
1、Zookeeper数据模型
Zookeeper数据模型是由一系列基本数据单元 Znode(数据节点)组成的节点树(Znode Tree),其中根节点为 / ,子节点由 /斜杆进行分割的路径。
每个节点上都会保存自己的数据内容和节点属性信息,每个节点称为一个“数据节点”或 ZNode。
ZooKeeper使用文件系统模型主要基于以下两点考虑:
- 1.文件系统的树形结构便于表达数据之间的层次关系
- 2.文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace )
ZooKeeper的层次模型称作 Data Tree,Data Tree的每个节点叫作Znode。
不同于文件系统,每个节点都可以保存数据,每一个 ZNode 默认能够存储 1MB 的数据,每个 ZNode 都可以通过其路径唯一标识,每个节点都有一个版本(version),版本从0开始计数。
注意:
- 每个 znode 可以存储数据,还可以挂载子节点,因此可以称之为“树”
- 每一个 znode 都必须有值,如果没有值,节点是不能创建成功的。
在 Zookeeper 中,znode 是一个跟 Unix 文件系统路径相似的节点,可以往这个节点存储或获取数据。
- 通过客户端可对 znode 进行增删改查的操作,
- 还可以注册 watcher 监控 znode 的变化。
上面关于 Zookeeper的知识点参考网络文章,自己进行整理加深理解,具体使用后面再深入认识。
参考文章:
- Zookeeper工作原理(详细):https://www.cnblogs.com/raphael5200/p/5285583.html
- ZooKeeper基本概念:https://blog.csdn.net/zhang7761/article/details/110235102
– 求知若饥,虚心若愚。