Zookeeper 架构设计及原理

  |   0 评论   |   0 浏览

Zookeeper 作为一个分布式协调系统,为大数据平台其他组件提供了协调服务。要想理解Zookeeper 如何对外提供服务,首先需要理解Zookeeper的架构设计工作原理

1. Zookeeper 定义

Zookeeper 是一个分布式的、开源协调服务框架,服务与分布式应用。它是Google的 Chubby 组件的一个开源实现,是HadoopHBase 的重要组件

  • 它提供了一系列的原语(数据结构)操作服务,因此分布式应用能够基于这些服务,构建出更高级别的服务,比如分布式锁服务配置管理服务分布式消息队列分布式通知与协调服务等。
  • Zookeeper 设计上易于编码,数据模型构建在树形结构目录风格的文件系统中。
  • Zookeeper 运行在Java 环境上,同时支持 Java 和 C 语言。

2. Zookeeper 的特点

Zookeeper 工作在集群中,对集群提供分布式协调服务,它提供的分布式协调服务具有如下的特点。

  • 最终一致性:客户端不论连接到哪个 Server,看到的都是同一个视图,这是Zookeeper 最重要的特点。
  • 可靠性:Zookeeper 具有简单健壮良好的性能。如果一条消息被一台服务器接收,那么它将被所有的服务器接收。
  • 实时性: Zookeeper 保证客户端将在一个时间间隔范围内,获得服务器更新的信息或服务器失效的信息。但由于网络延时等原因,Zookeeper 不能保证两个客户端能同时得到刚更新的数据,如果需要最新的数据,应该在读数据之前调用 sync() 接口。
  • 等待无关(wait-free): 慢的或失效的客户端不得干预快速客户端的请求,这就使得每个客户端都能有效 地等待。
  • 原子性: 对 Zookeeper 的更新操作要么成功,要么失败,没有中间状态。
  • 顺序性:它包括全局有序和偏序两种。全局有序是针对服务器端,例如,在一台服务器上,消息A 在消息B 前发布,那么所有服务器上的消息A 都将在消息B 前发布。偏序是针对客户端,例如,在同一个客户端消息B 在消息A 后发布,那么执行的顺序必将是先执行消息A 然后再执行消息B 。所有的更新操作都有严格的偏序关系,更新操作都是串行执行的,这是保证zookeeper功能正确性的关键。

3.Zookeeper 的基本架构

Zookeeper 服务自身组成一个集群(2n + 1 个服务节点最多允许n个失效)。Zookeeper 服务有两种角色:一种是主节点(Leader),负责投票的发起和决议,更新系统状态;另一种是从节点(Follower),用于接收客户端请求并向客户端返回结果,在选主过程(即选择主节点的过程)中参与投票。主节点失效后,会在从节点中重新选举新的主节点。

客户端(Client)可以选择连接到 Zookeeper 集群中的没台服务器端(Server),而且每台服务端的数据完全相同。每个从节点都需要与主节点进行通信,并同步主节点上更新的数据。

对于Zookeeper 集群来说,只要超过一半数量的Zookeeper 服务端可用,Zookeeper 整体服务就可用。

4. Zookeeper 的工作原理

Zookeeper 的核心是原子广播,该原子广播就是对 Zookeeper 集群上的所有主机发送数据包,通过这个机制保证了各个服务端之间的数据同步。实现这个机制在Zookeeper 中有一个内部协议,次协议有两种模式,一种是恢复模式,一种是广播模式。

当服务启动或在主节点崩溃后,次协议就进入了恢复模式,当主节点再次被选举出来,且大多数服务完成了和主节点的状态同步后,恢复模式就结束了。状态同步保证了主节点和服务端具有相同的系统状态。一旦主节点已经和多数从节点(也就是服务端)进行了状态同步后,它就可以开始广播消息,即进入广播模式。

在广播模式下,服务端会接受客户端的请求,所有的写请求都被转发给主节点,再由主节点发送广播给从节点。当半数以上的从节点完成数据的写请求之后,主节点才会提交这个更新,然后客户端才会收到一个更新成功的响应。

5. Zookeeper 的数据模型

Zookeeper 维护这一个树形层次结构,树中的结点被称为 znode。znode 可以用于存储数据,并且有一个与之相关联的访问控制列表(Access Control List,ACL,用于控制资源的访问权限)。Zookeeper 被设计用来实现协调服务(通常使用小数据文件),而不是用于存储大容量数据,因此一个znode能存储的数据被限制在 1MB 以内。

Zookeeper 的数据访问具有原子性。客户端在读取一个znode 数据时,要么读到所有数据,那么读操作失败,不会存在只读到部分数据的情况。同样,写操作将替换znode 存储的所有数据,Zookepper 会保证写操作不成功就事变,不会出现部分写成功之类的情况,也就是不会出现只保存客户端所写部分数据的情况。

znode 是客户端访问Zookeeper 的主要实体,它包含了一下主要特征。

(1)临时节点

znode 节点由两种: 临时节点和持久节点。znode的类型在创建时即确定,之后不能修改。当创建临时节点的客户端回话结束时,Zookeepr 会将该临时节点删除。而持久节点不依赖客户端回话,只有当客户端明确要删除该持久节点时才会被真正删除。临时节点不可以有子节点,即使是短暂的子节点。

(2)顺序节点

顺序节点是指名称中包含 Zookeeper 指定顺序号的znode。如果在创建znode 时设置了顺序标识,那么该znode 名称之后就会附加一个值,该值是一个单调递增的计数器添加的,由父结点维护。

在一个分布式系统中,顺序号可以用于为所有的事件进行全局排序,这样客户端就可以通过顺序号来推断事件的顺序。

(3)观察机制

znode 以某种方式发生变化时,观察(watcher)机制(观察机制:一个watcher 事件是一个一次性的触发器,当被设置了watcher的znode 发生了改变时,服务器将这个改变发送给设置了watcher的客户端,以便通知它们)可以让客户端得到通知。可以针对Zookeeper的操作来设置观察,该服务的其他操作可以触发观察。

在 Zookeeper 中,引入了watcher 机制来实现分布式的通知功能。Zookeeper允许客户端想服务端注册一个watcher 监视器,当服务端的一些特定事件触发了watcher 监视器后,就会向指定客户端发送一个异步时间通知来实现分布式的通知功能。这种机制称为注册与异步通知机制


标题:Zookeeper 架构设计及原理
作者:zh847707713
地址:http://lovehao.cn/articles/2021/11/11/1636619616127.html