zookeeper使用和原理探究

转：http://www.blogjava.net/BucketLi/archive/2010/12/21/341268.html

zookeeper介绍
zookeeper是一个为分布式应用提供一致性服务的软件，它是开源的Hadoop项目中的一个子项目，而且根据google发表的<The Chubby lock service for loosely-coupled distributed systems>论文来实现的，接下来咱们首先来安装使用下这个软件，而后再来探索下其中比较重要一致性算法。  

zookeeper安装和使用
zookeeper的安装基本上能够按照 http://hadoop.apache.org/zookeeper/docs/current/ zookeeperStarted.html 这个页面上的步骤完成安装，这里主要介绍下部署一个集群的步骤，由于这个官方页面彷佛讲得并非很是详细(Running Replicated Zookeeper)。

因为手头机器不足，因此在一台机器上部署了3个server,若是你手头也比较紧，也能够这么作。那么我建了3个文件夹，以下
server1   server2   server3

而后每一个文件夹里面解压一个zookeeper的下载包，而且还建了几个文件夹，整体结构以下,最后那个是下载过来压缩包的解压文件
data dataLog logs zookeeper-3.3.2

那么首先进入data目录，建立一个myid的文件，里面写入一个数字，好比我这个是server1,那么就写一个1，server2对应myid文件就写入2，server3对应myid文件就写个3

而后进入zookeeper-3.3.2/conf目录，那么若是是刚下过来，会有3个文件，configuration.xml, log4j.properties,zoo_sample.cfg,这3个文件咱们首先要作的就是在这个目录建立一个zoo.cfg的配置文件，固然你能够把zoo_sample.cfg文件改为zoo.cfg，配置的内容以下所示： 
tickTime=2000
initLimit=5
syncLimit=2
dataDir=xxxx/zookeeper/server1/data
dataLogDir=xxx/zookeeper/server1/dataLog
clientPort=2181
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890

标红的几个配置应该官网讲得很清楚了，只是须要注意的是clientPort这个端口若是你是在1台机器上部署多个server,那么每台机器都要不一样的clientPort，好比我server1是2181,server2是2182，server3是2183，dataDir和dataLogDir也须要区分下。

最后几行惟一须要注意的地方就是 server.X 这个数字就是对应 data/myid中的数字。你在3个server的myid文件中分别写入了1，2，3，那么每一个server中的zoo.cfg都配server.1,server.2,server.3就OK了。由于在同一台机器上，后面连着的2个端口3个server都不要同样，不然端口冲突，其中第一个端口用来集群成员的信息交换，第二个端口是在leader挂掉时专门用来进行选举leader所用。

进入zookeeper-3.3.2/bin 目录中，./zkServer.sh start启动一个server,这时会报大量错误？其实没什么关系，由于如今集群只起了1台server，zookeeper服务器端起来会根据zoo.cfg的服务器列表发起选举leader的请求，由于连不上其余机器而报错，那么当咱们起第二个zookeeper实例后，leader将会被选出，从而一致性服务开始可使用，这是由于3台机器只要有2台可用就能够选出leader而且对外提供服务(2n+1台机器，能够容n台机器挂掉)。

接下来就可使用了，咱们能够先经过 zookeeper自带的客户端交互程序来简单感觉下zookeeper到底作一些什么事情。进入zookeeper-3.3.2/bin（3个server中任意一个）下，./zkCli.sh –server 127.0.0.1:2182,我连的是开着2182端口的机器。

那么，首先咱们随便打个命令，由于zookeeper不认识，他会给出命令的help,以下图  
  
ls(查看当前节点数据),
ls2(查看当前节点数据并能看到更新次数等数据) ,
create(建立一个节点) ,
get(获得一个节点，包含数据和更新次数等数据),
set(修改节点)
delete(删除一个节点)

经过上述命令实践，咱们能够发现，zookeeper使用了一个相似文件系统的树结构，数据能够挂在某个节点上，能够对这个节点进行删改。另外咱们还发现，当改动一个节点的时候，集群中活着的机器都会更新到一致的数据。

