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则会得到节点变更通知，则发起新一轮的获取锁的流程。