zookeeper是什么,能做什么

Google的三篇论文影响了很多很多人，也影响了很多很多系统。这三篇论文一直是分布式领域传阅的经典。根据MapReduce，于是我们有了Hadoop；根据GFS，于是我们有了HDFS；根据BigTable，于是我们有了HBase。而在这三篇论文里都提及Google的一个lock service—Chubby，哦，于是我们有了Zookeeper。

随着大数据的火热，Hxx们已经变得耳熟能详，现在作为一个开发人员如果都不知道这几个名词出门都好像不好意思跟人打招呼。但实际上对我们这些非大数据开发人员而言，Zookeeper是比Hxx们可能接触到更多的一个基础服务。但是，无奈的是它一直默默的位于二线，从来没有Hxx们那么耀眼。那么到底什么是Zookeeper呢？Zookeeper可以用来干什么？我们将如何使用Zookeeper？Zookeeper又是怎么实现的？

伴随着Zookeeper有两篇论文：一篇是Zab，就是介绍Zookeeper背后使用的一致性协议的(Zookeeper atomic broadcast protocol)，还有一篇就是介绍Zookeeper本身的。在这两篇论文里都提到Zookeeper是一个分布式协调服务(a service for coordinating processes of distributed applications)。那分布式协调服务又是个什么东西呢？首先我们来看“协调”是什么意思。

说到协调，我首先想到的是北京很多十字路口的交通协管，他们手握着小红旗，指挥车辆和行人是不是可以通行。如果我们把车辆和行人比喻成运行在计算机中的单元(线程)，那么这个协管是干什么的？很多人都会想到，这不就是锁么？对，在一个并发的环境里，我们为了避免多个运行单元对共享数据同时进行修改，造成数据损坏的情况出现，我们就必须依赖像锁这样的协调机制，让有的线程可以先操作这些资源，然后其他线程等待。对于进程内的锁来讲，我们使用的各种语言平台都已经给我们准备很多种选择。就拿Java来说，有最普通不过的同步方法或同步块：

public synchronized void sharedMethod(){
   //对共享数据进行操作
}

使用了这种方式后，多个线程对sharedMethod进行操作的时候，就会协调好步骤，不会对sharedMethod里的资源进行破坏，产生不一致的情况。这个最简单的协调方法，但有的时候我们可能需要更复杂的协调。比如我们常常为了提高性能，我们使用读写锁。因为大部分时候我们对资源是读取多而修改少，而如果不管三七二十一全部使用排他的写锁，那么性能有可能就会受到影响。还是用java举例：

public class SharedSource{
   private ReadWriteLock rwlock = new ReentrantReadWriteLock();
   private Lock rlock = rwlock.readLock();
   private Lock wlock = rwlock.writeLock();

   public void read(){
      rlock.lock();
      try{
         //读取资源
      }finally{
         rlock.unlock();
      }
   }

   public void write(){
     wlock.lock();
     try{
        //写资源
     }finally{
        wlock.unlock();
     }
   }

}

我们在进程内还有各种各样的协调机制(一般我们称之为同步机制)。现在我们大概了解了什么是协调了，但是上面介绍的协调都是在进程内进行协调。在进程内进行协调我们可以使用语言，平台，操作系统等为我们提供的机制。那么如果我们在一个分布式环境中呢？也就是我们的程序运行在不同的机器上，这些机器可能位于同一个机架，同一个机房又或不同的数据中心。在这样的环境中，我们要实现协调该怎么办？那么这就是分布式协调服务要干的事情。

ok，可能有人会讲，这个好像也不难。无非是将原来在同一个进程内的一些原语通过网络实现在分布式环境中。是的，表面上是可以这么说。但分布式系统中，说往往比做容易得多。在分布式系统中，所有同一个进程内的任何假设都不存在：因为网络是不可靠的。

