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到底能幹些什麼。