zookeeper的应用

zookeeper的应用

上一篇文章《分布式系统---分布式一致性协议》http://blog.csdn.net/beginning1126/article/details/52901547中,主要阐述了paxos和zab协议,阐明zookeeper的工作原理。下面主要来聊聊zookeeper在实际生产环境中,能帮助我们做哪些事情。

zookeeper特性

目前很多大型的开源项目都在使用zookeeper,包括hadoop、hbase、kafka等。其对zookeeper的使用主要还是根据zookeeper的若干特性。特性总结如下:

  1. 节点可以存储少量信息,无论是永久节点还是临时节点,都可以存储少量信息,默认情况下,单个node可以存储小于1M的数据。zookeeper的数据是存储在内存里面的,同时也会持久化到磁盘上,一旦zookeeper crash重启,会从磁盘上读取数据恢复内存数据。依据zookeeper这个特性,实际生产环境,会将一些元数据、状态信息、索引信息等数据量小,并且经常变动的信息保存在zookeeper上。
  2. 临时节点,zk client通过tcp连接与zookeeper保持长连接,zk client在zookeeper上创建临时节点,一旦zk client网络故障或者crash,zookeeper上的临时节点都会自动删除,依据此特性,zookeeper常用于集群死活监控
  3. node事件触发,zk client可以在node上注册事件,一旦node发生变化,zookeeper会及时触发event,zk client会及时感知到。依据此特性,可以通过zookeeper完成发布、订阅功能
  4. 节点唯一创建,如果多个client同时往zookeeper上创建同一个node,只能有一个client创建成功。依据此特性,可以完成master-slave-slave master选举、分布式锁等功能
  5. 顺序节点,我们可以在zookeeper一个节点下,创建顺序节点,每个节点都会有个序号,这些序号依次递增,不会重复。依据此特性,可以为每个client生成全局唯一标识。

zookeeper的具体应用

下面结合一些具体例子,再详细阐述一下zookeeper的应用

配置管理中心

在实际生产环境上,每个服务器,都会在本地保存一个配置文件,当集群规模比较小的情况下,每次系统升级,配置变更,可以通过运维人员手工修改,但是一旦规模增大,维护成本将大大提升。

配置管理中心,则是为了解决如上问题提出的,当然它也有局限性,比较适合维护那些在多个服务器上配置文件大体相同,只有若干项不同(比如serverid,serverip等)。如果各个服务器上配置文件千奇百怪,毫无规则可言,配置管理中心就无能为力了。

配置管理中心的大体架构为:配置变更模块----zookeeper集群----集群服务器

配置变更模块可以有多个,一般情况都会提供一个web前端页面,供配置人员修改配置。

工作流程如下:

  1. 在zookeeper集群上创建配置节点cfg_node
  2. 服务器启动起来之后,先到cfg_node上读取配置信息,同时注册数据变更的watcher监听,
  3. 一旦节点数据发生变化,所有订阅的client都会得到变更通知,再重新获取一次配置信息

全局唯一id

在zookeeper中,每一个数据节点都能够维护一份顺序子节点,当client对其创建顺序子节点时,zookeeper会自动以后缀的形式在其子节点上添加一个序号,client就可以用这个节点名称作为全局唯一id

集群管理

集群的管理主要有如下几个方面

  1. 集群机器的死活监控,最简单发方法就是为每个机器创建一个临时节点,一旦机器crash,则zookeeper会删除临时节点。管理系统监控其父节点,则会得到子节点变更的通知。
  2. 集群机器数量的统计,通过父节点,则可以统计出子节点的数量
  3. 集群机器状态的获取,每个集群服务,创建临时节点之后,将其状态信息周期写入其对应的节点,管理系统读取节点data,则可以获取其状态信息。

master选举

多个client master选举,多个client同时向zookeeper创建同一个临时节点node,只能有一个client能创建成功,那么这个client则成为master,其它client需要在其父节点注册一个子节点变更的watcher,用于监控当前master机器是否存活,一旦发现当前master挂了,那么其余client会重新进行master选举。

但是这个过程有个漏洞,比如现在有个2个client竞争master,分别为client1和client2,client1先竞争为master,如果client1由于网络闪断或负载过高(常见cpu过载),则会导致其创建的临时节点删除掉,导致client2变成了master,但是一旦client1网络突然又好了,它是不知道这个时候它client2已经成为master,这种情况就为造成系统里有2个master,这个就是我们常说的脑裂现象,即存在多个active状态的节点各司其职。解决这个问题的方法其实也很简单,借助zookeeper节点的ACL权限控制机制。client自己创建的节点,设定其权限,其它client是没有权限往此节点更新状态数据的,一旦client1更新状态时,发现其已经么有权限了,这就说明这个节点已经不是自己创建的了,直接将自己的身份降为slave则可。

分布式锁

获取锁:比如有多个client想获取锁,可以同时创建临时节点lock,当然只能有一个client能创建成功,它就获取到了锁。其它client监听这个lock节点变更

释放锁:当获取锁的client crash,其临时节点会自动删除,或业务执行完成主动删除临时节点,则其释放了锁。其它client则会得到节点变更通知,则发起新一轮的获取锁的流程。

你可能感兴趣的:(分布式系统,zookeeper,分布式)