深入了解ZooKeeper(一)

时间:2021-11-02 14:39:54
在上篇博客 ZooKeeper初探之安装和配置中已经对Zookeeper这个“服务协调者”有了初步的认识和了解,一个字“美”,接下来开始深入的交往,开始了解其内心世界!

1. 内容思维导图

深入了解ZooKeeper(一)

2. 分布式协调技术

  在进程间通讯中为了防止资源的竞争和抢占,我们有很多方法(如原子函数,互斥锁,事件,信号等)去实现临界资源的有序访问。那么处于分布式的环境中时,我们又该如何去处理各服务之间的协调关系呢?

  深入了解ZooKeeper(一)

  图中有三台机器,每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来,构成一个系统来为用户提供服务,对用户来说这个系统的架构是透明的,假设在第一台机器上挂载了一个资源,然后这三个物理分布的进程都要竞争这个资源,但我们又不希望他们同时进行访问,这时候我们就需要一个协调器,来让他们有序的来访问这个资源。这个协调器就是我们经常提到的那个锁,比如说"进程-1"在使用该资源的时候,会先去获得锁,"进程1"获得锁以后会对该资源保持独占,这样其他进程就无法访问该资源,"进程1"用完该资源以后就将锁释放掉,让其他进程来获得锁,那么通过这个锁机制,我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。这个分布式锁也就是我们分布式协调技术实现的核心内容。

3. 分布式锁的实现

  为了防止分布式系统中的多个进程之间相互干扰,我们需要一种分布式协调技术来对这些进程进行调度。而这个分布式协调技术的核心就是来实现这个分布式锁。那么这个锁怎么实现呢?这实现起来确实相对来说比较困难的。

3.1 面临的问题

  同台机器之间的通讯和不同机器之间通讯的主要区别就在于网络,因为网络是不可靠的。

  比如,在同一台机器上,你对一个服务的调用如果成功,那就是成功,如果调用失败,比如抛出异常那就是调用失败。但是在分布式环境中,由于网络的不可靠,你对一个服务的调用失败了并不表示一定是失败的,可能是执行成功了,但是响应返回的时候失败了。还有,A和B都去调用C服务,在时间上 A还先调用一些,B后调用,那么最后的结果是不是一定A的请求就先于B到达呢? 这些在同一台机器上的种种假设,我们都要重新思考,我们还要思考这些问题给我们的设计和编码带来了哪些影响。还有,在分布式环境中为了提升可靠性,我们往往会部署多套服务,但是如何在多套服务中达到一致性,这在同一台机器上多个进程之间的同步相对来说比较容易办到,但在分布式环境中确实一个大难题。

所以分布式协调远比在同一台机器上对多个进程的调度要难得多,而且如果为每一个分布式应用都开发一个独立的协调程序。一方面,协调程序的反复编写浪费,且难以形成通用、伸缩性好的协调器。另一方面,协调程序开销比较大,会影响系统原有的性能。所以,急需一种高可靠、高可用的通用协调机制来用以协调分布式应用。

3.2 分布式锁的实现者

  目前,在分布式协调技术方面做得比较好的就是Google的Chubby还有Apache的ZooKeeper他们都是分布式锁的实现者。有人会问既然有了Chubby为什么还要弄一个ZooKeeper,难道Chubby做得不够好吗?不是这样的,主要是Chbby是非开源的,Google自家用。后来雅虎模仿Chubby开发出了ZooKeeper,也实现了类似的分布式锁的功能,并且将ZooKeeper作为一种开源的程序捐献给了Apache,那么这样就可以使用ZooKeeper所提供锁服务。而且在分布式领域久经考验,它的可靠性,可用性都是经过理论和实践的验证的。所以我们在构建一些分布式系统的时候,就可以以这类系统为起点来构建我们的系统,这将节省不少成本,而且bug也 将更少。

                深入了解ZooKeeper(一)

                   深入了解ZooKeeper(一)

4. Zookeeper数据模型

  ZooKeeper拥有一个层次的命名空间,这个和标准的文件系统非常相似

  深入了解ZooKeeper(一)

4.1 结构

  ZooKeeper命名空间中的Znode,兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL(访问控制列表)、时间戳等数据结构,又像目录一样可以作为路径标识的一部分。图中的每个节点称为一个Znode。 每个Znode由3部分组成:

  (1)stat:状态信息,描述Znode的版本、权限等信息

  (2)data:与Znode关联的数据

  (3)children:该Znode下的子节点

  ZooKeeper虽然可以关联一些数据,但并没有被设计为常规的数据库或者大数据存储,相反的是,它用来管理调度数据,比如分布式应用中的配置文件信息状态信息汇集位置等等。这些数据的共同特性就是它们都是很小的数据,通常以KB为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M,但常规使用中应该远小于此值。

4.2 引用方式

  Znode通过路径访问,但路径必须是绝对路径,因此他们必须由斜杠字符来开头。除此以外,他们必须是唯一的,也就是说每一个路径只有一个表示,因此这些路径不能改变。在ZooKeeper中,路径由Unicode字符串组成,并且有一些限制。字符串"/zookeeper"用以保存管理信息,比如关键配额信息。

