概述
ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務和命名服務等。
ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
ZooKeeper包含一個簡單的原語集,提供了java、C和python的接口
ZooKeeper代碼版本中，提供了分佈式獨享鎖、選舉、隊列的接口，代碼在src\recipes。其中分佈鎖和隊列有Java和C兩個版本，選舉只有Java版本。
原理
Zookeeper是以Fast-Paxos算法爲基礎的，Paxos算法存在活鎖的問題，即當有多個propose交錯提交時，有可能互相排斥導致沒有一個proposer能提交成功，而Fast-Paxos做了一些優化，通過選舉產生一個leader(領導者)，只有leader才能提交proposer。
Zookeeper的基本運轉流程：
1. 每個Server在內存中存儲了一份數據；
2. Zookeeper啓動時，將從實例中選舉一個leader；
3. Leader要具有最高的執行ID，類似root權限，Leader負責處理數據更新等操作；
4. 一個更新操作成功，當且僅當大多數Server在內存中成功修改數據。
爲什麼使用zookeeper？
- 大部分分佈式應用需要一個主控、協調器或控制器來管理物理分佈的子進程(如資源、任務分配等)
- 目前，大部分應用需要開發私有的協調程序，缺乏一個通用的機制
- 協調程序的反覆編寫浪費，且難以形成通用、伸縮性好的協調器
- Zookeeper：提供通用的分佈式鎖服務，用以協調分佈式應用
- Keepalived監控節點不好管理
- Keepalive採用優先級監控
- 沒有協同工作
- 功能單一
- Keepalive可擴展性差
Zookeeper特性
- Zookeeper是簡單的
- Zookeeper是富有表現力的
- Zookeeper具有高可用性
- Zookeeper採用鬆耦合交互方式
- Zookeeper是一個資源庫
Zookeeper優點
| 特點 | 說明 |
|---|---|
| 最終一致性 | 爲客戶端展示同一個視圖 |
| 可靠性 | 如果消息被一臺服務器接受，那麼它將被所有的服務器接受 |
| 實時性 | Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口 |
| 獨立性 | 各個Client之間互不干預 |
| 原子性 | 更新只能成功或失敗，沒有中間狀態 |
| 順序性 | 所有Server,同一消息發佈順序一致 |
znode
在zookeeper中，znode是一個跟Unix文件系統路勁相似的節點，可以往這個節點存儲或獲取數據。如果在創建znode時Flag設置爲EPHEMERAL(ephemeral短暫的)，那麼當創建這個znode的節點和zookeeper失去連接後，這個znode將不再存在在zookeeper裏，Zookeeper使用Watcher察覺事件信息。當客戶端接收到事件信息，比如連接超時、節點數據改變、子節點改變，可以調用相應的行爲來處理數據。
Zookeeper作用
- Hadoop，使用Zookeeper的事件處理確保整個集羣只有一個NameNode,存儲配置信息等。
- HBase，使用Zookeeper的事件處理確保整個集羣只有一個HMaster,察覺HRegionServer聯機和宕機，存儲訪問控制列表等。
例子
假設我們有20個搜索引擎的服務器(每個負責總索引中的一部分搜索任務)和一個總服務器(負責向這20個搜索引擎的服務器發出搜索請求併合並結果集)，一個備用的總服務器(負責當總服務器宕機時替換總服務器)，一個web的cgi(向總服務器發出搜索請求)。搜索引擎的服務器中的15個服務器提供搜索服務，5個服務器正在生成索引。這20個搜索引擎的服務器經常要讓正在提供搜索服務的服務器停止提供服務開始生成索引，或生成索引的服務器已經把索引生成完成可以提供搜索服務。
使用zookeeper可以保證總服務器自動感知有多少提供搜索引擎的服務器並向這些服務器發出搜索請求，當總服務宕機時自動啓用備用的總服務器。