【Free Style】ZooKeeper總結材料分享(一)

1??????概述

ZooKeeper是一個開源的的分布式服務框架，它是Apache Hadoop項目的一個子項目，主要用來解決分布式應用場景中存在的一些問題，如：統一命名服務、狀態同步服務、集群管理、分布式應用配置管理等，它支持Standalone模式和分布式模式，在分布式模式下，能夠為分布式應用提供高性能和可靠地協調服務，而且使用ZooKeeper可以大大簡化分布式協調服務的實現，為開發分布式應用極大地降低了成本。

1.1?????????總體架構

ZooKeeper集群由一組Server節點組成，這一組Server節點中存在一個角色為Leader的節點，其他節點都為Follower。當客戶端Client連接到ZooKeeper集群，并且執行寫請求時，這些請求會被發送到Leader節點上，然后Leader節點上數據變更會同步到集群中其他的Follower節點。

Leader節點在接收到數據變更請求后，首先將變更寫入本地磁盤，以作恢復之用。當所有的寫請求持久化到磁盤以后，才會將變更應用到內存中。

ZooKeeper使用了一種自定義的原子消息協議，在消息層的這種原子特性，保證了整個協調系統中的節點數據或狀態的一致性。Follower基于這種消息協議能夠保證本地的ZooKeeper數據與Leader節點同步，然后基于本地的存儲來獨立地對外提供服務。

當一個Leader節點發生故障失效時，失敗故障是快速響應的，消息層負責重新選擇一個Leader，繼續作為協調服務集群的中心，處理客戶端寫請求，并將ZooKeeper協調系統的數據變更同步（廣播）到其他的Follower節點。

1.2?????????常見概念

1.??在ZooKeeper集群中，每個節點共有3種角色和4種狀態：

l??角色：?leader，follower，observer

l??狀態：?leading，following，observing，looking

observer和observing是3.3版本之后引入的，他們的引入是為了解決zookeeper集群擴大后，由于網絡可靠性下降可能導致的拜占庭將軍問題。observer的行為與follower差不多，只是他們不參加選舉和投票，而僅僅接受（observing）選舉和投票的結果。

2.??節點類型：

l??Persistent Nodes：?永久有效的節點，除非client顯示的刪除，否則一直存在

l??Ephemeral Nodes：臨時節點，僅在創建該節點client保持連接期間有效，一旦連接丟失，zookeeper會自動刪除該節點

l??Sequence Nodes：順序節點，client申請創建該節點時，ZooKeeper會自動在節點路徑末尾添加遞增，這種類型是實現分布式鎖，分布式queue等特殊功能的關鍵

3.??Watch的Event類型

l??KeeperState：?Disconnected，SyncConnected，Expired

l??EventType：None，NodeCreated，NodeDeleted，NodeDataChanged，NodeChildrenChanged

1.3?????????設計要點

ZooKeeper的設計初衷

l??簡單

分布式應用中的各個進程可以通過ZooKeeper的命名空間（Namespace）來進行協調，這個命名空間是共享的、具有層次結構的，更重要的是它的結構足夠簡單，像我們平時接觸到的文件系統的目錄結構一樣容易理解，如圖所示：

在ZooKeeper中每個命名空間（Namespace）被稱為ZNode，你可以這樣理解，每個ZNode包含一個路徑和與之相關的元數據，以及繼承自該節點的孩子列表。與傳統文件系統不同的是，ZooKeeper中的數據保存在內存中，實現了分布式同步服務的高吞吐和低延遲。

在上圖示例的ZooKeeper的數據模型中，有如下要點：

1） 每個節點（ZNode）中存儲的是同步相關的數據（這是ZooKeeper設計的初衷，數據量很小，大概B到KB量級），例如狀態信息、配置內容、位置信息等

2）一個ZNode維護了一個狀態結構，該結構包括：版本號、ACL（Access Control List）變更、時間戳。每次ZNode數據發生變化，版本號都會遞增，這樣客戶端的讀請求可以基于版本號來檢索狀態相關數據

3）每個ZNode都有一個ACL，用來限制是否可以訪問該ZNode

4）在一個命名空間中，對ZNode上存儲的數據執行讀和寫請求操作都是原子的

