分布式协调服务框架——Zookeeper
Posted 小企鹅推雪球!
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式协调服务框架——Zookeeper相关的知识,希望对你有一定的参考价值。
文章目录
Zookeeper 简介
- Zookeeper 是⼀个分布式协调服务的开源框架。 主要⽤来解决分布式集群中应⽤系统的⼀致性问题,例如怎样避免同时操作同⼀数据造成脏读的问题。
- ZooKeeper 本质上是⼀个分布式的⼩⽂件存储系统。 提供基于类似于⽂件系统的⽬录树⽅式的数据存储,并且可以对树中的节点进⾏有效管理。
- ZooKeeper 提供给客户端监控存储在zk内部数据的功能,从⽽可以达到基于数据的集群管理。
- ZooKeeper可以做到: 统⼀命名服务(dubbo)、分布式配置管理(solr的配置集中管理)、分布式消息队列(sub/pub)、分布式锁、分布式协调等功能。
Zookeeper 架构组成
- Leader的作用:
- Zookeeper 集群⼯作的核⼼⻆⾊
- 集群内部各个服务器的调度者
- 事务请求(写操作) 的唯⼀调度和处理者,保证集群事务处理的顺序性;对于 createsetData, delete 等有写操作的请求,则需要统⼀转发给leader 处理, leader 需要决定编号、执⾏操作,这个过程称为⼀个事务
- Follower的作用:
- 处理客户端⾮事务(读操作) 请求,
- 转发事务请求给 Leader
- 参与集群 Leader 选举投票 2n-1台可以做集群投票
- Observer的作用
- Observer是观察者⻆⾊,观察 Zookeeper 集群的最新状态变化并将这些状态同步过来,其对于⾮事务请求可以进⾏ᇿ⽴处理,对于事务请求,则会转发给 Leader服务器进⾏处理。
- Observer不会参与任何形式的投票只提供⾮事务服务,通常⽤于在不影响集群事务处理能⼒的前提下提升集群的⾮事务处理能⼒。增加了集群增加并发的读请求。
- ZK也是Master/slave架构,但是与之前不同的是zk集群中的Leader不是指定⽽来,⽽是通过选举产⽣
Zookeeper 特点
- Zookeeper:⼀个leader:,多个跟随者(follower)组成的集群。
- Leader负责进⾏投票的发起和决议,更新系统状态(内部原理)
- Follower⽤于接收客户请求并向客户端返回结果,在选举Leader过程中参与投票
- 集群中只要有半数以上节点存活,Zookeeper集群就能正常服务。
- 全局数据⼀致:每个server保存⼀份相同的数据副本,Client⽆论连接到哪个server,数据都是⼀致的。
- 更新请求顺序进⾏(内部原理)
- 数据更新原⼦性,⼀次数据更新要么成功,要么失败。
ZooKeeper数据模型Znode
- 在ZooKeeper中,数据信息被保存在⼀个个数据节点上,这些节点被称为znode。
- ZNode 是Zookeeper 中最⼩数据单位,在 ZNode 下⾯⼜可以再挂 ZNode,这样⼀层层下去就形成了⼀个层次化命名空间 ZNode 树,我们称为 ZNode Tree,
- ZNode Tree采⽤了类似⽂件系统的层级树状结构进⾏管理。
- 在 Zookeeper 中,每⼀个数据节点都是⼀个 ZNode,上图根⽬录下有两个节点,分别是:app1 和app2,其中 app1 下⾯⼜有三个⼦节点,所有ZNode按层次化进⾏组织,形成ZNode Tree。
- ZNode的节点路径标识⽅式和Unix⽂件系统路径⾮常相似,都是由⼀系列使⽤斜杠(/)进⾏分割的路径表示,既可以向这个节点写⼊数据,也可以在这个节点下⾯创建⼦节点
ZNode 的类型
- Zookeeper的znode tree是由⼀系列数据节点组成的。
- Zookeeper 节点类型可以分为三⼤类:持久性节点(Persistent),临时性节点(Ephemeral)和临时性节点(Ephemeral)。
- 在创建节点的时候通过组合可以⽣成以下四种节点类型:持久节点、持久顺序节点、临时节点、临时顺序节点。不同类型的节点则会有不同的⽣命周期。
- 持久节点:是Zookeeper中最常⻅的⼀种节点类型,所谓持久节点,就是指节点被创建后会⼀直存在服务器,直到删除操作主动清除。
- 持久顺序节点:就是有顺序的持久节点,节点特性和持久节点是⼀样的,只是额外特性表现在顺序上。顺序特性实质是在创建节点的时候,会在节点名后⾯加上⼀个数字后缀,来表示其顺序。
- 临时节点:就是会被⾃动清理掉的节点,它的⽣命周期和客户端会话绑在⼀起,客户端会话结束,节点会被删除掉。与持久性节点不同的是,临时节点不能创建⼦节点。
- 临时顺序节点:就是有顺序的临时节点,和持久顺序节点相同,在其创建的时候会在名字后⾯加上数字后缀。
ZooKeeper事务ID
- 事务是对物理和抽象的应⽤状态上的操作集合。往往在现在的概念中,狭义上的事务通常指的是数据库事务,⼀般包含了⼀系列对数据库有序的读写操作,
- 数据库事务具有所谓的ACID特性,即原⼦性(Atomic)、⼀致性(Consistency)、隔离性(Isolation)和持久性(Durability)。
- 在ZooKeeper中,事务是指能够改变ZooKeeper服务器状态的操作,我们也称之为事务操作或更新操作,⼀般包括数据节点创建与删除、数据节点内容更新等操作。
- 。对于每⼀个事务请求,ZooKeeper都会为其分配⼀个全局唯⼀的事务ID,⽤ ZXID 来表示,通常是⼀个 64 位的数字。
- 每⼀个 ZXID 对应⼀次更新操作,从这些ZXID中可以间接地识别出ZooKeeper处理这些更新操作请求的全局顺序
- zk中的事务指的是对zk服务器状态改变的操作(create,update data,更新字节点);zk对这些事务操作都会编号,这个编号是⾃增⻓的被称为ZXID。
ZNode的状态信息
-
get /zookeeper得到状态信息
cZxid = 0x0 ctime = Wed Dec 31 19:00:00 EST 1969 mZxid = 0x0 mtime = Wed Dec 31 19:00:00 EST 1969 pZxid = 0x0 cversion = -1 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 0 numChildren = 1
-
整个 ZNode 节点内容包括两部分:节点数据内容和节点状态信息。数据内容是空,其他的属于状态信息。
cZxid 就是 Create ZXID,表示节点被创建时的事务ID。 ctime 就是 Create Time,表示节点创建时间。 mZxid 就是 Modified ZXID,表示节点最后⼀次被修改时的事务ID。 mtime 就是 Modified Time,表示节点最后⼀次被修改的时间。 pZxid 表示该节点的⼦节点列表最后⼀次被修改时的事务 ID。只有⼦节点列表变更才会更新 pZxid,⼦节点内容变更不会更新。 cversion 表示⼦节点的版本号。 dataVersion 表示内容版本号。 aclVersion 标识acl版本 ephemeralOwner 表示创建该临时节点时的会话 sessionID,如果是持久性节点那么值为 0 dataLength 表示数据⻓度。 numChildren 表示直系⼦节点数。
Zookeeper的Watcher 机制
- Zookeeper使⽤Watcher机制实现分布式数据的发布/订阅功能
- ⼀个典型的发布/订阅模型系统定义了⼀种 ⼀对多的订阅关系,能够让多个订阅者同时监听某⼀个主题对象,当这个主题对象⾃身状态变化时,会通知所有订阅者,使它们能够做出相应的处理。
- 在 ZooKeeper 中,引⼊了 Watcher 机制来实现这种分布式的通知功能。
- ZooKeeper 允许客户端向服务端注册⼀个 Watcher 监听,当服务端的⼀些指定事件触发了这个 Watcher,那么Zk就会向指定客户端发送⼀个事件通知来实现分布式的通知功能
- Watcher注册与通知过程如图所示:
- Zookeeper的Watcher机制主要包括客户端线程、客户端WatcherManager、Zookeeper服务器三部分,具体工作流程为:
- 客户端在向Zookeeper服务器注册的同时,会将Watcher对象存储在客户端的WatcherManager当中
- 当Zookeeper服务器触发Watcher事件后,会向客户端发送通知
- 客户端线程从WatcherManager中取出对应的Watcher对象来执⾏回调逻辑
以上是关于分布式协调服务框架——Zookeeper的主要内容,如果未能解决你的问题,请参考以下文章
Zookeeper 详细解析!分布式架构中的协调服务框架的最佳选型