zookeeper 的由來

　　分布式系統的很多難題，都是由於缺少協調機制造成的。在分布式協調這塊做得比較好的，有 Google 的 Chubby 以及 Apache 的 Zookeeper。Google Chubby 是一個分布式鎖服務，通過 Google Chubby 來解決分布式協作、Master 選舉等與分布式鎖服務相關的問題。　　

　　Zookeeper 也是類似，因為當時在雅虎內部的很多系統都需要依賴一個系統來進行分布式協調，但是谷歌的Chubby是不開源的，所以後來雅虎基於 Chubby 的思想開發了 zookeeper，並捐贈給了 Apache。

zookeeper解決了什麽問題：

1. zookeeper是一個精簡的文件系統。這點它和hadoop有點像，但是zookeeper這個文件系統是管理小文件的，而hadoop是管理超大文件的。

2. zookeeper提供了豐富的“構件”，這些構件可以實現很多協調數據結構和協議的操作。例如：分布式隊列、分布式鎖以及一組同級節點的“領導者選舉”算法。

3. zookeeper是高可用的，它本身的穩定性是相當之好，分布式集群完全可以依賴zookeeper集群的管理，利用zookeeper避免分布式系統的單點故障的問題。

4. zookeeper采用了松耦合的交互模式。這點在zookeeper提供分布式鎖上表現最為明顯，zookeeper可以被用作一個約會機制，讓參入的進程不在了解其他進程的（或網絡）的情況下能夠彼此發現並進行交互，參入的各方甚至不必同時存在，只要在zookeeper留下一條消息，在該進程結束後，另外一個進程還可以讀取這條信息，從而解耦了各個節點之間的關系。

5. zookeeper為集群提供了一個共享存儲庫，集群可以從這裏集中讀寫共享的信息，避免了每個節點的共享操作編程，減輕了分布式系統的開發難度。

6. zookeeper的設計采用的是觀察者的設計模式，zookeeper主要是負責存儲和管理大家關心的數據，然後接受觀察者的註冊，一旦這些數據的狀態發生變化，Zookeeper 就將負責通知已經在 Zookeeper 上註冊的那些觀察者做出相應的反應，從而實現集群中類似 Master/Slave 管理模式。

7. 。。。。。

如果自己設計一個類似 zookeeper 這個中間件，我們需要考慮到什麽呢？：

　　1. 防止單點故障

　　如果要防止 zookeeper 這個中間件的單點故障，那就勢必要做集群。而且這個集群如果要滿足高性能要求的話，還得是一個高性能高可用的集群。高性能意味著這個集群能夠分擔客戶端的請求流量，高可用意味著集群中的某一個節點宕機以後，不影響整個集群的數據和繼續提供服務的可能性。結論： 所以這個中間件需要考慮到集群,而且這個集群還需要分攤客戶端的請求流量，實現服務的高性能。

　　2. 接著上面那個結論再來思考，如果要滿足這樣的一個高性能集群，我們最直觀的想法應該是，每個節點都能接收到請求，並且每個節點的數據都必須要保持一致。要實現各個節點的數據一致性，就勢必要一個 leader 節點負責協調和數據同步操作。這個我想大家都知道，如果在這樣一個集群中沒有 leader 節點，每個節點都可以接收所有請求，那麽這個集群的數據同步的復雜度是非常大。結論：所以這個集群中涉及到數據同步以及會存在leader 節點

　　3.繼續思考，如何在這些節點中選舉出 leader 節點，以及leader 掛了以後，如何恢復呢？結論：所以 zookeeper 用了基於 paxos 理論所衍生出來的 ZAB 協議

　　.4. leader 節點如何和其他節點保證數據一致性，並且要求是強一致的。在分布式系統中，每一個機器節點雖然都能夠明確知道自己進行的事務操作過程是成功和失敗，但是卻無法直接獲取其他分布式節點的操作結果。所以當一個事務操作涉及到跨節點的時候，就需要用到分布式事務，分布式事務的數據一致性協議有 2PC 協議和3PC 協議。

Zookeeper 集群角色：

　　Leader 角色：Leader 服務器是整個 zookeeper 集群的核心，主要的工作任務有兩項1. 事務請求的唯一調度和處理者，保證集群事物處理的順序性2. 集群內部各服務器的調度者

　　Follower 角色：Follower 角色的主要職責是1. 處理客戶端非事務請求、轉發事務請求給 leader 服務器2. 參與事物請求 Proposal 的投票（需要半數以上服務器通過才能通知 leader commit 數據; Leader 發起的提案，要求 Follower 投票）3. 參與 Leader 選舉的投票

　　Observer 角色：Observer 是 zookeeper3.3 開始引入的一個全新的服務器角色，從字面來理解，該角色充當了觀察者的角色。觀察 zookeeper 集群中的最新狀態變化並將這些狀態變化同步到 observer 服務器上。Observer 的工作原理與follower 角色基本一致，而它和 follower 角色唯一的不同在於 observer 不參與任何形式的投票，包括事務請求Proposal的投票和leader選舉的投票。簡單來說，observer服務器只提供非事務請求服務，通常在於不影響集群事物處理能力的前提下提升集群非事務處理的能力

zookeeper 的集群：

　　如上圖，在 zookeeper 中，客戶端會隨機連接到 zookeeper 集群中的一個節點，如果是讀請求，就直接從當前節點中讀取數據，如果是寫請求，那麽請求會被轉發給 leader 提交事務，然後 leader 會廣播事務，只要有超過半數節點寫入成功，那麽寫請求就會被提交（類 2PC 事務）

　　所有事務請求必須由一個全局唯一的服務器來協調處理，這個服務器就是 Leader 服務器，其他的服務器就是follower。leader 服務器把客戶端的失去請求轉化成一個事務 Proposal（提議），並把這個 Proposal 分發給集群中的所有 Follower 服務器。之後 Leader 服務器需要等待所有Follower 服務器的反饋，一旦超過半數的 Follower 服務器進行了正確的反饋，那麽 Leader 就會再次向所有的Follower 服務器發送 Commit 消息，要求各個 follower 節點對前面的一個 Proposal 進行提交;

深入分析Zookeeper的實現原理