zookeeper系列之一—zookeeper入门

Zookeeper是什么？

Zookeeper故名思议动物管理员，它是拿来管大象（Hadoop）、蜜蜂（Hive）、小猪（Pig）的管理员，Apache Hbase和Apache Solr以及LinkedIn sensei等项目都采用到了Zookeeper。Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，Zookeeper是以Fast Paxos算法为基础，实现同步服务，配置维护和命名服务等分布式应用。

Zookeeper如何工作？

Zookeeper是作为分布式应用建立更高层次的同步（synchronization）、配置管理（configuration maintenance）、群组（groups）以及名称服务（naming）。在变成上，Zookeeper设计很简单，所使用的数据模型风格很像文件系统的目录结构，简单来说，有点类似windows中注册表的结构，有名称，有树节点，有key（键）/Value（值）对的关系，可以看做一个树形结构的数据库，分布在不同的机器上做名称管理。

Zookeeper分为2个部分：服务器端和客户端，客户端只连接到整个Zookeeper服务的某个服务器上。客户端使用并维护一个TCP连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个TCP连接中断，客户端将尝试连接到另外的Zookeeper服务器。客户端第一次连接到Zookeeper服务时，接受这个连接的Zookeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。

启动Zookeeper服务器集群环境后，多个Zookeeper服务器在工作前会选举出一个Leader，在接下来的工作中这个被选举出来的Leader死了，而剩下的Zookeeper服务器会知道这个Leader死掉了，在或者的Zookeeper集群中会继续选出一个Leader，选举出leader的目的是为了可以在分布式的环境中保证数据的一致性。

另外，Zookeeper支持watch（观察）的概念。客户端可以在每个znode节点上设置一个观察。如果被观察服务端的zonde节点有变更，那么watch就会被触发，这个watch所属的客户端将接收到一个通知包被告知节点已经发生变化。若客户端和所连接的Zookeeper服务器断开连接时，其他客户端也会受到一个通知，也就说一个Zookeeper服务器端可以对于多个客户端，当然也可以多个Zookeeper服务器端可以对于多个客户端。你还可以通过命令查看出，当前哪个Zookeeper服务端的节点是Leader，哪个是Follower。

我通过试验观察到Zookeeper的集群环境最好有3台以上的节点，如果只有2台，那么2台种种不管哪台机器down掉，将只剩下一个leader，那么如果再有客户端连接上来，将无法工作，并且剩下的leader服务器会不断的抛出异常。并且客户端连接时还会抛出这样的异常，说明连接被拒绝，并且等待一个socket连接新的连接，这里socket新的连接指的是zookeeper中的一个Follower。

记得大约在2006年的时候Google出了Chubby来解决分布一致性的问题（distributed consensus problem），所有集群中的服务器通过Chubby最终选出一个Master Server，最后这个Master Server来协调工作。简单来说其原理就是：在一个分布式系统中，有一组服务器在运行同样的程序，它们需要确定一个Value，以那个服务器提供的信息为主/准，当这个服务器经过n/2+1的方式呗选出来后，所有的机器上的Process都被通知到这个服务器就是主服务器Master服务器，大家以他提供的信息为准。很想知道Google Chubby中的奥妙，可惜人家Google不开源，自家用。

但是在2009年3年以后沉默已久的Yahoo在Apache上退出了类似的产品Zookeeper，并且在Google原有Chubby的设计思想上做了一些改进，因为Zookeeper并不是完全遵循Paxos协议，而是基于自身设计并优化的一个2 phase commit协议，Zookeeper跟Chubby一样用来存放一些相互协作的信息（Coordination），这些信息比较小一般不会超过1M，在Zookeeper中是以一种hierarchical tree的形式来存放，这些具体的Key/Value信息就store在 tree node中。当有事件导致node数据变化，例如：变更，增加，删除时，Zookeeper就会调用triggerWatch方法，判断当前的path是否有对应的坚挺着（watcher），如果有watcher，会触发其process方法，执行process方法中的业务逻辑。