Zookeeper的基礎知識是什么

本篇文章為大家展示了Zookeeper的基礎知識是什么，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

簡介

Apache ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，由Client和Server構成，Server提供了一致性復制和存儲服務，Client包含一個簡單的原語集，分布式應用程序可以基于它實現同步服務，配置維護和命名服務等。ZooKeeper的設計非常易于編程，ZooKeeper維護著一個hierarchal（層次）的名字空間，它采用樹形的數據結構，類似于標準文件系統。因為想要從零實現一個分布式協作服務是非常難的。最常見的問題就是競爭條件和死鎖。Apache ZooKeeper的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

Zookeepr的數據都存放在內存中（更新數據也會持久化到磁盤），所以它的吞吐量會非常高，同時延遲會很低。ZooKeeper的實現更重視high performance（高性能）, highly available（高可用性）, strictly ordered access（嚴格有序訪問）。Zookeeper性能方面的表現讓它能夠用于大型分布式系統，高可用性可以避免出現單點故障，嚴格有序訪問可以讓Client實現復雜的同步原語。

Zookeeper系統模型

上圖的哪些Server組成了Zookeeper服務，每個Server都知道彼此的存在。這些server在內存中保持著狀態的鏡像，還通過transaction logs和快照持久到硬盤中。只要集群中多數Server可訪問，那么ZooKeeper服務就可用。

Clients會連接到某一個ZooKeeper Server上。Client和Server保持一個TCP長連接，通過該TCP長連接，Client可以發送請求，得到response，得到watch event，還有發送心跳（客戶端和服務端通過心跳來保持連接，即session）。如果和Server的TCP長連接斷了，那么Client就會連接到另外一個Server上。

Zookeeper是有序的：Zookeeper用stamps(數字)作為所有事務的順序。

Zookeeper是非常快的：特別是以讀為主的情況下，Zookeeper應用程序可以運行在數千臺機器上，它性能表現最佳的是在讀寫比率為10:1的情況下。

Zookeeper數據模型

ZooKeeper數據模型的結構與Unix文件系統很類似，整體上可以看作是一棵樹，每個節點稱做一個ZNode。每個ZNode上可存儲少量數據(默認是1M, 可以通過配置修改, 通常不建議在ZNode上存儲大量的數據)，下面說說Zookeeper幾個比較重要的概念：

一，Znode

1，Zookeeper節點稱為Znode，每個節點都有唯一的路徑標示。Znode分類兩類：1，普通的Znode；2，ephemeral（臨時）Znode
2，Znode維護了stat結構，里面包含數據，ACL變更的版本號，還有時間戳去允許緩存驗證和協調更新。當znode的data改變了，版本號就會增加
3，Znode可以有子節點，并且Znode可以存放數據，但是ephemeral（臨時）Znode不能有子節點。
4，Znode數據可以有多個版本，客戶端可以根據版本獲取該節點的數據。
5，如果創建ephemeral（臨時）Znode的客戶端和服務端失去連接的話，那么該零時節點也自動刪除。
6，Znode可以自動編號。
7，Znode中可以添加watch，該watch用于監控該節點存儲的數據是否有修改，子節點目錄的變化等，一旦變化可以通知設置監控的客戶端。
8，Znode的讀寫操作都具備原子性，每個Znode都有一個訪問控制列表（ACL）來控制誰能做什么操作。

二，Session
Client與ZooKeeper之間的通信，需要創建一個Session，這個Session會有一個超時時間。因為ZooKeeper集群會把Client的Session信息持久化，所以在Session沒超時之前，Client與ZooKeeper Server的連接可以在各個ZooKeeper Server之間透明地移動。
在實際的應用中，如果Client與Server之間的通信足夠頻繁，Session的維護就不需要其它額外的消息了。否則，ZooKeeper Client會每T/3 ms發一次心跳給Server，如果Client 2T/3 ms沒收到來自Server的心跳回應，就會換到一個新的ZooKeeper Server上。這里T是用戶配置的Session的超時時間。

三，Watcher
ZooKeeper支持一種Watch操作，Client可以在某個ZNode上設置一個Watcher，來Watch該ZNode上的變化。如果該ZNode上有相應的變化，就會觸發這個Watcher，把相應的事件通知給設置Watcher的Client。需要注意的是，ZooKeeper中的Watcher是一次性的，即觸發一次就會被取消，如果想繼續Watch的話，需要客戶端重新設置Watcher。

四，事務日志和快照

dataDir目錄指定了Zookeeper的數據目錄，用于存儲Zookeeper的快照文件（snapshot）。