比如，在同一个进程内，你对一个方法的调用如果成功，那就是成功(当然，如果你的代码有bug那就另说了)，如果调用失败，比如抛出异常那就是调用失败。在同一个进程内，如果这个方法先调用先执行，那就是先执行。但是在分布式环境中呢？ 由于网络的不可靠，你对一个服务的调用失败了并不表示一定是失败的，可能是执行成功了，但是响应返回的时候失败了。还有，A和B都去调用C服务，在时间上A还先调用一些，B后调用，那么最后的结果是不是一定A的请求就先于B到达呢？ 这些本来在同一个进程内的种种假设我们都要重新思考，我们还要思考这些问题给我们的设计和编码带来了哪些影响。还有，在分布式环境中为了提升可靠性，我们往往会部署多套服务，但是如何在多套服务中达到一致性，这在同一个进程内很容易解决的问题，但在分布式环境中确实一个大难题。

所以分布式协调远远比同一个进程里的协调复杂得多，所以类似Zookeeper这类基础服务就应运而生。这些系统都在各个系统久经考验，它的可靠性，可用性都是经过理论和实践的验证的。所以我们在构建一些分布式系统的时候，就可以以这类系统为起点来构建我们的系统，这将节省不少成本，而且bug也将更少。

在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 

这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。

配置管理

在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。但是当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。比如我们可以把配置放在数据库里，然后所有需要配置的服务都去这个数据库读取配置。但是，因为很多服务的正常运行都非常依赖这个配置，所以需要这个集中提供配置服务的服务具备很高的可靠性。一般我们可以用一个集群来提供这个配置服务，但是用集群提升可靠性，那如何保证配置在集群中的一致性呢？ 这个时候就需要使用一种实现了一致性协议的服务了。Zookeeper就是这种服务，它使用Zab这种一致性协议来提供一致性。现在有很多开源项目使用Zookeeper来维护配置，比如在HBase中，客户端就是连接一个Zookeeper，获得必要的HBase集群的配置信息，然后才可以进一步操作。还有在开源的消息队列Kafka中，也使用Zookeeper来维护broker的信息。在Alibaba开源的SOA框架Dubbo中也广泛的使用Zookeeper管理一些配置来实现服务治理。

名字服务

名字服务这个就很好理解了。比如为了通过网络访问一个系统，我们得知道对方的IP地址，但是IP地址对人非常不友好，这个时候我们就需要使用域名来访问。但是计算机是不能是别域名的。怎么办呢？如果我们每台机器里都备有一份域名到IP地址的映射，这个倒是能解决一部分问题，但是如果域名对应的IP发生变化了又该怎么办呢？于是我们有了DNS这个东西。我们只需要访问一个大家熟知的(known)的点，它就会告诉你这个域名对应的IP是什么。在我们的应用中也会存在很多这类问题，特别是在我们的服务特别多的时候，如果我们在本地保存服务的地址的时候将非常不方便，但是如果我们只需要访问一个大家都熟知的访问点，这里提供统一的入口，那么维护起来将方便得多了。

分布式锁

其实在第一篇文章中已经介绍了Zookeeper是一个分布式协调服务。这样我们就可以利用Zookeeper来协调多个分布式进程之间的活动。比如在一个分布式环境中，为了提高可靠性，我们的集群的每台服务器上都部署着同样的服务。但是，一件事情如果集群中的每个服务器都进行的话，那相互之间就要协调，编程起来将非常复杂。而如果我们只让一个服务进行操作，那又存在单点。通常还有一种做法就是使用分布式锁，在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。比如HBase的Master就是采用这种机制。但要注意的是分布式锁跟同一个进程的锁还是有区别的，所以使用的时候要比同一个进程里的锁更谨慎的使用。

集群管理

在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中其他机器需要感知到这种变化，然后根据这种变化做出对应的决策。比如我们是一个分布式存储系统，有一个中央控制节点负责存储的分配，当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候我们就需要动态感知到集群目前的状态。还有，比如一个分布式的SOA架构中，服务是一个集群提供的，当消费者访问某个服务时，就需要采用某种机制发现现在有哪些节点可以提供该服务(这也称之为服务发现，比如Alibaba开源的SOA框架Dubbo就采用了Zookeeper作为服务发现的底层机制)。还有开源的Kafka队列就采用了Zookeeper作为Cosnumer的上下线管理。