5）客戶端可以在一個ZNode上設置一個監視器（Watch），如果該ZNode數據發生變更，ZooKeeper會通知客戶端，從而觸發監視器中實現的邏輯的執行

6）每個客戶端與ZooKeeper連接，便建立了一次會話（Session），會話過程中，可能發生CONNECTING、CONNECTED和CLOSED三種狀態

7）ZooKeeper支持臨時節點（Ephemeral Nodes）的概念，它是與ZooKeeper中的會話（Session）相關的，如果連接斷開，則該節點被刪除

l??冗余

ZooKeeper被設計為復制集群架構，每個節點的數據都可以在集群中復制傳播，使集群中的每個節點數據同步一致，從而達到服務的可靠性和可用性。前面說到，ZooKeeper將數據放在內存中來提高性能，為了避免發生單點故障（SPOF），支持數據的復制來達到冗余存儲，這是必不可少的。

l??有序

ZooKeeper使用時間戳來記錄導致狀態變更的事務性操作，也就是說，一組事務通過時間戳來保證有序性。基于這一特性。ZooKeeper可以實現更加高級的抽象操作，如同步等。

l??快速

ZooKeeper包括讀寫兩種操作，基于ZooKeeper的分布式應用，如果是讀多寫少的應用場景（讀寫比例大約是10:1），那么讀性能更能夠體現出高效。

1.4?????????數據模型

ZooKeeper有一個分層的命名空間，結構類似文件系統的目錄結構，非常簡單而直觀。其中，ZNode是最重要的概念，前面我們已經描述過。另外，有ZNode有關的還包括Watches、ACL、臨時節點、序列節點（Sequence Node）。

l??ZNODE

ZooKeeper中使用Zxid（ZooKeeper Transaction Id）來表示每次節點數據變更，一個Zxid與一個時間戳對應，所以多個不同的變更對應的事務是有序的。下面是ZNode的組成結構，引用文檔如下所示：

o????czxid – The zxid of the change that caused this znode to be created.

o????mzxid – The zxid of the change that last modified this znode.

o????ctime – The time in milliseconds from epoch when this znode was created.

o????mtime – The time in milliseconds from epoch when this znode was last modified.

o????version – The number of changes to the data of this znode.

o????cversion – The number of changes to the children of this znode.

o????aversion – The number of changes to the ACL of this znode.

o????ephemeralOwner – The session id of the owner of this znode if the znode is an ephemeral node. If it is not an ephemeral node, it will be zero.

o????dataLength – The length of the data field of this znode.

o????numChildren – The number of children of this znode.

（1）znode中的數據可以有多個版本，在查詢該znode數據時就需要帶上版本信息。如：set path version / delete path version

（2）znode可以是臨時znode，由create -e?生成的節點，一旦創建這個znode的client與server斷開連接，該znode將被自動刪除。

client和server之間通過heartbeat來確認連接正常，這種狀態稱之為session，斷開連接后session失效。

（3）臨時znode不能有子znode。

（4）znode可以自動編號，由create -s?生成的節點，例如在?create -s /app/node?已存在時，將會生成/app/node00***001節點。

（5）znode可以被監控，該目錄下某些信息的修改，例如節點數據、子節點變化等，可以主動通知監控注冊的client。事實上，通過這個特性，可以完成許多重要應用，例如配置管理、信息同步、分布式鎖等等。

l??Watches?（監視）

ZooKeeper中的Watch是只能觸發一次（觸發的同時會刪除這個監視）。也就是說，如果客戶端在指定的ZNode設置了Watch，如果該ZNode數據發生變更，ZooKeeper會發送一個變更通知給客戶端，同時觸發設置的Watch事件。如果ZNode數據又發生了變更，客戶端在收到第一次通知后沒有重新設置該ZNode的Watch，則ZooKeeper就不會發送一個變更通知給客戶端。

ZooKeeper異步通知設置Watch的客戶端。但是ZooKeeper能夠保證在ZNode的變更生效之后才會異步地通知客戶端，然后客戶端才能夠看到ZNode的數據變更。由于網絡延遲，多個客戶端可能會在不同的時間看到ZNode數據的變更，但是看到變更的順序是能夠保證有序一致的。

