Zookeeper基本概念

一、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

– 求知若饥，虚心若愚。