共計 3201 個字符，預計需要花費 9 分鐘才能閱讀完成。
本篇文章為大家展示了如何實現 zookeepr 分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
zk 一個分布式應用協調服務
zk 是一個分布式，開源的，分布式協調服務，他提供了一組簡單的原生接口，分布式應用可以基于它實現，高水準的同步，集群，配置管理和命名服務。它基于開發，使用簡單的原則而設計。使用類似于文件系統目錄樹結構的數據模型。它基于 java 實現，可以為 c 和 java 應用服務。
協調是個臭名昭著的活兒。很容易產生資源競爭和死鎖的問題。zk 的實現動機就是緩解分布式應用在解決彼此斜體問題而產生的抓狂行為。
zk 的設計目標
zk 是個簡單的玩意兒。zk 通過分布式的處理流程來協調應用彼此，它是使用的是一種類似文件系統的分層名字空間。這些名字空間里，包含了數據的注冊者，用 zk 的叫法，稱之為 znodes. 它類似于文件和目錄。不像傳統的文件系統，是用來存儲的，zk 的數據都在內存中，所以意味著，zk 的高吞吐量和底延時。zk 實現了一個優質的，高新能，高可用，嚴格訪問順序的服務。從 zk 的表現來看，它完全可以使用，大型，分布式系統。在可用上，也使它不會碰到單點故障的問題，嚴格的順序性，也意味著可以在客戶單實現非常復雜的同步操作。
zk 是可復制的。像它協調的應用一樣，zk 自身也復制到一系列主機上。他們是一個整體。如圖 zk server
所有組成 zk server 的 severs 必須彼此能感知對方。他們在內存里維護一個所有機器的狀態圖，在磁盤里保存有實務日志和快照。只要大多數服務器可用。zk 服務就可用。
客戶端連接到單一的服務器，通過 tcp 協議，發送請求，獲得反饋，獲得監聽事件，發送心跳包。如果連接的服務器掛掉，客戶端會連接其他的服務機器。
zk 是順序的。zk 的每次更新都會用一個數字做標簽，這個數字，代表了全部的 zk 事務順序，接下來的操作用這個順序來實現高水平的抽象，比如同步操作。
zk 是快速的。zk 在讀為主的操作中，顯得特別的快。zk 運行在上千臺機器上，當讀操作為主的請求中，表現會更好。讀寫比為 10:1。
數據模型和命名層次
zk 提供的命名空間像一個標準的文件系統。一個名字，就是它的路徑以（/）分隔的組合，在 zk 中每個節點，都已路徑來唯一標識。zk 的層次命名結構如圖
Nodes 和短命的 nodes
不像傳統的文件系統，在 zk 里每個 node 和它的孩子 node，都有數據和他們關聯。他們像個這樣一個文件系統，即每個文件也是目錄。（zk 節點里存儲的數據，包括狀態信息，配置，本地信息等，所以數據量都不大通常只有幾字節或者幾千字節），為了說清楚 zk node. 我們把它稱作 znode，znode 維護這一個數據結構，包括狀態更改的版本號，acl 更改的信息和時間戳去用和套東西區驗證和協調的更新。如果以個 node 的數據發生變化，它的版本號也會變化。比如一個客戶端讀取一個 node 數據，也會得到它的版本號。存儲在 node 里的數據讀寫都是原子的。讀會讀所有關聯的數據，寫也會替換所有的數據，不會半途而廢。每個節點都有個訪問控制列表（acl）, 嚴格限制誰能干什么！
zk 里還有個短命 node 的概念。這些 node 和創建這個節點的 session 生命一樣長。當這個 session 關閉時，這個 node 也就自動刪除了。短命 node 在你開發實現【tbd】是很重要。
有條件的更新和監控
zk 支持監控的概念，客戶端可以對一個節點進行監控，當這個節點發生變化時，監控被觸發同時被刪除，當監控被觸發，客戶端收到一個數據更改的數據包。還有當客戶端和服務端連接斷開，客戶端也會收到一個通知。這個在【tbd】中很有用。
保證
zk 簡單快速，就像他的開始的目標一樣，是構造復雜系統的基礎，比如，同步系統。實際上它有一下保證:
時序一致性：更新操作會以客戶端發送的順序被執行。
原子性：更新要么失敗，要么成功沒有部分成功的狀態。
狀態圖統一：一個客戶端無論它連接到哪個機器，所有機器圖譜一致。
可靠性：一個更新被應用，就會一直有效，直到有新的數據覆蓋。
時間線：客戶端某個時間段內看到的系統狀態圖，保證是最新的。
更多這些方面的應用，可以參看【tbd】
簡單的 api
zk 設計之初就是提供簡單的程序接口，所以，它僅僅支持一下操作：
create : 在節點樹上，創建一個節點
delete: 刪除一個節點
exists: 檢查一個節點是否存在
get data: 從一個節點獲取數據
set data：向一個節點寫數據
get children: 獲取一個節點的孩子節點
sync: 等待數據傳播同步
關于這方面的更深的技術討論，和在構建高水平應用方面的實踐，可以參考【tbd】
技術實現
下面是 zk 服務組件圖，處理請求處理器外，每個 zk 組件都有復制的多份。
每個機器上的內存數據庫，都包含整個數據，更新日志記錄到磁盤，寫操作被序列化到磁盤在它擴散同步到其他內存數據庫之前。
每個 zk 主機都對外提供服務，客戶端連接某一個主機請求服務。讀的服務從客戶連接的機器本身內存里獲取，寫服務和改變服務狀態的請求通過一個一致的協議處理。
這個一致的協議要求，所有寫請求都統一發送到一個叫 leader 的主機。剩下的被稱作 followers 的 zk 主機, 通過 leader 接收數據消息，消息層負責 leaders 的失敗替換和 leaders 和 followers 之間的同步。
zk 使用的是原子性的消息協議，因為消息是原子性的，所以能保證本地的信息與其他主機信息是一致沒有分歧的。當 leader 收到一個寫請求后，它會評估服務器狀態，決定什么時候寫，然后啟動寫事務，最后獲取服務請的新狀態。
應用
zk 的使用接口尤其的簡單，你可以通過他實現，順序操作，比如同步，群組管理等，許多分布式應有使用它，想了解更多，關注【tbd】。
表現
zk 被設計成高可用，是不是這樣呢？在 yahoo 的開發組的調查說明了它是的。當讀遠大于寫操作的時候，它表現的尤其的高性能，因為寫操作要同步所有的服務器狀態。（讀遠大于寫是經典的協調服務案例），下圖是 zk 讀寫比率變化的測試結果圖表
這個圖表的測試數據是，3.2 版本的 zk 運行在雙核 2Ghz Xeon 處理器和兩個 15k 轉速的 sata 設備上的測試數據，一個磁盤專門做 zk 日志，一個寫寫數據快照，讀寫操作都是 1k 大小，servers 表示 zk 服務，組成主機數目，接近 30 個其他主機模擬客戶機，zk 服務被配置成，leader 不允許從客戶端連接。另外說明下，3.2 讀寫性能是 3.1 版本的兩倍。
測試結果也說明了 zk 的可靠性，下圖顯示了在各種錯誤下服務器的表現，這些錯誤包含以下幾種:
1,follower 機器的當掉和恢復。
2, 另外一個 follower 的當掉和恢復。
3,leader 的當掉。
4, 兩個 follower 同時當掉。
5, 另外一個 leader 的當掉。
可用性
這個圖里顯示了，我們有 7 個主機組成的 zk 服務器，在一段時間內我們注入錯誤的系統表現。這次測試我們和以前跑同樣的訪問飽和度，有一點們把寫的比率維持在 30%，這也是我們比較保守負載比例。
從張圖里，可以看出一下重要的幾點，當 followers 掛掉并很快恢復是，zk 能保持很高的吞吐量。更重要是，leader 選舉算法能讓系統很快恢復，以保持它的高吞吐量?？梢钥吹?zk 花了不到 200ms 選舉新的 leader. 第三點，當 follower 恢復處理能力是，zk 的吞吐量又開始維持在高水平。
zookeepr 項目
zk 已經成功的在多個工業系統中應用。比如在 yahoo. 它負責協調 yahoo 的失敗恢復。上千個主題訂閱高擴展的信使服務，和數據傳輸。yahoo 的獲取服務，crawler, 也負責它的失敗恢復協調。作為 yahoo 的一員，廣告也是通過 zk 實現高可用性。
上述內容就是如何實現 zookeepr 分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注丸趣 TV 行業資訊頻道。
