zookeeper

本文深入探讨Zookeeper作为分布式协调服务的原理与应用场景,包括数据发布/订阅、命名服务、分布式协调/通知、分布式锁及分布式队列,揭示Zookeeper如何解决分布式系统中的一致性和数据管理难题。
摘要由CSDN通过智能技术生成

Zookeeper的概述:
zookeeper是一个开源的分布式协调服务框架,主要用来解决分布式集群中应用系统的一致性问题和数据管理问题
zookeeper的特点
zookeeper本质上是一个分布式文件系统,适合存放小文件,也可以理解为一个数据库

在这里插入图片描述
如上图可知,zookeeper中存储的其实是一个又一个znode,znode是zookeeper中的节点
znode是有路径的,例如/data/host1 , /data/host2,这个路径也可以理解为是znode的name
znode也可以携带数据,例如说某个znode的路径是/data/host1,其值是一个字符串"192.168.0.1"
正因为znode的特性,所以zookeeper可以对外提供出一个类似于文件系统的视图,可以通过操作文件系统的方式操作zookeeper
使用路径获取znode
获取znode携带的数据
修改znode携带的数据
删除znode
添加znode
Zookeeper的应用场景
1.数据发布/订阅
数据发布/订阅系统,需要发布者将数据发布到zookeeper的节点上,供订阅者进行数据订阅,进而达到动态获取数据的目的,实现配置信息的集中式管理和数据的动态更新.
发布/订阅一般有两种设计模式:推模式和拉模式
推模式:服务端主动将数据更新发送给所有订阅的客户端称为推模式(如dubbox的服务生成者)
拉模式:客户端主动请求获取最新数据称为拉模式(如dubbox的服务消费者)
zookeeper采用了推拉相结合的模式,客户端向服务端注册自己需要关注的节点,一旦该节点数据发生变更,那么服务端就会向相应的客户端推送Watcher时间通知,客户端接收到此通知后,主动到服务端获取最新的数据.
2.命名服务
命名服务是分步实现系统中较为常见的一类场景,分布式系统中,被命名的实体通常可以是集群中的机器,提供的服务地址或远程对象等,
通过命名服务,客户端可以根据指定名字来获取资源的实体,在分布式环境中,上层应用仅仅需要一个全局唯一的名字.zookeeper可以实现一套分布式全局唯一ID的分配机制.
在这里插入图片描述
通过调用zookeeper节点创建的api接口就可以创建一个顺序节点,并且在api返回值中会返回这个节点的完整名字,利用此特性,可以生成全局ID,其步骤如下:
1.客户端根据任务类型,在指定类型的任务下通过调用接口创建一个顺序节点,如"job"。
2.创建完成后,会返回一个完整的节点名,如"job-00000001"。
3. 客户端拼接type类型和返回值后,就可以作为全局唯一ID了,如"type2-job-00000001"。
3.分布式协调/通知
zookeeper中特有的watcher注册于异步通知机制,能够很好的实现分布式环境下不同机器,甚至不同系统之间的协调与通知,从而实现对数据变更的实时处理.
通常的做法是不同的客户端都对zookeeper上的同一个数据节点进行watcher注册,监听数据节点的变化(包括节点本身和子节点),若数据节点发生变化,那么所有订阅
的客户端都能够接受到相应的watcher通知,并作出相应处理.
在绝大多数分布式系统中,系统机器间的通信无外乎心跳检测,工作进行汇报和系统调度.
①心跳检测,不同机器间需要检测到彼此是否在正常运行,可以使用zookeeper实现机器间的心跳检测,基于其临时节点特性(临时节点的生存周期是客户端会话,客户端若断开后,其临时节点自然不再存在),可以让不同机器都在zookeeper的一个指定节点下创建临时子节点,不同的机器之间可以根据这个临时子节点来判断对应的客户端机器是否存活.通过zookeeper可以大大减少系统耦合.
②工作进度汇报,通常任务被分发到不同机器后,需要实时地将自己的任务执行进度汇报给分发系统,可以在zookeeper上选择一个节点,每个任务客户端都在这个节点下面创建临时子节点.这样不仅可以判断机器是否存活,同时各个机器可以将自己的任务执行进度写到该临时节点中去,以便中心系统能够实时获取任务的执行进度.
③系统调度,zookeeper能够实现如下系统调度模式:分布式系统由控制台和一些客户端系统两部分构成,控制台的职责就是需要将一些指令信息发送给所有的客户端,以控制他们进行相应的业务逻辑,后台管理人员在控制台上做一些操作,实际上就是修改zookeeper上某些节点的数据,zookeeper可以把数据变更以时间通知的形式发送给订阅客户端.
4.分布式锁
分布式锁用于控制分布式系统之间同步访问共享资源的一种方式,可以保证不同系统访问一个或者一组资源时的一致性,主要分为排它锁和共享锁.
排它锁又称写锁或独占锁,若事务T1对数据对象O1加上了排它锁,那么在整个加锁期间,只允许事务T1对O1进行读取和更新操作,其他任何事务都不能再对这个数据对象进行任何类型的操作,直到T1释放了排它锁.
在这里插入图片描述
①获取锁,在需要获取排它锁时,所有客户端通过调用接口,在/exclusive_lock节点下创建 临时子节点/exclusive_lock/lock。zookeeper可以保证只有一个客户端能够创建成功,没有成功的客户端需要注册/exclusive_lock节点监听.
②释放锁,当获取锁的客户端断开或者正常完成业务逻辑都会导致临时节点的删除,此时,所有在/exclusive_lock节点上注册监听的客户端都会收到通知,可以重新发起分布式锁获取.
共享锁又称读锁,若事务T1对数据对象O1加上共享锁,那么当前事务只能对O1进行读取操作,其他事务也只能对这个数据对象加共享锁,直到该数据对象上的所有共享锁都被释放.在需要获取共享锁时,所有客户端都会到/shared_lock下面创建一个临时顺序节点
在这里插入图片描述
5.分布式队列
有一些时候,多个团队需要共同完成一个任务,比如,A团队将hadoop集群计算的结果交给B团队继续计算,B完成了自己任务再交给C团队继续做.这就有点像业务系统的工作流一样,一环一环地传下去.
分布式环境下,我们同样需要一个类似单进程队列的组件,用来实现跨进程,跨主机,跨网络的数据共享和数据传递,这就是我们的分布式队列

Zookeeper集群是一个基于主从架构的高可用集群
每个服务器承担如下三种角色中的一种
Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader,它会发起并维护与各 Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广 播给其它服务器。
Follower 一个Zookeeper集群可能同时存在多个Follower,它会响应Leader的心跳。 Follower可直接处理并返回客户端的读请求,同时会将写请求转发给Leader处理,并且负 责在Leader处理写请求时对请求进行投票。
Observer 角色与Follower类似,但是无投票权。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值