zookeeper之场景与架构-《每日五分钟搞定大数据》

zookeeper之场景与架构-《每日五分钟搞定大数据》

Zookeeper作为一个分布式协调系统提供了一项基本服务:分布式锁服务,分布式锁是分布式协调技术实现的核心内容。像配置管理、任务分发、组服务、分布式消息队列、分布式通知/协调等,这些应用实际上都是基于这项基础服务由用户自己摸索出来的。

1.Zookeeper在大数据系统中的常见应用

zookeeper作为分布式协调系统在大数据领域非常常用,它是一个很好的中心化管理工具。下面举几个常见的应用场景。

1.1.HDFS/YARN

HA(分布式锁的应用):Master挂掉之后迅速切换到slave节点。

1.2.hbase

HA :同上。

配置管理 :client需要读写hbase的数据首先都是连到ZK读取root表,获得meta表所在的region,最后找到数据所在位置。

任务发布:regionserver挂了一台,master需要重新分配region,会把任务放在zookeeper等regionserver来获取

1.3.kafka

配置管理:broker会在zookeeper注册并保持相关的元数据(topic,partition信息等)更新

任务分配:给topic分配partitions和replication

2.Zookeeper有哪些操作特性 2.1.数据结构

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

stat状态信息:描述该Znode的版本, 权限等信息

data:与该Znode关联的数据(配置文件信息、状态信息、汇集位置),数据大小至多1M

children:该Znode下的子节点

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

2.2.watch机制

ZooKeeper可以为所有的读操作设置watch,包括:exists()、getChildren()及getData()。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时,ZooKeeper将会向客户端发送且仅发送一条通知,因为watch只能被触发一次,这样可以减少网络流量。

数据watch(data watches):getData和exists负责设置数据watch

孩子watch(child watches):getChildren负责设置孩子watch

2.3.节点类型 ZooKeeper中的节点有两种,分别为临时节点和永久节点(还可再分为有序无序)。节点的类型在创建时即被确定,并且不能改变。

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

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

3.这些应用是如何通过这些特性实现的 3.1.HA:

两种方式:

创建两个或多个有序临时节点,永远把最小值当做master

创建临时节点的为master,多个slave会watch这个节点

3.2.配置管理:

存储集群元数据提供给client使用,体现在比如需要对HBase和Kafka操作时,都会直接连到zookeeper,zookeeper记录了数据存储的位置,存活的节点等元数据信息。

3.3.任务发布:

Master要监视/works和/tasks两个永久节点,以便能感知到由哪些slave当前可用,当前有新任务需要分配。
分配过程:在/assign下创建当前可用的workA,找到需要分配的taskA,创建/assign/workA/taskA

4.zookeeper架构设计

  zookeeper作为一个分布式协调系统,很多组件都会依赖它,那么此时它的可用性就非常重要了,那么保证可用性的同时作为分布式系统的它是怎么保证扩展性的?问题很多,读完接下来的内容你会有答案。

  上图来自zookeeper的官方文档,我解释下这张图的各个角色(observer在上图中可以理解为特殊的follower)

角色 分工 数量
client客户端   请求发起方   不限  
observer观察者   接受用户读写请求,写转发给leader,读直接返回(选主过程不参加投票)   不限  
follower跟随者   接受用户读写请求,写转发给leader,读直接返回(选主过程参加投票)   奇数个(不可过多)  
leader领导者   负责提议,更新系统状态   1个  

另外:follower和observer同时均为learner(学习者)角色,learner的分工是同步leader的状态。

5.zookeeper的读写

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpxjjz.html