zookeeper是乙個針對大型分布式系統的可靠協調系統。提供的功能包括：配置維護、名字服務、分布式同步、組服務等。目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。zookeeper已經成為hadoop生態系統中的基礎元件。
zookeeper有如下特點：
最終一致性：為客戶端展示同一檢視，這是zookeeper最重要的功能。
可靠性：如果訊息被到一台伺服器接受，那麼它將被所有的伺服器接受。
實時性：zookeeper不能保證兩個客戶端能同時得到剛更新的資料，如果需要最新資料，應該在讀資料之前呼叫sync()介面。
等待無關（wait-free）：慢的或者失效的client不干預快速的client的請求。
原子性：更新只能成功或者失敗，沒有中間狀態。
順序性：所有server，同一訊息發布順序一致。
zookeeper的應用有hdfs、yarn、storm、hbase、flume、dubbo（阿里巴巴）以及metaq阿里巴巴）。
zookeeper基本原理
zookeeper的架構如圖所示。
每個server在記憶體中儲存了乙份資料。當zookeeper啟動時，將從例項中選舉乙個leader（paxos協議）。leader負責處理資料更新等操作（zab協議）。乙個更新操作成功，當且僅當大多數server在記憶體中成功修改資料。
zookeeper有三個不同的角色。領導者負責進行投票的發起和決議以及系統的狀態更新。學習者包括跟隨者和觀察者。其中，跟隨者用於接收客戶請求並向客戶端返回結果，在選主過程中參與投票。觀察者可以接收客戶端連線，將寫請求**給leader節點。但觀察者不參與投票，只負責同步leader的狀態。目的是為了系統的擴充套件，提高讀取速度。客戶端是請求發起方。
leader選舉演算法採用了paxos協議。paxos的核心思想是當多數server寫成功，則任務資料寫成功。如果有3個server，則兩個寫成功即可。
zookeeper的寫過程如圖所示。首先，客戶端向本地server傳送請求。然後，server向leader傳送請求，leader會向各個server發起投票命令。之後，leader會收集投票結果通知所有server禿瓢結果。最後，server傳送操作結果給客戶端。
zookeeper的資料模型
zookeeper是層次化的目錄結構，命名符合常規檔案系統規範。每個節點在zookeeper中叫做znode,並且其有乙個唯一的路徑標識。節點znode可以包含資料和子節點（ephemeral型別的節點不能有子節點）。znode中的資料可以有多個版本，比如某乙個路徑下存有多個資料版本，那麼查詢這個路徑下的資料需帶上版本。客戶端應用可以在節點上設定監視器（watcher）。節點不支援部分讀寫，而是一次性完整讀寫。znode有兩種型別，短暫的（ephemeral）和持久的（persistent）。znode的型別在建立時確定並且之後不能再修改。短暫znode的客戶端會話結束時，zookeeper會將該短暫znode刪除，短暫znode不可以有子節點。持久znode不依賴於客戶端會話，只有當客戶端明確要刪除該持久znode時才會被刪除。znode有四種形式的目錄節點，persistent、persistent_sequential、ephemeral、ephemeral_sequential。
zookeeper應用場景
統一命名服務
分布式環境下，經常需要對應用/服務進行統一命名，便於識別不同服務。類似於網域名稱與ip之間對應關係，網域名稱容易記住。通過名稱來獲取資源或服務的位址，提供者等資訊按照層次結構組織服務/應用名稱可將服務名稱以及位址資訊寫到zookeeper上，客戶端通過zookeeper獲取可用服務列表類。
配置管理
分布式環境下，配置檔案管理和同步是乙個常見問題。乙個集群中，所有節點的配置資訊是一致的，比如hadoop。對配置檔案修改後，希望能夠快速同步到各個節點上配置管理可交由zookeeper實現。可將配置資訊寫入zookeeper的乙個znode上。各個節點監聽這個znode。一旦znode中的資料被修改，zookeeper將通知各個節點。
集群管理
分布式環境中，實時掌握每個節點的狀態是必要的。可根據節點實時狀態作出一些調整。zookeeper可將節點資訊寫入zookeeper的乙個znode上。監聽這個znode可獲取它的實時狀態變化。典型應用比如hbase中master狀態監控與選舉。
分布式通知/協調
分布式環境中，經常存在乙個服務需要知道它所管理的子服務的狀態。例如，namenode須知道各datanode的狀態，jobtracker須知道各tasktracker的狀態。心跳檢測機制和資訊推送也是可通過zookeeper實現。
分布式鎖
zookeeper是強一致的。多個客戶端同時在zookeeper上建立相同znode，只有乙個建立成功。zookeeper實現鎖的獨占性。多個客戶端同時在zookeeper上建立相同znode ，建立成功的那個客戶端得到鎖，其他客戶端等待。zookeeper 控制鎖的時序。各個客戶端在某個znode下建立臨時znode （型別為createmode. ephemeral _sequential），這樣，該znode可掌握全域性訪問時序。
分布式佇列
兩種佇列。當乙個佇列的成員都聚齊時，這個佇列才可用，否則一直等待所有成員到達，這種是同步佇列。佇列按照 fifo 方式進行入隊和出隊操作，例如實現生產者和消費者模型。（可通過分布式鎖實現）
同步佇列。乙個job由多個task組成，只有所有任務完成後，job才執行完成。可為job建立乙個/job目錄，然後在該目錄下，為每個完成的task建立乙個臨時znode，一旦臨時節點數目達到task總數，則job執行完成。
zookeeper客戶端設計
zookeeper api包括：
string create (path, data, acl, flags)
void delete (path, expectedversion)
stat setdata (path, data, expectedversion)
byte getdata (path, watch)
stat exists (path, watch)
string getchildren (path, watch)
void sync (path)
zookeeper watcher
watcher 在 zookeeper 是乙個核心功能。可以監控目錄節點的資料變化以及子目錄的變化。一旦狀態發生變化，伺服器就會通知所有設定在這個目錄節點上的 watcher。其基本特點是一次設定對應一次觸發、非同步觸發以及順序觸發。可以設定觀察的操作為exists getchildren getdata。可以觸發觀察的操作為create delete setdata。
zookeeper案例—配置管理（updater設計）
zookeeper案例—配置管理（wacher設計）
以上介紹了zookeeper的基本原理與應用場景，下一步將介紹hadoop的其他元件。
Zookeeper基本原理
一 zookeeper角色 領導者 leader 領導者負責進行投票的發起和決議，更新系統狀態。學習者 learner 跟隨者 follower用於接收客戶端請求並向客戶端返回結果，在選主過程中參與投票。觀察者 observer可以接收客戶端連線，並將請求 給leader節點，但observer 不...
zookeeper基本原理
服務集群對外提供服務的過程中，有很多的配置需要隨時更新，服務間需要協調工作，這些資訊如何推送到各個節點？並且保證資訊的一致性和可靠性？用zookeeper實現了一 個配置管理中心，利用zookeeper將配置資訊分發到各個服務節點上，並保證資訊的正確性和一致性。引用官方的說法 zookeeper是乙...
深入理解zookeeper基本原理
zookeeper 是乙個針對大型分布式系統的可靠協調系統 它提供的功能包括 配置維護 名字服務 分布式同步 組服務等 它的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效 功能穩定的系統提供給使用者。zookeeper 主要包含以下幾個特點 1 最終一致性 為客戶端展示同一檢視，這是...