标签:状态 block cimage 消息 设置 生命周期 分享图片 通过 手动
Zookeeper作为一个分布式协调系统提供了一项基本服务:分布式锁服务,分布式锁是分布式协调技术实现的核心内容。像配置管理、任务分发、组服务、分布式消息队列、分布式通知/协调等,这些应用实际上都是基于这项基础服务由用户自己摸索出来的。
zookeeper作为分布式协调系统在大数据领域非常常用,它是一个很好的中心化管理工具。下面举几个常见的应用场景。
ZooKeeper命名空间中的Znode,兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构,又像目录一样可以作为路径标识的一部分。 每个Znode由3部分组成:
ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据,写操作也将替换掉节点的所有数据。另外,每一个节点都拥有自己的ACL(访问控制列表),这个列表规定了用户的权限,即限定了特定用户对目标节点可以执行的操作。
ZooKeeper可以为所有的读操作设置watch,包括:exists()、getChildren()及getData()。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时,ZooKeeper将会向客户端发送且仅发送一条通知,因为watch只能被触发一次,这样可以减少网络流量。
ZooKeeper中的节点有两种,分别为临时节点和永久节点(还可再分为有序无序)。节点的类型在创建时即被确定,并且不能改变。
两种方式:
存储集群元数据提供给client使用,体现在比如需要对HBase和Kafka操作时,都会直接连到zookeeper,zookeeper记录了数据存储的位置,存活的节点等元数据信息。
Master要监视/works和/tasks两个永久节点,以便能感知到由哪些slave当前可用,当前有新任务需要分配。
分配过程:在/assign下创建当前可用的workA,找到需要分配的taskA,创建/assign/workA/taskA
zookeeper还有很多类似的应用大多都是基于上面的特性。总的来说,zk只是一个提供了一些特性的系统,用户根据这些特性自己定义了它的用法。熟悉了zk的操作以及应用场景,下一篇说下zk的架构设计与角色分工。
评论不能及时回复可直接加公众号提问或交流,知无不答,谢谢 。
标签:状态 block cimage 消息 设置 生命周期 分享图片 通过 手动
原文地址:http://blog.51cto.com/9587671/2318187