ZNode可以設置兩類Watch，一個是Data Watches（該ZNode的數據變更導致觸發Watch事件），另一個是Child Watches（該ZNode的孩子節點發生變更導致觸發Watch事件）。

調用getData()和exists()?方法可以設置Data Watches，

調用getChildren()方法可以設置Child Watches。

調用setData()方法觸發在該ZNode的注冊的Data Watches。

調用create()方法創建一個ZNode，將觸發該ZNode的Data Watches；

調用create()方法創建ZNode的孩子節點，則觸發ZNode的Child Watches。

調用delete()方法刪除ZNode，則同時觸發Data Watches和Child Watches，如果該被刪除的ZNode還有父節點，則父節點觸發一個Child Watches。

另外，如果客戶端與ZooKeeper Server斷開連接，客戶端就無法觸發Watches，除非再次與ZooKeeper Server建立連接。

l??Sequence Nodes?（序列節點）

在創建ZNode的時候，可以請求ZooKeeper生成序列，以路徑名為前綴，計數器緊接在路徑名后面，例如，會生成類似如下形式序列：

對于ZNode的父節點來說，序列中的每個計數器字符串都是唯一的，最大值為2147483647?（0x7fff ffff）

l??ACLs（訪問控制列表）

ACL可以控制訪問ZooKeeper的節點，只能應用于特定的ZNode上，而不能應用于該ZNode的所有孩子節點上。它主要有如下五種權限：

o????CREATE?允許創建Child Nodes

o????READ?允許獲取ZNode的數據，以及該節點的孩子列表

o????WRITE?可以修改ZNode的數據

o????DELETE?可以刪除一個孩子節點

o????ADMIN?可以設置權限

ZooKeeper內置了4種方式實現ACL：

o????world?一個單獨的ID，表示任何人都可以訪問

o????auth?不使用ID，只有認證的用戶可以訪問

o????digest?使用username:password生成MD5哈希值作為認證ID

o????ip?使用客戶端主機IP地址來進行認證

l??ZooKeeeper Session

當客戶端連接到ZooKeeper集群時，建立了會話。會話過程中的狀態變遷，如圖所示：

建立連接過程中，會話狀態為CONNECTING；當連接建立成功后，會話狀態變為CONNECTED。會話過程中，如果正常的話，會話的狀態只能是CONNECTING和CONNECTED二者之一。如果在會話過程中連接斷開，則變為CLOSED狀態。

1.5??????????應用陷阱

并非任何分布式應用都適合使用ZooKeeper來構建協調服務，我們根據ZooKeeper提供的文檔，給出哪些情況下使用會出現問題，又是如何應對這種問題的。總結如下：

1.????丟失ZNode上的變更通知

客戶端連接到ZooKeeper Server以后，會維護一個TCP連接。在CONNECTED狀態下，客戶端設置了某個ZNode的Watch-，可以收到來自該節點變更的通知（后續會觸發一定的邏輯執行流程）。但是，如果由于網絡異常，客戶端斷開了與ZooKeeper Server的連接，在斷開的過程中，是無法收到ZooKeeper在ZNode上發送的節點數據變更通知的。

所以，如果使用ZooKeeper的Watch，必須要尋找保持CONNECTED的Watch，才能保證不會丟失該Watch監控的ZNode上的數據變更通知。

2.????無效ZooKeeper集群節點列表

與ZooKeeper集群 交 互時，一般情況下客戶端會持有一個ZooKeeper集群節點的列表，或者列表的子集，那么會存在如下兩種情況：

一種情況是，如果客戶端持有的列表或者列表子集，其中節點都處于Active狀態，能夠提供協調服務，那么客戶端訪問ZooKeeper集群沒有任何問題。

另一種情況，客戶端持有ZooKeeper集群節點列表或列表子集，如果列表中的某些節點因為故障退出了集群，如果客戶端再次連接這一類失效的節點，就無法獲取服務。

所以，我們在應用中使用ZooKeeper集群時，一定要明確這一點，或者跳過無效的節點，或者重新尋找有效的節點繼續業務處理，或者檢查ZooKeeper集群，使整個集群恢復正常。

3.????配置導致的性能問題