dataLogDir定義了Zookeeper的事務日志目錄，目錄存放Zookeeper的事務日志，正常情況下，所有的更新操作在返回客戶端更新成功前，Zookeeper肯定已經將本次更新操作寫入到事務日志了（即磁盤中）。事務日志的文件名是log.，zxid是寫入這個文件的第一個事務id。在完成若干次事務后會一次數據快照，將當前Server上所有節點的狀態以快照文件的形式dump到磁盤上去，即snapshot文件。

Zookeeper角色

Zookeepr角色分可以分為四類：

Server的狀態可以分為如下四種：

leading：當前Server為Leader。

following：當前Server為Follower。

observing：當前Server為Observer。

looking：當前Server不知道leader是誰，正在搜尋。

Zookeeper特性

順序一致性：按照客戶端發送請求的順序更新數據。Zookeeper是不屬于強一致性，因為watcher沒辦法撲捉到每次的變化。
原子性：更新要么成功，要么失敗，不會出現部分更新。
單一系統映像 ：無論客戶端連接哪個server，都會看到同一個視圖。
可靠性：具有簡單、健壯、良好的性能，如果消息被到一臺服務器接受，那么它將被所有的服務器接受。
時效性：Zookeeper保證客戶端將在一個時間間隔范圍內獲得服務器的更新數據，或者服務器失效的信息。但由于網絡延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的數據，如果需要最新數據，應該在讀數據之前調用sync()接口。

ZooKeeper原理

Zookeeper的核心是原子廣播，通過Zab協議保證各個Server之間數據的同步。Zab協議有兩種模式，分別是恢復模式（選舉Leader）和廣播模式（同步）。服務啟動或者Leader崩潰后，Zab就會進入了恢復模式，當Leader被選舉出來，且大多數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與之同步。
    OBSERVING：不選舉，只從Leader同步狀態。

Zookeeper API

Zookeeper的一個設計目標是提供簡單的編程接口，僅僅支持如下操作：

create：創建一個Znode。path是其路徑，data是要存儲在該Znode上的數據，createMode包括：PERSISTEN，PERSISTENT_SEQUENTAIL，EPHEMERAL，EPHEMERAL_SEQUENTAIL。

delete：刪除一個Znode。可以刪除指定版本的Znode，如果version設置為-1的話，就刪除所有的版本。

exists：判斷Znode是否存在，設置是否Watch這個Znode。

get data：讀取指定Znode上的數據，并設置是否watch這個Znode。

set data：更新指定Znode的數據，并設置是否Watch這個Znode。

get children：更新指定ZNode的數據，并設置是否Watch這個Znode。

sync：把sync之前的更新操作都同步過來。

set acl：設置指定ZNode的Acl信息

get acl：獲取指定ZNode的Acl信息

其他

讀、寫(更新)模式：
Zookeeper集群中，客戶端可以從任意一個ZooKeeper服務器讀取，這一特點保證了ZooKeeper有比較好的讀性能；

寫的請求會先Forwarder到Leader，然后由Leader來通過ZooKeeper中的原子廣播協議，將請求廣播給所有的Follower，Leader收到一半以上的寫成功的Ack后，就認為該寫成功了，就會將該寫進行持久化，并告訴客戶端寫成功了。

WAL(Write-Ahead-Log)和Snapshot：
ZooKeeper也有WAL，每一個更新操作，ZooKeeper都會先寫WAL，然后再對內存中的數據做更新，最后向Client通知更新結果。

ZooKeeper還會定期將內存中的目錄樹進行Snapshot，落地到磁盤上。其實跟HDFS中的fsimage和edits log是類似的。這么做的主要目的，一當然是數據的持久化，二是加快重啟之后的恢復速度，如果全部通過Replay WAL的形式恢復的話，會比較慢。

FIFO：
對于每一個ZooKeeper客戶端而言，所有的操作都是遵循FIFO順序的，這一特性是由下面兩個基本特性來保證的：

一是ZooKeeper Client與Server之間的網絡通信是基于TCP，TCP保證了Client/Server之間傳輸包的順序；

二是ZooKeeper Server執行客戶端請求也是嚴格按照FIFO順序的。

線性化：
ZooKeeper包括全局有序和偏序兩種：

全局有序是針對服務器端。例如：在一臺服務器上消息A在消息B前發布，那么所有服務器上的消息A都將在消息B前被發布；

偏序是針對客戶端。例如：在同一個客戶端發送消息B在消息A后發布，那么執行的順序必將是先執行消息A然后在是消息B；

所有的更新操作都有嚴格的偏序關系，更新操作都是串行執行的，這一點是保證ZooKeeper功能正確性的關鍵。

使用場景

1，數據發布與訂閱

2，名空間服務

3，分布式通知/協調

4，分布式鎖

5，集群管理

上述內容就是Zookeeper的基礎知識是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。