Zookeeper概述

為什麼要用zookeeper

zookeeper是分散式協調服務，分散式應用難免會出現部分失敗，假設一條訊息在兩個節點中間傳輸，如果出現網路錯誤，傳送者無法知道接收者是否已經拿到訊息，接收者可能拿到了，也可能沒有拿到，傳送者要知道真實情況只能重新連線接收者，並向它發出詢問，我們不知道一個操作是否成功，這種情況部分失敗。zookeeper的出現使得我們可以對出現部分失敗的情況進行相應的處理。

zookeeper特點

• 使用起來十分的簡便，它的核心是一個簡化的檔案系統，與linux的檔案系統類似，並且提供了一些簡單的操作和一些額外的抽象操作（排序和通知）
• 在設計上具有高可用性
  ，如果使用複製模式的 話，當一臺leader節點掛點，馬上選舉出一個新的leader，整個選舉過程只有200ms左右
• 使用了鬆耦合的互動方式，在雙方都不瞭解的情況下進行資料的交換，雙方甚至都不需要知道對方是否存在
• 具有高效能，對於以寫操作為主的工作中，基準吞吐量超過每秒10000個操作，對於常規的以讀操作為主的工作中，吞吐量可以高出好幾倍。

• 上圖為一個領導者（leader），多個跟隨者（follower）組成的叢集。
• Leader 負責進行投票的發起和決議，更新系統狀態。通過自動選舉產生
• Follower 用於接收客戶請求並向客戶端返回結果，在選舉 Leader 過程中參與投票
• 叢集中只要有半數以上節點存活
  ，Zookeeper 叢集就能正常服務。如果有5臺節點，只需要3臺節點存活即可，如果有4臺也需要3臺，所以一般部署奇數的臺數的節點
• 全域性資料一致：每個 server 儲存一份相同的資料副本，client 無論連線到哪個 server，資料都是一致的。
• 更新請求順序進行，來自同一個 client 的更新請求按其傳送順序依次執行
• 資料更新原子性，一次資料更新要麼成功，要麼失敗。
• 實時性，在一定時間範圍內，client 能讀到最新資料，下面的寫資料流程解釋原因

寫資料流程

由上圖可以看出當有半數以上的資料寫成功後，leader就會通知某個server，server就會通知客戶端寫入資料成功，此時有部分未同步的節點，當其他的客戶端讀取時會出現滯後的系統檢視，為了避免這種情況，應該在讀取之前進行sync操作，該操作會強制伺服器與leader的伺服器檢視保持一致。

zookeeper資料結構

可以把它理解為一個具有高可用的檔案系統,但是裡面沒有檔案合目錄，統一使用節點znode的概念，znode中可> 以儲存資料也可以儲存其他的znode

四種類型的znode：

• PERSISTENT-持久化目錄節點 ，客戶端與zookeeper斷開連線後，該節點依舊存在
• PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點 ，客戶端與zookeeper斷開連線後，該節點依舊存在，只是Zookeeper給該節點名稱進行順序編號
• EPHEMERAL-臨時目錄節點，客戶端與zookeeper斷開連線後，該節點被刪除
• EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點，客戶端與zookeeper斷開連線後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號