目錄
Zookeeper 3.5官方文檔學習
介紹
Zookeeper是一個專爲分佈式應用提供的分佈式的、開源的協調服務。它公開了一組簡單的原語，分佈式應用程序可以基於這些原語來實現用於同步，配置維護以及組和命名的更高級別的服務。它的設計易於編程，並使用了按照文件系統熟悉的目錄樹結構樣式的數據模型。它以Java運行，並且具有Java和C的綁定。
Design Goals(設計目標)
Zookeeper是簡單的。 它允許分佈式進程通過共享的分級名稱空間相互協調，組織方式類似於標準的文件系統。 name space（名稱空間）由 znodes這種數據寄存器組成, 這些類似於文件和目錄. 和傳統的文件系統不同的是,zookeeper的數據保存在內存中, 而普通的文件系統存儲在磁盤上. 這意味着zookeeper可以實現高吞吐量和低延遲
Zookeeper實施對高性能,高可用性,嚴格有序訪問加以重視. 它的性能意味着它可以在大型的分佈式系統中.
可靠性方面使得它不會由單點故障的情況存在. 嚴格的順序意味着在客戶端上可以實現複雜的同步原語
Zookeeper 也是分佈式的,像它協調的分佈式進程一樣，ZooKeeper本身也可以在稱爲集合的主機上進行復制。
這些組成ZooKeeper服務的Servers 必須彼此瞭解.它們維護內存中的狀態圖像，以及持久存儲中的事務日誌和快照。只要大多數服務器可用，ZooKeeper服務將可用。
客戶端連接到單個ZooKeeper服務器。客戶端維護一個TCP連接，通過它發送請求，獲取響應，獲取監視事件併發送心跳。如果與服務器的TCP連接斷開，則客戶端將連接到其他服務器。
Zookeeper是有序的, ZooKeeper用一個反映所有ZooKeeper事務順序的數字標記每個更新。後續操作可以使用該命令來實現更高級別的抽象，例如同步原語。
ZooKeeper很快。在“讀取爲主”的工作負載中，它特別快。 ZooKeeper應用程序可在數千臺計算機上運行，並且在讀取比寫入更常見的情況下，其性能最佳，比率約爲10：1
Data model and the hierarchical namespace(數據模型和分層名稱空間)
ZooKeeper提供的名稱空間與標準文件系統的名稱空間非常相似。名稱是由斜槓（/）分隔的一系列路徑元素。 ZooKeeper名稱空間中的每個節點都由路徑標識
ZooKeeper的層次命名空間:
Nodes and ephemeral nodes(節點和短暫節點:)
跟標準的文件系統不太一樣, 每一個zookeeper名稱空間中的節點都可以擁有與之相關的數據以及孩子節點.就好像有一個文件系統,這個文件系統可以允許一個文件又是一個目錄.
ZooKeeper旨在存儲協調數據：狀態信息，配置，位置信息等，因此存儲在每個節點上的數據通常很小，在字節到千字節範圍內。
我們使用術語znode來明確表示我們正在談論ZooKeeper數據節點。
Znodes維護一個統計信息結構，其中包括用於數據更改，ACL更改和時間戳的版本號，以允許進行緩存驗證和協調更新。 znode的數據每次更改時，版本號都會增加。例如，每當客戶端檢索數據時，它也接收數據的版本。
ZooKeeper還具有短暫節點的概念。只要創建znode的會話處於活動狀態，這些znode就存在。會話結束時，將刪除znode。當您想實現[tbd]時，臨時節點非常有用。
Conditional updates and watches (有條件的更新和監視)
Zookeeper支持監視的概念.客戶端可以設置給znode設置監視. 一個監視將會被觸發還有在znode變更的時候刪除.當監視被觸發時,客戶端接收一個數據包,說明znode已經被修改 . 如果客戶端和zookeeper servers的鏈接斷開了,客戶端就會接收到本地一個通知.
Guarantees（一致性的保證）
Zookeeper 是十分快速和簡單的。因爲它的目標，它將成爲構建更復雜的服務的基礎。例如同步， 它提供了一系列保證.
- 順序一致性-來自客戶端的更新將按照發送的順序應用。
- 原子性-更新成功或失敗。沒有部分成功部分失敗的可能性
- 單個系統映像-無論客戶端連接到哪個服務器，客戶端都將看到相同的服務視圖。(單一性)
- 可靠性-應用更新後，此更新將一直持續到客戶端覆蓋更新爲止。
- 實時性-Zookeeper保證客戶端將在一個時間間隔範圍內獲得服務器的更新信息或者服務器失效的信息。
Simple API(簡單的API)
zookeeper的其中一個設計目標就是提供一些很簡單的編程接口給大家.So, 它只提供了這些操作:
- create: 在上文提到的層級空間中建立一個節點(層次空間可以類比成一棵樹)
- delete: 刪除一個節點
- exists: 判斷一個節點是否存在
- get data: 讀取一個節點的信息
- set data: 給一個節點設置一些信息
- get children: 獲取一個節點的所有孩子節點
- sync: 等待數據傳播(同步)
Implementation(實際操作)
ZooKeeper Components顯示ZooKeeper服務的高級組件。.除請求處理器外，構成ZooKeeper服務的每個服務器都複製其自己的每個組件副本。
Replicated Database 是一個包含了整個數據樹的內存數據庫. 它會更新數據到磁盤以保證可恢復性. 在將"寫入"存儲到內存數據庫之前,會將其序列化到磁盤
每個ZooKeeper服務器都爲客戶端提供服務。客戶端僅連接到一臺服務器即可提交請求。讀取請求從每個服務器數據庫的本地副本提供服務。更改服務狀態的請求（寫請求）由協議協議處理。
作爲協議協議的一部分，來自客戶端的所有寫請求都轉發到稱爲leader的那個服務器(leader只有一個)。其餘的ZooKeeper服務器（稱爲follower）從leader接收消息建議並同意消息傳遞。消息傳遞層負責替換出現故障的leader，並將follower與leader同步。
ZooKeeper使用自定義的原子消息傳遞協議。由於消息傳遞層是原子性的，因此ZooKeeper可以保證本地副本永遠不會跟實際有偏差。當leader收到寫請求時，它會計算要應用write操作時系統的狀態，並將其轉換爲捕獲該新狀態的事務。
uses(用途)
ZooKeeper的編程接口比較簡單。但是，有了它，您可以實現更高階的操作，例如同步原語，組成員資格，所有權等。
Performance(性能)
ZooKeeper被設計爲具有高性能。是真的嗎？ Yahoo!的ZooKeeper開發團隊的結果。研究表明確實如此。 由於寫入涉及同步所有服務器的狀態，因此在讀取次數超過寫入次數的應用程序中，該性能特別高。 （對於協調服務，通常情況下，讀取次數多於寫入次數。）
Reliability(可靠性)
爲了顯示隨着故障注入系統隨時間變化的Zookeeper行爲，我們運行了由7臺機器組成的ZooKeeper服務。我們使用與以前相同的飽和度基準，但是這次我們將寫入百分比保持在恆定的30％，這是我們預期工作量的保守比率。
該圖有一些重要的觀察結果。首先，如果followers 失敗並迅速恢復，則ZooKeeper能夠在失敗的情況下維持高吞吐量。但是，也許更重要的是，leader選擇算法允許系統恢復得足夠快，以防止吞吐量大幅下降。根據我們的觀察，ZooKeeper只需不到200毫秒即可選出新的leader。第三，隨着followers 的恢復，ZooKeeper一旦開始處理請求就能夠再次提高吞吐量。
Znode
每個Znode有自身信息，數據、長度、創建時間、修改時間。
Znode維護數據、ACL（access control list，訪問控制列表）、時間戳等交換版本號等數據結構，它通過對這些數據的管理來讓緩存生效並且令協調更新。每當Znode中的數據更新後版本號將增加。
讀寫操作
讀寫數據原子性，讀就讀取所有數據，寫入時完全覆蓋。Znode的ACL存儲用戶操作權限。
臨時節點
和session相關，session結束，節點刪除。(就是客戶端和服務端斷開連接之後,它就自動刪除掉)
Zookeeper選舉leader流程
1.選舉Leader
2.同步數據
3.選舉Leader過程中算法有很多，但要達到的選舉標準是一致的
4.Leader要具有最高的zxid
5.集羣中大多數的機器得到響應並follow選出的Leader
***半數機制（Paxos 協議）***：集羣中半數以上機器存活，集羣可用。所以 zookeeper 適合裝在奇數臺機器上
舉例:如果有3臺機器先後順序啓動zookeeper
第一臺啓動,此時只有它一個zookeeper節點,發包出去要跟別人選舉,沒人接收, 一直就是looking狀態,zxid=1
第二臺啓動了, 它跟第一個節點開始通信,交換選舉的包,但是兩臺機器都沒有歷史數據,所以zxid爲2的第二臺機器就贏了,但是此時它還沒辦法成爲leader,因爲需要>=半數的機器都投它的票纔可以.
第三臺啓動了,它跟前兩個節點通信,這個時候它的zxid=3,大於前兩個,那麼前兩個機器就會選它作爲leader,超過半數,成功當選. 牛逼
稍微懂一些了