前面两篇文章介绍了Zookeeper是什么和可以干什么，那么接下来我们就实际的接触一下Zookeeper这个东西，看看具体如何使用，有个大体的感受，后面再描述某些地方的时候也能在大脑中有具体的印象。本文只关注分布式模式的zookeeper，因为这也是在生产环境的唯一部署方式，单机的zookeeper可以在测试和开发环境使用，但是单机环境的zookeeper就不再是zookeeper了。

安装配置很简单，官网也有介绍，这里就只对后面的文章有提到的点说明下。

配置-zoo.cfg

这是zookeeper的主要配置文件，因为Zookeeper是一个集群服务，集群的每个节点都需要这个配置文件。为了避免出差错，zoo.cfg这个配置文件里没有跟特定节点相关的配置，所以每个节点上的这个zoo.cfg都是一模一样的配置。这样就非常便于管理了，比如我们可以把这个文件提交到版本控制里管理起来。其实这给我们设计集群系统的时候也是个提示：集群系统一般有很多配置，应该尽量将通用的配置和特定每个服务的配置(比如服务标识)分离，这样通用的配置在不同服务之间copy就ok了。ok，下面来介绍一些配置点：

clientPort=2181

client port，顾名思义，就是客户端连接zookeeper服务的端口。这是一个TCP port。

dataDir=/data

dataLogDir=/datalog

dataLogDir如果没提供的话使用的则是dataDir。zookeeper的持久化都存储在这两个目录里。dataLogDir里是放到的顺序日志(WAL)。而dataDir里放的是内存数据结构的snapshot，便于快速恢复。为了达到性能最大化，一般建议把dataDir和dataLogDir分到不同的磁盘上，这样就可以充分利用磁盘顺序写的特性。

下面是集群中服务的列表

server.1=127.0.0.1:20881:30881
server.2=127.0.0.1:20882:30882
server.3=127.0.0.1:20883:30883

在上面的例子中，我把三个zookeeper服务放到同一台机器上。上面的配置中有两个TCP port。后面一个是用于Zookeeper选举用的，而前一个是Leader和Follower或Observer交换数据使用的。我们还注意到server.后面的数字。这个就是myid(关于myid是什么下一节会介绍)。

上面这几个是一些基本配置。

还有像 tickTime，这是个时间单位定量。比如tickTime=1000，这就表示在zookeeper里1 tick表示1000 ms，所有其他用到时间的地方都会用多少tick来表示。

比如 syncLimit = 2 就表示fowller与leader的心跳时间是2 tick。

maxClientCnxns – 对于一个客户端的连接数限制，默认是60，这在大部分时候是足够了。但是在我们实际使用中发现，在测试环境经常超过这个数，经过调查发现有的团队将几十个应用全部部署到一台机器上，以方便测试，于是这个数字就超过了。

minSessionTimeout, maxSessionTimeout – 一般，客户端连接zookeeper的时候，都会设置一个session timeout，如果超过这个时间client没有与zookeeper server有联系，则这个session会被设置为过期(如果这个session上有临时节点，则会被全部删除，这就是实现集群感知的基础，后面的文章会介绍这一点)。但是这个时间不是客户端可以无限制设置的，服务器可以设置这两个参数来限制客户端设置的范围。

autopurge.snapRetainCount，autopurge.purgeInterval – 客户端在与zookeeper交互过程中会产生非常多的日志，而且zookeeper也会将内存中的数据作为snapshot保存下来，这些数据是不会被自动删除的，这样磁盘中这样的数据就会越来越多。不过可以通过这两个参数来设置，让zookeeper自动删除数据。autopurge.purgeInterval就是设置多少小时清理一次。而autopurge.snapRetainCount是设置保留多少个snapshot，之前的则删除。

