Zookeeper 是一个高性能的分布式一致系统,在分布式系统中有着广泛的应用。基于它,可以实现诸如“分布式同步”、“配置管理”、“命名空间管理”等众多功能,是分布式系统中常见的基础系统。Zookeeper 主要用来解决分布式集群中应用系统的一致性问题。
~
本篇内容包括:Zookeeper————分布式过程协同技术 以及 Zookeeper 的数据结构。
文章目录
- 一、Zookeeper————分布式过程协同技术
- 1、什么是“分布式过程协同技术”
- 2、关于 Zookeeper
- 3、Zookeeper 特性
- 二、Zookeeper 的数据结构
- 1、ZooKeeper 数据模型的结构
- 2、ZooKeeper 数据模型与 Unix 文件系统差异
- 3、Znode 节点
- 三、zookeeper 应用场景
- 1、通知协调(数据发布与订阅)
- 2、命名服务
- 3、分布式锁
- 4、负载均衡
- 5、配置管理
- 6、集群管理
一、Zookeeper————分布式过程协同技术
1、什么是“分布式过程协同技术”
分布式协同技术是用来解决多进程的同步控制,使得进程有序的访问零界资源,而这种技术的本质是分布式锁。
Zookeeper 主要作用为在分布式系统中协调多个任务,一个任务可以是协作或者是竞争。
- 协作意味着多个进程需要一同处理某些事情,一些进程采取某些行动使得其他进程可以继续工作,例如:在主从模式中,主节点与从节点协作,主节点分配任务给从节点;
- 竞争是指两个进程不能同时处理工作,一个进程必须等待另一个进程,例如:同样在主从工作模式中,通过互斥排它锁的方式保证任何时刻只有一个主。
2、关于 Zookeeper
关于 Zookeeper 名字的由来:Zookeeper 由雅虎研究院开发,开发团队原来想使用动物命名项目,在讨论时大家觉得分布式系统就像一个动物园,胡乱且难以管理,而 Zookeeper 就是将这一切变得可控。遂起名为 Zookeeper,意为动物园管理员。
Zookeeper 是一个高性能的分布式一致系统,在分布式系统中有着广泛的应用。基于它,可以实现诸如“分布式同步”、“配置管理”、“命名空间管理”等众多功能,是分布式系统中常见的基础系统。有很多我们非常熟悉的系统的基础都是采用的 Zookeeper,比如 Apache Kafka、Apache HBase、Apache Solr…
Zookeeper 主要用来解决分布式集群中应用系统的一致性问题。
Zookeeper 维护一个类似 Unix 文件系统的数据结构,其中每个节点均可存储少量的数据,并且都可以被监听,可以发通知。客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)时,Zookeeper 会通知客户端来执行回调机制!
Zookeeper 在设计模式的角度上来看,是基于观察者模式的,可以把它作为一个信息的中心。使用该服务的生产者和消费者都以 Zookeeper 中的数据为基准,即 “生产者可以改变节点上的状态和数据;消费者订阅节点,从而能够在节点变动时收到通知”。基于这样的机制,将 Zookeeper 作为信息中心,便可以实现分布式系统中节点状态的最终一致性。
3、Zookeeper 特性
ZooKeeper 特性如下:
- 最终一致性(Eventually Consistent):客户端不论连接到哪个 Zookeeper 的哪一个节点,最终都会收到同一份状态。这是 Zookeeper 最重要的性能;
- 顺序一致性(Sequential Consistency):来自相同客户端提交的事务,ZooKeeper 将严格按照其提交顺序依次执行;
- 全局一致性(Single System Image):ZooKeeper 每个 Server 保存一份相同的数据副本,Clinent 无论连接那个 Server,数据都是一致的;
- 原子性(Atomicity):于 ZooKeeper 集群中提交事务,只能成功或者失败,没有中间状态;
- 可靠性(Reliability):事务一旦完成,其产生的状态变化将永久保留,直到其他事务进行覆盖;
- 实时性(Timeliness),在一定时间范围内,Client 能读到最新数据
- 等待无关(wait-free):慢的或者失效的 Client 不得干预快速的 Client 的请求,使得每个 Client 都能有效的等。
二、Zookeeper 的数据结构
1、ZooKeeper 数据模型的结构
ZooKeeper 数据模型的结构与 Unix 文件系统很类似,整体上可以看作是一棵树,每个节点称做一个 ZNode,每个 ZNode 默认能够存储 1MB 的数据,每个 ZNode 都可以通过其路径唯一标识
2、ZooKeeper 数据模型与 Unix 文件系统差异
ZooKeeper 数据模型在结构上和标准文件系统都是采用树形层次结构,每个节点可以拥有子节点。但也有不同之处:
- 引用方式:Zonde 通过路径引用,如同 Unix 中的文件路径。路径必须是绝对的,因此他们必须由斜杠字符来开头。除此以外,他们必须是唯一的,也就是说每一个路径只有一个表示,因此这些路径不能改变。在 ZooKeeper 中,路径由 Unicode 字符串组成,并且有一些限制。字符串 “/zookeeper” 用以保存管理信息,比如关键配额信息。
- 数据访问:ZooKeeper 中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据,写操作也将替换掉节点的所有数据。另外,每一个节点都拥有自己的ACL(访问控制列表),这个列表规定了用户的权限,即限定了特定用户对目标节点可以执行的操作。
- 观察:客户端可以在节点上设置 watch,我们称之为监视器。当节点状态发生改变时(Znode 的增、删、改)将会触发 watch 所对应的操作。当 watch 被触发时,ZooKeeper 将会向客户端发送且仅发送一条通知,因为 watch 只能被触发一次,这样可以减少网络流量。
3、Znode 节点
ZooKeeper 命名空间中的 Znode,兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构,又像目录一样可以作为路径标识的一部分。图中的每个节点称为一个Znode。 每个 Znode 由3部分组成:
- stat:此为状态信息, 描述该Znode的版本, 权限等信息
- data:与该Znode关联的数据
- children:该Znode下的子节点
ZooKeeper 虽然可以关联一些数据,但并没有被设计为常规的数据库或者大数据存储,相反的是,它用来管理调度数据,比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据,通常以 KB 为大小单位。ZooKeeper 的服务器和客户端都被设计为严格检查并限制每个 Znode 的数据大小至多 1M,但常规使用中应该远小于此值。
# Znode类型
ZooKeeper 创建 ZNode 时,可以指定四种类型,节点的类型在创建时即被确定,并且不能改变:
- PERSISTENT,持久性 ZNode。创建后,即使客户端与服务端断开连接也不会删除,只有客户端主动删除才会消失。
- PERSISTENT_SEQUENTIAL,持久性顺序编号 ZNode。和持久性节点一样不会因为断开连接后而删除,并且 ZNode 的编号会自动增加。
- EPHEMERAL,临时性 ZNode。客户端与服务端断开连接,该 ZNode 会被删除。
- EPEMERAL_SEQUENTIAL,临时性顺序编号 ZNode。和临时性节点一样,断开连接会被删除,并且 ZNode 的编号会自动增加。
Ps:当创建 Znode 的时候,用户可以请求在 ZooKeeper 的路径结尾添加一个递增的计数。这个计数对于此节点的父节点来说是唯一的,它的格式为"%10d"(10 位数字,没有数值的数位用 0 补充,例如"0000000001")。当计数值大于 2^32-1 时,计数器将溢出。
三、zookeeper 应用场景
1、通知协调(数据发布与订阅)
应用配置集中到节点上,应用启动时主动获取,并在节点上注册一个 watcher,每次配置更新都会通知到应用。
数据发布/订阅(Publish/Subscribe)系统,即所谓的配置中心,顾名思义就是发布者将数据发布到 ZooKeeper 的一个或一系列节点上,供订阅者进行数据订阅,进而达到动态获取数据的目的,实现配置信息的集中式管理和数据的动态更新。
2、命名服务
分布式命名服务,创建一个节点后,节点的路径就是全局唯一的,可以作为全局名称使用
命名服务是分步实现系统中较为常见的一类场景,分布式系统中,被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等,通过命名服务,客户端可以根据指定名字来获取资源的实体、服务地址和提供者的信息。Zookeeper 也可帮助应用系统通过资源引用的方式来实现对资源的定位和使用,广义上的命名服务的资源定位都不是真正意义上的实体资源,在分布式环境中,上层应用仅仅需要一个全局唯一的名字。Zookeeper 可以实现一套分布式全局唯一 ID 的分配机制。
3、分布式锁
Zookeeper 能保证数据的强一致性,用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁,另一个用户检测该节点,如果存在,代表别的用户已经锁住,如果不存在,则可以创建一个节点,代表拥有一个锁。
4、负载均衡
通过 Zookeeper 来实现服务动态注册、机器上线与下线的动态感知,扩容方便,容错性好,且无中心化结构能够解决之前使用负载均衡设备所带来的单点故障问题。只有当配置信息更新时服务消费者才会去 Zookeeper上获取最新的服务地址列表,其他时候使用本地缓存即可,这样服务消费者在服务信息没有变更时,几乎不依赖配置中心,能大大降低配置中心的压力。
5、配置管理
在分布式应用环境中很常见,例如同一个应用系统需要多台节点运行,但是它们运行的应用系统的某些配置项是相同的,如果要修改这些相同的配置项,那么就必须同时修改每台运行这个应用系统的 PC Server,这样非常麻烦而且容易出错。像这样的配置信息完全可以交给 Zookeeper 来管理,将配置信息保存在 Zookeeper 的某个目录节点中,然后将所有需要修改的应用机器监控配置信息的状态,一旦配置信息发生变化,每台应用机器就会收到 Zookeeper 的通知,然后从 Zookeeper 获取新的配置信息应用到系统中。
6、集群管理
每个加入集群的机器都创建一个节点,写入自己的状态。监控父节点的用户会受到通知,进行相应的处理。离开时删除节点,监控父节点的用户同样会收到通知。