4.3 数据访问

  ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据,写操作也将替换掉节点的所有数据。另外,每一个节点都拥有自己的ACL(访问控制列表),这个列表规定了用户的权限,即限定了特定用户对目标节点可以执行的操作。

4.4 节点类型

  Zookeeper有两种节点类型:临时节点和永久节点

  (1)临时节点:该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束,临时节点将被自动删除,当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话,但他们对所有的客户端还是可见的。另外,ZooKeeper的临时节点不允许拥有子节点。

  (2)永久节点:该节点的生命周期不依赖于会话,并且只有在客户端显示执行删除操作的时候,他们才能被删除。

  注:节点的类型是在创建时被确定的,并且不能改变

  当创建Znode的时候,用户可以请求在ZooKeeper的路径结尾添加一个递增的计数。这个计数对于此节点的父节点来说是唯一的,它的格式为"%10d"(10位数字,没有数值的数位用0补充,例如"0000000001")。当计数值大于232-1时,计数器将溢出。

4.5 节点属性

深入了解ZooKeeper(一)

5. Zookeeper时间表示

5.1 Zxid

  致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳,并且这个时间戳全局有序。也就是说,每个对节点的改变都将产生一个唯一的Zxid。如果Zxid1的值小于Zxid2的值,那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。实际上,ZooKeeper的每个节点维护者三个Zxid值,为别为:cZxid、mZxid、pZxid。

  cZxid: 是节点的创建时间所对应的Zxid格式时间戳

  mZxid:是节点的修改时间所对应的Zxid格式时间戳

  实现中Zxid是一个64为的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个 新的epoch。低32位是个递增计数

5.2 版本号

  对节点的每一个操作都将致使这个节点的版本号增加。每个节点维护着三个版本号,他们分别为:

  ① version:节点数据版本号
  ② cversion:子节点版本号
  ③ aversion:节点所拥有的ACL版本号

6. Zookeeper服务操作

  在ZooKeeper中有9个基本服务操作,如下图所示:

  深入了解ZooKeeper(一)

  更新ZooKeeper操作是有限制的。delete或setData必须明确要更新的Znode的版本号,我们可以调用exists找到。如果版本号不匹配,更新将会失败。

  更新ZooKeeper操作是非阻塞式的。因此客户端如果失去了一个更新(由于另一个进程在同时更新这个Znode),他可以在不阻塞其他进程执行的情况下,选择重新尝试或进行其他操作。

  尽管ZooKeeper可以被看做是一个文件系统,但是处于便利,摒弃了一些文件系统地操作原语。因为文件非常的小并且使整体读写的,所以不需要打开、关闭或是寻地址的操作

7. watch触发器

  Zookeeper可以为所有的读操作设置watch,这些读操作包括:exists()、getChildren()及getData()。watch事件是一次性的触发器,当watch的对象状态发生改变时,将会触发此对象上watch所对应的事件,watch事件将被异步地发送给客户端,并且Zookeeper为watch机制提供了有序的一致性保证,理论上,客户端接收watch事件的时间要快于其看到watch对象状态变化的时间。

7.1 watch类型  

ZooKeeper所管理的watch可以分为两类:

  ① 数据watch(data  watches):getData和exists负责设置数据watch
  ② 孩子watch(child watches):getChildren负责设置孩子watch

我们可以通过操作返回的数据来设置不同的watch:

  ① getData和exists:返回关于节点的数据信息
  ② getChildren:返回孩子列表

因此:

  ① 一个成功的setData操作将触发Znode的数据watch

  ② 一个成功的create操作将触发Znode的数据watch以及孩子watch

  ③ 一个成功的delete操作将触发Znode的数据watch以及孩子watch

7.2 watch注册与触发

深入了解ZooKeeper(一)

  Watch由客户端所连接的ZooKeeper服务器在本地维护,因此watch可以非常容易地设置、管理和分派。当客户端连接到一个新的服务器时,任何的会话事件都将可能触发watch。另外,当从服务器断开连接的时候,watch将不会被接收。但是,当一个客户端重新建立连接的时候,任何先前注册过的watch都会被重新注册。

7.3 watch需要注意事项

Zookeeper的watch实际上要处理两类事件:

① 连接状态事件(type=None, path=null)

  这类事件不需要注册,也不需要我们连续触发,我们只要处理就行了。

② 节点事件

  节点的建立,删除,数据的修改。它是one time trigger,我们需要不停的注册触发,还可能发生事件丢失的情况。

  上面2类事件都在Watch中处理,也就是重载的process(Event event)

节点事件的触发,通过函数exists,getData或getChildren来处理这类函数,有双重作用:

  ① 注册触发事件

  ② 函数本身的功能

函数的本身的功能又可以用异步的回调函数来实现,重载processResult()过程中处理函数本身的的功能。

本博客的内容摘抄自: https://blog.csdn.net/fenglongmiao/article/category/7442147