ZooKeeper 初探

本文简单介绍了ZooKeeper，并使用实例案例在本地环境快速搭建ZooKeeper环境，基本内容包括：

- zookeeper的单机模式(standalone mode) 和 集群模式(replicated mode)

- Java binding 的使用

- 应用场景

基本介绍

ZooKeeper是一个协调分布式应用的框架, 它是开源的Hadoop项目中的一个子项目。

安装和使用

单机模式的安装还是比较简单直接的，详情可以参考zookeeper的官网http://zookeeper.apache.org/doc/current/zookeeperStarted.html

官网对集群模式介绍的不是很清楚，所以引用了另外一篇博文来介绍集群http://www.blogjava.net/BucketLi/archive/2010/12/21/341268.html，另附上项目生产环境上的zookeeper集群配置：

对于集群模式，其中有个概念 - quorum 我觉得有必要拿出来仔细研究下，参见http://blog.csdn.net/turkeyzhou/article/details/9307551，其实我的理解就是Quorum机制是来解决读写模型中读写的负载均衡，把 Write 身上的部分负载转移到了Read上。

通过Java代码使用ZooKeeper

ZooKeeper有Java版本和C语言版本，下文介绍了Java binding 的方式。

1. 在Eclipse里面创建新的Java Project。

2. 从官网（http://zookeeper.apache.org/doc/current/zookeeperStarted.html）下载zookeeper的jar包，并引入Project。

3. 创建Java类，调用其接口方法，主要的操作就是对znode的增删改操作，监听znode的变化以及处理。以下为我自己编写的测试程序：

package com.ibm.zookeeper;

import java.io.IOException;

import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.KeeperException;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.ZooDefs.Ids;
import org.apache.zookeeper.ZooKeeper;

public class TestZookeeper {

	public static void main(String[] args) throws IOException, KeeperException, InterruptedException {
		// 创建一个Zookeeper实例，第一个参数为目标服务器地址和端口，第二个参数为Session超时时间，第三个为节点变化时的回调方法
		ZooKeeper zk = new ZooKeeper("127.0.0.1:2181", 500000, new Watcher() {
			// 监控所有被触发的事件
			public void process(WatchedEvent event) {
				// dosomething
				System.out.println("节点变化了！！！");
			}
		});
		
		// 在/下面创建一个app1 znode,数据为app1_data,不进行ACL权限控制，节点为永久性的
		zk.create("/app1", "app1_data".getBytes(), Ids.OPEN_ACL_UNSAFE,
				CreateMode.PERSISTENT);
		
		// 取得/节点下的子节点名称,返回List<String>
		zk.getChildren("/", true);
		
		// 取得/app1节点下的数据,返回byte[]
		zk.getData("/app1", true, null);
		
		// 删除/app1这个节点，第二个参数为版本，－1的话直接删除，无视版本
		zk.delete("/app1", -1);
		
		// 关闭session
		zk.close();
	}

}

4. 可以使用Eclipse的zookeeper插件来观察集群zookeeper服务器之间的同步。

Zookeeper的主流应用场景实现思路

1. 配置管理
集中式的配置管理在应用集群中是非常常见的，一般商业公司内部都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。

Zookeeper很容易实现这种集中式的配置管理，比如将APP1的所有配置配置到/APP1 znode下，APP1所有机器一启动就对/APP1这个节点进行监控(zk.exist("/APP1",true)),并且实现回调方法Watcher，那么在zookeeper上/APP1 znode节点下数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可(zk.getData("/APP1",false,null));

以上这个例子只是简单的粗颗粒度配置监控，细颗粒度的数据可以进行分层级监控，这一切都是可以设计和控制的。

2. 集群管理
应用集群中，我们常常需要让每一个机器知道集群中（或依赖的其他某一个集群）哪些机器是活着的，并且在集群机器因为宕机，网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。

Zookeeper同样很容易实现这个功能，比如我在zookeeper服务器端有一个znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点，比如server1创建/APP1SERVERS/SERVER1(可以使用ip,保证不重复)，server2创建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch /APP1SERVERS这个父节点，那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行watch的客户端。因为EPHEMERAL类型节点有一个很重要的特性，就是客户端和服务器端连接断掉或者session过期就会使节点消失，那么在某一个机器挂掉或者断链的时候，其对应的节点就会消失，然后集群中所有对/APP1SERVERS进行watch的客户端都会收到通知，然后取得最新列表即可。

另外有一个应用场景就是集群选master,一旦master挂掉能够马上能从slave中选出一个master,实现步骤和前者一样，只是机器在启动的时候在APP1SERVERS创建的节点类型变为EPHEMERAL_SEQUENTIAL类型，这样每个节点会自动被编号。

我们默认规定编号最小的为master,所以当我们对/APP1SERVERS节点做监控的时候，得到服务器列表，只要所有集群机器逻辑认为最小编号节点为master，那么master就被选出，而这个master宕机的时候，相应的znode会消失，然后新的服务器列表就被推送到客户端，然后每个节点逻辑认为最小编号节点为master，这样就做到动态master选举。