一、Zookerper 簡介：
ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，Google Chubby 開源實現，Hadoop Hbase 重要組件；
ZooKeeper是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等；
ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶；
ZooKeeper包含一個簡單的原語集，提供Java和C的接口；
ZooKeeper代碼版本中，提供了分佈式獨享鎖、選舉、隊列的接口；
二、Zookerper 原理：
ZooKeeper是以Fast Paxos算法爲基礎的，Paxos 算法存在活鎖的問題，即當有多個proposer交錯提交時，有可能互相排斥導致沒有一個proposer能提交成功，而Fast Paxos作了一些優化，通過選舉產生一個leader，只有leader才能提交proposer，具體算法可見 Fast Paxos。
三、Zookeeper中的角色主要有以下三類：
1、領導者 leader 用於更新系統狀態；
2、學習者 learner
2.1、跟隨者 follower(控制層)
用於接口客戶請求並向客戶端面返回結果；
2.2、觀察者 observer(業務層)
用於接收客戶端連接，將寫請求轉發給 leader，目的爲了展擴系統，提高讀取速度；
3、客戶端 client；
四、Zookeeper 設計目的：
1.最終一致性：
client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。
2.可靠性：
具有簡單、健壯、良好的性能，如果消息m被到一臺服務器接受，那麼它將被所有的服務器接受。
3.實時性：
Zookeeper保證客戶端將在一個時間間隔範圍內獲得服務器的更新信息，或者服務器失效的信息。
但由於網絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。
4.等待無關（wait-free）：
慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
5.原子性：更新只能成功或者失敗，沒有中間狀態。
6.順序性：
包括全局有序和偏序兩種：全局有序是指如果在一臺服務器上消息a在消息b前發佈，則在所有Server上消息a都將在消息b前被髮布；
偏序是指如果一個消息b在消息a後被同一個發送者發佈，a必將排在b前面。
五、ZooKeeper的工作原理：
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步,實現這個機制的協議叫做Zab協議,Zab協議有兩種模式，它們分別是恢復模式(選主) 廣播模式(同步);
當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以後，恢復模式就結束了,狀態同步保證了leader和Server具有相同的系統狀態。
爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。
每個Server在工作過程中有三種狀態：
LOOKING：當前Server不知道leader是誰，正在搜尋;
LEADING：當前Server即爲選舉出來的leader;
FOLLOWING：leader已經選舉出來，當前Server與之同步;
六、應用場景(http://www.cnblogs.com/tommyli/p/3766189.html)：
1、數據發佈與訂閱(配置中心）：
發佈與訂閱模型，顧名思義就是發佈者將數據發佈到ZK節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。例如全局的配置信息，服務式服務框架的服務地址列表等就非常適合使用。
2、負載均衡：
這裏說的負載均衡是指軟負載均衡。在分佈式環境中，爲了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，達到對等服務。而消費者就須要在這些對等的服務器中選擇一個來執行相關的業務邏輯，其中比較典型的是消息中間件中的生產者，消費者負載均衡。
3、命名服務(Naming Service)：
命名服務也是分佈式系統中比較常見的一類場景。在分佈式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等信息。被命名的實體通常可以是集羣中的機器，提供的服務地址，遠程對象等等——這些我們都可以統稱他們爲名字（Name）。其中較爲常見的就是一些分佈式服務框架中的服務地址列表。通過調用ZK提供的創建節點的API，能夠很容易創建一個全局唯一的path，這個path就可以作爲一個名稱。
4、分佈式通知/協調：
ZooKeeper特有watcher註冊與異步通知機制，能夠很好的實現分佈式環境下不同系統之間的通知與協調，實現對數據變更的實時處理。使用方法通常是不同系統都對ZK上同一個znode進行註冊，監聽znode的變化（包括znode本身內容及子節點的），其中一個系統update了znode，那麼另一個系統能夠收到通知，並作出相應處理。
5、集羣管理與Master選舉：
集羣機器監控：這通常用於那種對集羣中機器狀態，機器在線率有較高要求的場景，能夠快速對集羣中機器變化作出響應。這樣的場景中，往往有一個監控系統，實時檢測集羣機器是否存活。過去的做法通常是：監控系統通過某種手段（比如ping）定時檢測每個機器，或者每個機器自己定時向監控系統彙報“我還活着”。 這種做法可行，但是存在兩個比較明顯的問題：
6、分佈式鎖：
分佈式鎖，這個主要得益於ZooKeeper爲我們保證了數據的強一致性。鎖服務可以分爲兩類，一個是保持獨佔，另一個是控制時序。
7、分佈式隊列：
隊列方面，簡單地講有兩種，一種是常規的先進先出隊列，另一種是要等到隊列成員聚齊之後的才統一按序執行。對於第一種先進先出隊列，和分佈式鎖服務中的控制時序場景基本原理一致，這裏不再贅述。
ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，Google Chubby 開源實現，Hadoop Hbase 重要組件；
ZooKeeper是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等；
ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶；
ZooKeeper包含一個簡單的原語集，提供Java和C的接口；
ZooKeeper代碼版本中，提供了分佈式獨享鎖、選舉、隊列的接口；
二、Zookerper 原理：
ZooKeeper是以Fast Paxos算法爲基礎的，Paxos 算法存在活鎖的問題，即當有多個proposer交錯提交時，有可能互相排斥導致沒有一個proposer能提交成功，而Fast Paxos作了一些優化，通過選舉產生一個leader，只有leader才能提交proposer，具體算法可見 Fast Paxos。
三、Zookeeper中的角色主要有以下三類：
1、領導者 leader 用於更新系統狀態；
2、學習者 learner
2.1、跟隨者 follower(控制層)
用於接口客戶請求並向客戶端面返回結果；
2.2、觀察者 observer(業務層)
用於接收客戶端連接，將寫請求轉發給 leader，目的爲了展擴系統，提高讀取速度；
3、客戶端 client；
四、Zookeeper 設計目的：
1.最終一致性：
client不論連接到哪個Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。
2.可靠性：
具有簡單、健壯、良好的性能，如果消息m被到一臺服務器接受，那麼它將被所有的服務器接受。
3.實時性：
Zookeeper保證客戶端將在一個時間間隔範圍內獲得服務器的更新信息，或者服務器失效的信息。
但由於網絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。
4.等待無關（wait-free）：
慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。
5.原子性：更新只能成功或者失敗，沒有中間狀態。
6.順序性：
包括全局有序和偏序兩種：全局有序是指如果在一臺服務器上消息a在消息b前發佈，則在所有Server上消息a都將在消息b前被髮布；
偏序是指如果一個消息b在消息a後被同一個發送者發佈，a必將排在b前面。
五、ZooKeeper的工作原理：
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步,實現這個機制的協議叫做Zab協議,Zab協議有兩種模式，它們分別是恢復模式(選主) 廣播模式(同步);
當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以後，恢復模式就結束了,狀態同步保證了leader和Server具有相同的系統狀態。
爲了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。
每個Server在工作過程中有三種狀態：
LOOKING：當前Server不知道leader是誰，正在搜尋;
LEADING：當前Server即爲選舉出來的leader;
FOLLOWING：leader已經選舉出來，當前Server與之同步;
六、應用場景(http://www.cnblogs.com/tommyli/p/3766189.html)：
1、數據發佈與訂閱(配置中心）：
發佈與訂閱模型，顧名思義就是發佈者將數據發佈到ZK節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。例如全局的配置信息，服務式服務框架的服務地址列表等就非常適合使用。
2、負載均衡：
這裏說的負載均衡是指軟負載均衡。在分佈式環境中，爲了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，達到對等服務。而消費者就須要在這些對等的服務器中選擇一個來執行相關的業務邏輯，其中比較典型的是消息中間件中的生產者，消費者負載均衡。
3、命名服務(Naming Service)：
命名服務也是分佈式系統中比較常見的一類場景。在分佈式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等信息。被命名的實體通常可以是集羣中的機器，提供的服務地址，遠程對象等等——這些我們都可以統稱他們爲名字（Name）。其中較爲常見的就是一些分佈式服務框架中的服務地址列表。通過調用ZK提供的創建節點的API，能夠很容易創建一個全局唯一的path，這個path就可以作爲一個名稱。
4、分佈式通知/協調：
ZooKeeper特有watcher註冊與異步通知機制，能夠很好的實現分佈式環境下不同系統之間的通知與協調，實現對數據變更的實時處理。使用方法通常是不同系統都對ZK上同一個znode進行註冊，監聽znode的變化（包括znode本身內容及子節點的），其中一個系統update了znode，那麼另一個系統能夠收到通知，並作出相應處理。
5、集羣管理與Master選舉：
集羣機器監控：這通常用於那種對集羣中機器狀態，機器在線率有較高要求的場景，能夠快速對集羣中機器變化作出響應。這樣的場景中，往往有一個監控系統，實時檢測集羣機器是否存活。過去的做法通常是：監控系統通過某種手段（比如ping）定時檢測每個機器，或者每個機器自己定時向監控系統彙報“我還活着”。 這種做法可行，但是存在兩個比較明顯的問題：
6、分佈式鎖：
分佈式鎖，這個主要得益於ZooKeeper爲我們保證了數據的強一致性。鎖服務可以分爲兩類，一個是保持獨佔，另一個是控制時序。
7、分佈式隊列：
隊列方面，簡單地講有兩種，一種是常規的先進先出隊列，另一種是要等到隊列成員聚齊之後的才統一按序執行。對於第一種先進先出隊列，和分佈式鎖服務中的控制時序場景基本原理一致，這裏不再贅述。
