Zookeeper--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到底能干些什么。