zookeeper的数据模型
在简单使用了zookeeper以后，咱们发现其数据模型有些像操做系统的文件结构，结构以下图所示



(1)     每一个节点在zookeeper中叫作znode,而且其有一个惟一的路径标识，如/SERVER2节点的标识就为/APP3/SERVER2
(2)     Znode能够有子znode，而且znode里能够存数据，可是EPHEMERAL类型的节点不能有子节点
(3)     Znode中的数据能够有多个版本，好比某一个路径下存有多个数据版本，那么查询这个路径下的数据就须要带上版本。
(4)     znode 能够是临时节点，一旦建立这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通讯采用长链接方式，每一个客户端和  服务器经过心跳来保持链接，这个链接状态称为 session，若是 znode 是临时节点，这个 session 失效，znode 也就删除了
(5)     znode 的目录名能够自动编号，如 App1 已经存在，再建立的话，将会自动命名为 App2 
(6)     znode 能够被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化能够通知设置监控的客户端，这个功能是zookeeper对于应用最重要的特性，经过这个特性能够实现的功能包括配置的集中管理，集群管理，分布式锁等等。 

经过java代码使用zookeeper 
Zookeeper的使用主要是经过建立其jar包下的Zookeeper实例，而且调用其接口方法进行的，主要的操做就是对znode的增删改操做，监听znode的变化以及处理。 

如下为主要的API使用和解释

//建立一个Zookeeper实例，第一个参数为目标服务器地址和端口，第二个参数为Session超时时间，第三个为节点变化时的回调方法
ZooKeeper zk = new ZooKeeper("127.0.0.1:2181", 500000,new Watcher() {
           // 监控全部被触发的事件
             public void process(WatchedEvent event) {
           //dosomething
           }
      });
//建立一个节点root，数据是mydata,不进行ACL权限控制，节点为永久性的(即客户端shutdown了也不会消失)
zk.create("/root", "mydata".getBytes(),Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);

//在root下面建立一个childone znode,数据为childone,不进行ACL权限控制，节点为永久性的
zk.create("/root/childone","childone".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.PERSISTENT);

//取得/root节点下的子节点名称,返回List<String>
zk.getChildren("/root",true);

//取得/root/childone节点下的数据,返回byte[]
zk.getData("/root/childone", true, null);

//修改节点/root/childone下的数据，第三个参数为版本，若是是-1，那会无视被修改的数据版本，直接改掉
zk.setData("/root/childone","childonemodify".getBytes(), -1);

//删除/root/childone这个节点，第二个参数为版本，－1的话直接删除，无视版本
zk.delete("/root/childone", -1);
      
//关闭session
zk.close();

 
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类型，这样每一个节点会自动被编号，例如          

zk.create("/testRootPath/testChildPath1","1".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
        
zk.create("/testRootPath/testChildPath2","2".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
        
zk.create("/testRootPath/testChildPath3","3".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
        
// 建立一个子目录节点
zk.create("/testRootPath/testChildPath4","4".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);

System.out.println(zk.getChildren("/testRootPath", false));

 打印结果：[testChildPath10000000000, testChildPath20000000001, testChildPath40000000003, testChildPath30000000002]

zk.create("/testRootPath", "testRootData".getBytes(),Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);

// 建立一个子目录节点
zk.create("/testRootPath/testChildPath1","1".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
        
zk.create("/testRootPath/testChildPath2","2".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
        
zk.create("/testRootPath/testChildPath3","3".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
        
// 建立一个子目录节点
zk.create("/testRootPath/testChildPath4","4".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);

System.out.println(zk.getChildren("/testRootPath", false));

打印结果:[testChildPath2, testChildPath1, testChildPath4, testChildPath3]

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


总结 

咱们初步使用了一下zookeeper而且尝试着描述了几种应用场景的具体实现思路，接下来的文章，咱们会尝试着去探究一下zookeeper的高可用性与leaderElection算法。

参考：http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/

      http://hadoop.apache.org/zookeeper/docs/current/

      http://rdc.taobao.com/team/jm/archives/448