如果設置Java堆內存（Heap）不合理，會導致ZooKeeper內存不足，會在內存與文件系統之間進行數據交換，導致ZooKeeper的性能極大地下降，從而可能會影響應用程序。

為了避免Swapping問題的出現，主要考慮設置足夠的Java堆內存，同時減少被 操 作系統和Cache使用的內存，盡量避免在內存與文件系統之間發生數據交換，或者可以將交換限制在一定的范圍之內。

4.????事務日志存儲設備性能

ZooKeeper會同步事務到存儲設備，如果存儲設備不是專用的，而是和其他I/O密集型應用共享同一磁盤，會降低ZooKeeper的效率。因為客戶端請求ZNode數據變更而發生的事務，ZooKeeper會在響應之前將事務日志寫入存儲設備，如果存儲設備是專用的，那么整個服務以至外部應用都會獲得極大地性能提升。

5.????ZNode存儲大量數據導致性能問題

ZooKeeper的設計初衷是，每個ZNode只存放少量的同步數據，如果存儲了大量數據，導致ZooKeeper每次節點發生變更時需要將事務寫入存儲設備，同時還要在集群內部復制傳播，這將導致不可避免的延遲和性能問題。

所以，如果需要與大量的數據相關，可以將大量數據存儲在其他設備中，而只是在ZooKeeper中存儲一個簡單的映射，如指針、引用等等。

1.6?????????API接口

這里只描述具體的功能接口

l??create

創建一個節點（node）

l??delete

刪除一個節點

l??exists

測試一個節點是否存在

l??get data

從一個節點中讀數據

l??set data

向一個節點寫數據

l??get children

獲取子節點列表

l??sync

等待數據的同步

1.7?????????集群的組件

在ZooKeeper集群當中，集群中的服務器角色有兩種Leader和Learner，Learner角色又分為Observer和Follower，具體功能如下：

1.領導者(leader)，負責進行投票的發起和決議，更新系統狀態

2.學習者(learner)，包括跟隨者（follower）和觀察者（observer），

3.follower用于接受客戶端請求并向客戶端返回結果，在選主過程中參與投票

4.Observer可以接受客戶端請求，將寫請求轉發給leader，但observer不參加投票過程，只同步leader的狀態，observer的目的是為了擴展系統，提高讀取速度。

5.?客戶端(client)，請求發起方

ZooKeeper的組件圖中給出了ZooKeeper服務的高層次的組件。除了請求處理器（requestprocessor）外，構成ZooKeeper服務的每個服務器都有一個備份。復制的數據庫（replicateddatabase）是一個內存數據庫，包含整個數據樹。為了可恢復，更新會被log到磁盤，并且在更新這個內存數據庫之前，先序列化到磁盤。

每個ZooKeeper都為客戶端提供服務。客戶端只連接到一個服務器，并提交請求。讀請求直接由本地的復制數據庫提供數據。對服務狀態進行修改的請求、寫請求通過一個約定的協議進行通訊。

作為這個協議的一部分，所有的寫請求都被傳送到leader服務器，而其他的服務器，叫做followers，follower從leader接收信息修改的提議，并同意進行。當leader發生故障時，協議的信息層（messaginglayer）關注leader的替換，并同步到所有的follower。

ZooKeeper采用一個自定義的信息原子操作協議，由于信息層的操作是原子性的，ZooKeeper能保證本地的復制數據庫不會產生不一致。當leader接收到一個寫請求，它計算出寫之后系統的狀態，把它變成一個事務。

1.8?????????其它用途

ZooKeeper本身的接口很簡單，用戶可以實現高層的抽象操作。如同步原語，group membership，ownership等。

1.9?????????性能

ZooKeeper適合于讀比寫多的場景

上圖展示橫軸是讀的占比，縱軸是吞吐率。

測試版本為3.2，硬件環境為雙核?2G Xeon，兩個15000轉的硬盤

1.10?????可靠性

上圖ZooKeeper由7臺機器組成，并故意注入兩個失敗。橫軸是實間線，縱軸是吞吐率（寫占比為30%）。

一般選舉一個新的leader大概需要200ms左右的時間。

1.11?????業界使用公司

官網上主推雅虎。

因字數限制，下篇接著分享~~~

ZooKeeper

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。