不过如果你的集群是一个非常繁忙的集群，然后又碰上这个删除操作，可能会影响zookeeper集群的性能，所以一般会让这个过程在访问低谷的时候进行，但是遗憾的是zookeeper并没有设置在哪个时间点运行的设置，所以有的时候我们会禁用这个自动删除的功能，而在服务器上配置一个cron，然后在凌晨来干这件事。

以上就是zoo.cfg里的一些配置了。下面就来介绍myid。

配置-myid

在dataDir里会放置一个myid文件，里面就一个数字，用来唯一标识这个服务。这个id是很重要的，一定要保证整个集群中唯一。zookeeper会根据这个id来取出server.x上的配置。比如当前id为1，则对应着zoo.cfg里的server.1的配置。

2. 而且在后面我们介绍leader选举的时候，这个id的大小也是有意义的。

OK，上面就是配置的讲解了，现在我们可以启动zookeeper集群了。进入到bin目录，执行 ./zkServer.sh start即可。

在上一篇，我们了解了zookeeper最基本的配置，也从中了解一些配置的作用，那么这篇文章中，我们将介绍Zookeeper的启动过程，我们在了解启动过程的时候还要回过头看看上一篇中各个配置参数在启动时的位置。

Zookeeper的启动入口在org.apache.zookeeper.server.quorum.QuorumPeerMain。

在这个类的main方法里进入了zookeeper的启动过程，首先我们会解析配置文件，即zoo.cfg和myid。

这样我们就知道了dataDir和dataLogDir指向哪儿了，然后就可以启动日志清理任务了(如果配置了的话)。

DatadirCleanupManager purgeMgr = new DatadirCleanupManager(config
                .getDataDir(), config.getDataLogDir(), config
                .getSnapRetainCount(), config.getPurgeInterval());
purgeMgr.start();

接下来会初始化ServerCnxnFactory，这个是用来接收来自客户端的连接的，也就是这里启动的是一个tcp server。在Zookeeper里提供两种tcp server的实现，一个是使用java原生NIO的方式，另外一个是使用Netty。默认是java nio的方式，一个典型的Reactor模型。因为java nio编程并不是本文的重点，所以在这里就只是简单的介绍一下。

//首先根据配置创建对应factory的实例:NIOServerCnxnFactory 或者 NettyServerCnxnFactory
ServerCnxnFactory cnxnFactory = ServerCnxnFactory.createFactory();
//初始化配置
cnxnFactory.configure(config.getClientPortAddress(),config.getMaxClientCnxns());

创建几个SelectorThread处理具体的数据读取和写出。

先是创建ServerSocketChannel，bind等

this.ss =  ServerSocketChannel.open();
ss.socket().setReuseAddress(true);
ss.socket().bind(addr);
ss.configureBlocking(false);

然后创建一个AcceptThread线程来接收客户端的连接。

这一部分就是处理客户端请求的模块了，如果遇到有客户端请求的问题可以看看这部分。

接下来就进入初始化的主要部分了，首先会创建一个QuorumPeer实例，这个类就是表示zookeeper集群中的一个节点。初始化QuorumPeer的时候有这么几个关键点：

1. 初始化FileTxnSnapLog，这个类主要管理Zookeeper中的操作日志(WAL)和snapshot。

2. 初始化ZKDatabase，这个类就是Zookeeper的目录结构在内存中的表示，所有的操作最后都会映射到这个类上面来。

3. 初始化决议validator(QuorumVerifier->QuorumMaj) (其实这一步，是在配置)。这一步是从zoo.cfg的server.n这一部分初始化出集群的成员出来，有哪些需要参与投票(follower)，有哪些只是observer。还有决定half是多少等，这些都是zookeeper的核心。在这一步，对于每个节点会初始化一个QuorumServer对象，并且放到allMembers，votingMembers，observingMembers这几个map里。而且这里也对参与者的个数进行了一些判断。

4. leader选举 这一步非常重要，也是zookeeper里最复杂而最精华的一部分。