溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“zookeeper基礎知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“zookeeper基礎知識點有哪些”吧!
ZooKeeper 的設計目標是將那些復雜且容易出錯的分布式一致性服務封裝起來，構成一個高效可靠的原語集，并以一系列簡單易用的接口提供給用戶使用。
ZooKeeper 是一個典型的分布式數據一致性解決方案，分布式應用程序可以基于 ZooKeeper 實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能。
Zookeeper 一個最常用的使用場景就是用于擔任服務生產者和服務消費者的注冊中心。（如：Dubbo中zookeeper擔任注冊中心的角色）
Zookeeper本身就是一個分布式程序（只要半數以上節點存活，Zookeeper就能正常服務）
為了保證高可用，最好是以集群形態來部署Zookeeper，這樣只要集群中大部分機器可用，那么Zookeeper本身仍然是可用的
zookeeper將數據保存在內存中，這也就保證了高吞吐量和低延遲（但是內存限制了能夠存儲的容量不太大，此限制也是保持）
zookeeper是高性能的。在“讀”多于“寫”的應用程序中尤其地高性能，因為“寫”會導致所有的服務器間同步狀態。
zookeeper有臨時節點的概念。當創建臨時節點的客戶端會話一直保持活動，瞬時節點就一直存在。而當會話終結時，瞬時節點刪除。持久節點是指一旦這個znode被創建了，除非主動進行znode的移除操作，否則這個znode將一直保存在zookeeper上
zookeeper底層其實只提供了兩個功能：1、管理（存儲、讀取）用戶程序提交的數據 2、為用戶程序提交數據及節點監聽服務
Session 指的是 ZooKeeper 服務器與客戶端會話。在 ZooKeeper 中，一個客戶端連接是指客戶端和服務器之間的一個 TCP 長連接。客戶端啟動的時候，首先會與服務器建立一個 TCP 連接，從第一次連接建立開始，客戶端會話的生命周期也開始了。通過這個連接，客戶端能夠通過心跳檢測與服務器保持有效的會話，也能夠向Zookeeper服務器發送請求并接受響應，同時還能夠通過該連接接收來自服務器的Watch事件通知。 Session的sessionTimeout值用來設置一個客戶端會話的超時時間。當由于服務器壓力太大、網絡故障或是客戶端主動斷開連接等各種原因導致客戶端連接斷開時，只要在sessionTimeout規定的時間內能夠重新連接上集群中任意一臺服務器，那么之前創建的會話仍然有效。
** 在為客戶端創建會話之前，服務端首先會為每個客戶端都分配一個sessionID。由于 sessionID 是 Zookeeper 會話的一個重要標識，許多與會話相關的運行機制都是基于這個 sessionID 的，因此，無論是哪臺服務器為客戶端分配的 sessionID，都務必保證全局唯一。
在談到分布式的時候，我們通常說的“節點"是指組成集群的每一臺機器。然而，在Zookeeper中，“節點"分為兩類，第一類同樣是指構成集群的機器，我們稱之為機器節點；第二類則是指數據模型中的數據單元，我們稱之為數據節點一一ZNode。
Zookeeper將所有數據存儲在內存中，數據模型是一棵樹（Znode Tree)，由斜杠（/）的進行分割的路徑，就是一個Znode，例如/foo/path2。每個上都會保存自己的數據內容，同時還會保存一系列屬性信息。
在Zookeeper中，node可以分為持久節點和臨時節點兩類。所謂持久節點是指一旦這個ZNode被創建了，除非主動進行ZNode的移除操作，否則這個ZNode將一直保存在Zookeeper上。而臨時節點就不一樣了，它的生命周期和客戶端會話綁定，一旦客戶端會話失效，那么這個客戶端創建的所有臨時節點都會被移除。另外，ZooKeeper還允許用戶為每個節點添加一個特殊的屬性：SEQUENTIAL.一旦節點被標記上這個屬性，那么在這個節點被創建的時候，Zookeeper會自動在其節點名后面追加上一個整型數字，這個整型數字是一個由父節點維護的自增數字。
在前面我們已經提到，Zookeeper 的每個 ZNode 上都會存儲數據，對應于每個ZNode，Zookeeper 都會為其維護一個叫作 Stat 的數據結構，Stat中記錄了這個 ZNode 的三個數據版本，分別是version（當前ZNode的版本）、cversion（當前ZNode子節點的版本）和 aversion（當前ZNode的ACL版本）。
Watcher（事件監聽器），是Zookeeper中的一個很重要的特性。Zookeeper允許用戶在指定節點上注冊一些Watcher，并且在一些特定事件觸發的時候，ZooKeeper服務端會將事件通知到感興趣的客戶端上去，該機制是Zookeeper實現分布式協調服務的重要特性。
Zookeeper采用ACL（AccessControlLists）策略來進行權限控制，類似于 UNIX 文件系統的權限控制。Zookeeper 定義了如下5種權限。
其中尤其需要注意的是，CREATE和DELETE這兩種權限都是針對子節點的權限控制。
順序一致性： 從同一客戶端發起的事務請求，最終將會嚴格地按照順序被應用到 ZooKeeper 中去。
原子性： 所有事務請求的處理結果在整個集群中所有機器上的應用情況是一致的，也就是說，要么整個集群中所有的機器都成功應用了某一個事務，要么都沒有應用。
單一系統映像 ： 無論客戶端連到哪一個 ZooKeeper 服務器上，其看到的服務端數據模型都是一致的。
可靠性： 一旦一次更改請求被應用，更改的結果就會被持久化，直到被下一次更改覆蓋。
ZooKeeper 允許分布式進程通過共享的層次結構命名空間進行相互協調，這與標準文件系統類似。 名稱空間由 ZooKeeper 中的數據寄存器組成 - 稱為znode，這些類似于文件和目錄。 與為存儲設計的典型文件系統不同，ZooKeeper數據保存在內存中，這意味著ZooKeeper可以實現高吞吐量和低延遲。
為了保證高可用，最好是以集群形態來部署 ZooKeeper，這樣只要集群中大部分機器是可用的（能夠容忍一定的機器故障），那么zookeeper本身仍然是可用的。 客戶端在使用 ZooKeeper 時，需要知道集群機器列表，通過與集群中的某一臺機器建立 TCP 連接來使用服務，客戶端使用這個TCP鏈接來發送請求、獲取結果、獲取監聽事件以及發送心跳包。如果這個連接異常斷開了，客戶端可以連接到另外的機器上。
**ZooKeeper 官方提供的架構圖：
上圖中每一個Server代表一個安裝Zookeeper服務的服務器。組成 ZooKeeper 服務的服務器都會在內存中維護當前的服務器狀態，并且每臺服務器之間都互相保持著通信。集群間通過 Zab 協議（Zookeeper Atomic Broadcast）來保持數據的一致性。
對于來自客戶端的每個更新請求，ZooKeeper 都會分配一個全局唯一的遞增編號，這個編號反應了所有事務操作的先后順序，應用程序可以使用 ZooKeeper 這個特性來實現更高層次的同步原語。 這個編號也叫做時間戳——zxid（Zookeeper Transaction Id）
ZooKeeper 是高性能的。 在“讀”多于“寫”的應用程序中尤其地高性能，因為“寫”會導致所有的服務器間同步狀態。（“讀”多于“寫”是協調服務的典型場景。）
最典型集群模式： Master/Slave 模式（主備模式）。在這種模式中，通常 Master服務器作為主服務器提供寫服務，其他的 Slave 服務器從服務器通過異步復制的方式獲取 Master 服務器最新的數據提供讀服務。
但是，在 ZooKeeper 中沒有選擇傳統的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三種角色。如下圖所示
ZooKeeper 集群中的所有機器通過一個 Leader 選舉過程來選定一臺稱為 “Leader” 的機器，Leader 既可以為客戶端提供寫服務又能提供讀服務。除了 Leader 外，Follower 和 Observer 都只能提供讀服務。Follower 和 Observer 唯一的區別在于 Observer 機器不參與 Leader 的選舉過程，也不參與寫操作的“過半寫成功”策略，因此 Observer 機器可以在不影響寫性能的情況下提升集群的讀性能。
Paxos 算法應該可以說是 ZooKeeper 的靈魂了。但是，ZooKeeper 并沒有完全采用 Paxos算法 ，而是使用 ZAB 協議作為其保證數據一致性的核心算法。另外，在ZooKeeper的官方文檔中也指出，ZAB協議并不像 Paxos 算法那樣，是一種通用的分布式一致性算法，它是一種特別為Zookeeper設計的崩潰可恢復的原子消息廣播算法。
ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協議是為分布式協調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協議。 在 ZooKeeper 中，主要依賴 ZAB 協議來實現分布式數據一致性，基于該協議，ZooKeeper 實現了一種主備模式的系統架構來保持集群中各個副本之間的數據一致性。
ZAB協議包括兩種基本的模式，分別是 崩潰恢復和消息廣播。當整個服務框架在啟動過程中，或是當 Leader 服務器出現網絡中斷、崩潰退出與重啟等異常情況時，ZAB 協議就會進人恢復模式并選舉產生新的Leader服務器。當選舉產生了新的 Leader 服務器，同時集群中已經有過半的機器與該Leader服務器完成了狀態同步之后，ZAB協議就會退出恢復模式。其中，所謂的狀態同步是指數據同步，用來保證集群中存在過半的機器能夠和Leader服務器的數據狀態保持一致。
當集群中已經有過半的Follower服務器完成了和Leader服務器的狀態同步，那么整個服務框架就可以進人消息廣播模式了。 當一臺同樣遵守ZAB協議的服務器啟動后加人到集群中時，如果此時集群中已經存在一個Leader服務器在負責進行消息廣播，那么新加人的服務器就會自覺地進人數據恢復模式：找到Leader所在的服務器，并與其進行數據同步，然后一起參與到消息廣播流程中去。正如上文介紹中所說的，ZooKeeper設計成只允許唯一的一個Leader服務器來進行事務請求的處理。Leader服務器在接收到客戶端的事務請求后，會生成對應的事務提案并發起一輪廣播協議；而如果集群中的其他機器接收到客戶端的事務請求，那么這些非Leader服務器會首先將這個事務請求轉發給Leader服務器。
到此，相信大家對“zookeeper基礎知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
