zookeeper基礎(chǔ)知識(shí)點(diǎn)有哪些

本篇內(nèi)容主要講解“zookeeper基礎(chǔ)知識(shí)點(diǎn)有哪些”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“zookeeper基礎(chǔ)知識(shí)點(diǎn)有哪些”吧!

一、zookeeper的概念

1、Zookeeper的基礎(chǔ)概念

• ZooKeeper 的設(shè)計(jì)目標(biāo)是將那些復(fù)雜且容易出錯(cuò)的分布式一致性服務(wù)封裝起來(lái)，構(gòu)成一個(gè)高效可靠的原語(yǔ)集，并以一系列簡(jiǎn)單易用的接口提供給用戶使用。

• ZooKeeper 是一個(gè)典型的分布式數(shù)據(jù)一致性解決方案，分布式應(yīng)用程序可以基于 ZooKeeper 實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集群管理、Master 選舉、分布式鎖和分布式隊(duì)列等功能。

• Zookeeper 一個(gè)最常用的使用場(chǎng)景就是用于擔(dān)任服務(wù)生產(chǎn)者和服務(wù)消費(fèi)者的注冊(cè)中心。（如：Dubbo中zookeeper擔(dān)任注冊(cè)中心的角色）

2、Zookeeper重要概念：

• Zookeeper本身就是一個(gè)分布式程序（只要半數(shù)以上節(jié)點(diǎn)存活，Zookeeper就能正常服務(wù)）

• 為了保證高可用，最好是以集群形態(tài)來(lái)部署Zookeeper，這樣只要集群中大部分機(jī)器可用，那么Zookeeper本身仍然是可用的

• zookeeper將數(shù)據(jù)保存在內(nèi)存中，這也就保證了高吞吐量和低延遲（但是內(nèi)存限制了能夠存儲(chǔ)的容量不太大，此限制也是保持）

• zookeeper是高性能的。在“讀”多于“寫(xiě)”的應(yīng)用程序中尤其地高性能，因?yàn)椤皩?xiě)”會(huì)導(dǎo)致所有的服務(wù)器間同步狀態(tài)。

• zookeeper有臨時(shí)節(jié)點(diǎn)的概念。當(dāng)創(chuàng)建臨時(shí)節(jié)點(diǎn)的客戶端會(huì)話一直保持活動(dòng)，瞬時(shí)節(jié)點(diǎn)就一直存在。而當(dāng)會(huì)話終結(jié)時(shí)，瞬時(shí)節(jié)點(diǎn)刪除。持久節(jié)點(diǎn)是指一旦這個(gè)znode被創(chuàng)建了，除非主動(dòng)進(jìn)行znode的移除操作，否則這個(gè)znode將一直保存在zookeeper上

• zookeeper底層其實(shí)只提供了兩個(gè)功能：1、管理（存儲(chǔ)、讀?。┯脩舫绦蛱峤坏臄?shù)據(jù) 2、為用戶程序提交數(shù)據(jù)及節(jié)點(diǎn)監(jiān)聽(tīng)服務(wù)

3、會(huì)話（Session）

Session 指的是 ZooKeeper 服務(wù)器與客戶端會(huì)話。在 ZooKeeper 中，一個(gè)客戶端連接是指客戶端和服務(wù)器之間的一個(gè) TCP 長(zhǎng)連接?？蛻舳藛?dòng)的時(shí)候，首先會(huì)與服務(wù)器建立一個(gè) TCP 連接，從第一次連接建立開(kāi)始，客戶端會(huì)話的生命周期也開(kāi)始了。通過(guò)這個(gè)連接，客戶端能夠通過(guò)心跳檢測(cè)與服務(wù)器保持有效的會(huì)話，也能夠向Zookeeper服務(wù)器發(fā)送請(qǐng)求并接受響應(yīng)，同時(shí)還能夠通過(guò)該連接接收來(lái)自服務(wù)器的Watch事件通知。 Session的sessionTimeout值用來(lái)設(shè)置一個(gè)客戶端會(huì)話的超時(shí)時(shí)間。當(dāng)由于服務(wù)器壓力太大、網(wǎng)絡(luò)故障或是客戶端主動(dòng)斷開(kāi)連接等各種原因?qū)е驴蛻舳诉B接斷開(kāi)時(shí)，只要在sessionTimeout規(guī)定的時(shí)間內(nèi)能夠重新連接上集群中任意一臺(tái)服務(wù)器，那么之前創(chuàng)建的會(huì)話仍然有效。

** 在為客戶端創(chuàng)建會(huì)話之前，服務(wù)端首先會(huì)為每個(gè)客戶端都分配一個(gè)sessionID。由于 sessionID 是 Zookeeper 會(huì)話的一個(gè)重要標(biāo)識(shí)，許多與會(huì)話相關(guān)的運(yùn)行機(jī)制都是基于這個(gè) sessionID 的，因此，無(wú)論是哪臺(tái)服務(wù)器為客戶端分配的 sessionID，都務(wù)必保證全局唯一。

4、Znode

在談到分布式的時(shí)候，我們通常說(shuō)的“節(jié)點(diǎn)"是指組成集群的每一臺(tái)機(jī)器。然而，在Zookeeper中，“節(jié)點(diǎn)"分為兩類，第一類同樣是指構(gòu)成集群的機(jī)器，我們稱之為機(jī)器節(jié)點(diǎn)；第二類則是指數(shù)據(jù)模型中的數(shù)據(jù)單元，我們稱之為數(shù)據(jù)節(jié)點(diǎn)一一ZNode。

Zookeeper將所有數(shù)據(jù)存儲(chǔ)在內(nèi)存中，數(shù)據(jù)模型是一棵樹(shù)（Znode Tree)，由斜杠（/）的進(jìn)行分割的路徑，就是一個(gè)Znode，例如/foo/path2。每個(gè)上都會(huì)保存自己的數(shù)據(jù)內(nèi)容，同時(shí)還會(huì)保存一系列屬性信息。

在Zookeeper中，node可以分為持久節(jié)點(diǎn)和臨時(shí)節(jié)點(diǎn)兩類。所謂持久節(jié)點(diǎn)是指一旦這個(gè)ZNode被創(chuàng)建了，除非主動(dòng)進(jìn)行ZNode的移除操作，否則這個(gè)ZNode將一直保存在Zookeeper上。而臨時(shí)節(jié)點(diǎn)就不一樣了，它的生命周期和客戶端會(huì)話綁定，一旦客戶端會(huì)話失效，那么這個(gè)客戶端創(chuàng)建的所有臨時(shí)節(jié)點(diǎn)都會(huì)被移除。另外，ZooKeeper還允許用戶為每個(gè)節(jié)點(diǎn)添加一個(gè)特殊的屬性：SEQUENTIAL.一旦節(jié)點(diǎn)被標(biāo)記上這個(gè)屬性，那么在這個(gè)節(jié)點(diǎn)被創(chuàng)建的時(shí)候，Zookeeper會(huì)自動(dòng)在其節(jié)點(diǎn)名后面追加上一個(gè)整型數(shù)字，這個(gè)整型數(shù)字是一個(gè)由父節(jié)點(diǎn)維護(hù)的自增數(shù)字。

5、 版本

在前面我們已經(jīng)提到，Zookeeper 的每個(gè) ZNode 上都會(huì)存儲(chǔ)數(shù)據(jù)，對(duì)應(yīng)于每個(gè)ZNode，Zookeeper 都會(huì)為其維護(hù)一個(gè)叫作 Stat 的數(shù)據(jù)結(jié)構(gòu)，Stat中記錄了這個(gè) ZNode 的三個(gè)數(shù)據(jù)版本，分別是version（當(dāng)前ZNode的版本）、cversion（當(dāng)前ZNode子節(jié)點(diǎn)的版本）和 aversion（當(dāng)前ZNode的ACL版本）。

6、 Watcher

Watcher（事件監(jiān)聽(tīng)器），是Zookeeper中的一個(gè)很重要的特性。Zookeeper允許用戶在指定節(jié)點(diǎn)上注冊(cè)一些Watcher，并且在一些特定事件觸發(fā)的時(shí)候，ZooKeeper服務(wù)端會(huì)將事件通知到感興趣的客戶端上去，該機(jī)制是Zookeeper實(shí)現(xiàn)分布式協(xié)調(diào)服務(wù)的重要特性。

7、 ACL

Zookeeper采用ACL（AccessControlLists）策略來(lái)進(jìn)行權(quán)限控制，類似于 UNIX 文件系統(tǒng)的權(quán)限控制。Zookeeper 定義了如下5種權(quán)限。

其中尤其需要注意的是，CREATE和DELETE這兩種權(quán)限都是針對(duì)子節(jié)點(diǎn)的權(quán)限控制。

二、ZooKeeper 特點(diǎn)

• 順序一致性： 從同一客戶端發(fā)起的事務(wù)請(qǐng)求，最終將會(huì)嚴(yán)格地按照順序被應(yīng)用到 ZooKeeper 中去。

• 原子性： 所有事務(wù)請(qǐng)求的處理結(jié)果在整個(gè)集群中所有機(jī)器上的應(yīng)用情況是一致的，也就是說(shuō)，要么整個(gè)集群中所有的機(jī)器都成功應(yīng)用了某一個(gè)事務(wù)，要么都沒(méi)有應(yīng)用。

• 單一系統(tǒng)映像 ： 無(wú)論客戶端連到哪一個(gè) ZooKeeper 服務(wù)器上，其看到的服務(wù)端數(shù)據(jù)模型都是一致的。

• 可靠性： 一旦一次更改請(qǐng)求被應(yīng)用，更改的結(jié)果就會(huì)被持久化，直到被下一次更改覆蓋。

三、ZooKeeper 設(shè)計(jì)目標(biāo)

3.1 簡(jiǎn)單的數(shù)據(jù)模型

ZooKeeper 允許分布式進(jìn)程通過(guò)共享的層次結(jié)構(gòu)命名空間進(jìn)行相互協(xié)調(diào)，這與標(biāo)準(zhǔn)文件系統(tǒng)類似。 名稱空間由 ZooKeeper 中的數(shù)據(jù)寄存器組成 - 稱為znode，這些類似于文件和目錄。 與為存儲(chǔ)設(shè)計(jì)的典型文件系統(tǒng)不同，ZooKeeper數(shù)據(jù)保存在內(nèi)存中，這意味著ZooKeeper可以實(shí)現(xiàn)高吞吐量和低延遲。

3.2 可構(gòu)建集群

為了保證高可用，最好是以集群形態(tài)來(lái)部署 ZooKeeper，這樣只要集群中大部分機(jī)器是可用的（能夠容忍一定的機(jī)器故障），那么zookeeper本身仍然是可用的。 客戶端在使用 ZooKeeper 時(shí)，需要知道集群機(jī)器列表，通過(guò)與集群中的某一臺(tái)機(jī)器建立 TCP 連接來(lái)使用服務(wù)，客戶端使用這個(gè)TCP鏈接來(lái)發(fā)送請(qǐng)求、獲取結(jié)果、獲取監(jiān)聽(tīng)事件以及發(fā)送心跳包。如果這個(gè)連接異常斷開(kāi)了，客戶端可以連接到另外的機(jī)器上。

**ZooKeeper 官方提供的架構(gòu)圖：

上圖中每一個(gè)Server代表一個(gè)安裝Zookeeper服務(wù)的服務(wù)器。組成 ZooKeeper 服務(wù)的服務(wù)器都會(huì)在內(nèi)存中維護(hù)當(dāng)前的服務(wù)器狀態(tài)，并且每臺(tái)服務(wù)器之間都互相保持著通信。集群間通過(guò) Zab 協(xié)議（Zookeeper Atomic Broadcast）來(lái)保持?jǐn)?shù)據(jù)的一致性。

3.3 順序訪問(wèn)

對(duì)于來(lái)自客戶端的每個(gè)更新請(qǐng)求，ZooKeeper 都會(huì)分配一個(gè)全局唯一的遞增編號(hào)，這個(gè)編號(hào)反應(yīng)了所有事務(wù)操作的先后順序，應(yīng)用程序可以使用 ZooKeeper 這個(gè)特性來(lái)實(shí)現(xiàn)更高層次的同步原語(yǔ)。 這個(gè)編號(hào)也叫做時(shí)間戳——zxid（Zookeeper Transaction Id）

3.4 高性能

ZooKeeper 是高性能的。 在“讀”多于“寫(xiě)”的應(yīng)用程序中尤其地高性能，因?yàn)椤皩?xiě)”會(huì)導(dǎo)致所有的服務(wù)器間同步狀態(tài)。（“讀”多于“寫(xiě)”是協(xié)調(diào)服務(wù)的典型場(chǎng)景。）

四 ZooKeeper 集群角色介紹

最典型集群模式： Master/Slave 模式（主備模式）。在這種模式中，通常 Master服務(wù)器作為主服務(wù)器提供寫(xiě)服務(wù)，其他的 Slave 服務(wù)器從服務(wù)器通過(guò)異步復(fù)制的方式獲取 Master 服務(wù)器最新的數(shù)據(jù)提供讀服務(wù)。

但是，在 ZooKeeper 中沒(méi)有選擇傳統(tǒng)的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三種角色。如下圖所示

ZooKeeper 集群中的所有機(jī)器通過(guò)一個(gè) Leader 選舉過(guò)程來(lái)選定一臺(tái)稱為 “Leader” 的機(jī)器，Leader 既可以為客戶端提供寫(xiě)服務(wù)又能提供讀服務(wù)。除了 Leader 外，F(xiàn)ollower 和 Observer 都只能提供讀服務(wù)。Follower 和 Observer 唯一的區(qū)別在于 Observer 機(jī)器不參與 Leader 的選舉過(guò)程，也不參與寫(xiě)操作的“過(guò)半寫(xiě)成功”策略，因此 Observer 機(jī)器可以在不影響寫(xiě)性能的情況下提升集群的讀性能。

五 ZooKeeper &ZAB 協(xié)議&Paxos算法

5.1 ZAB 協(xié)議&Paxos算法

Paxos 算法應(yīng)該可以說(shuō)是 ZooKeeper 的靈魂了。但是，ZooKeeper 并沒(méi)有完全采用 Paxos算法 ，而是使用 ZAB 協(xié)議作為其保證數(shù)據(jù)一致性的核心算法。另外，在ZooKeeper的官方文檔中也指出，ZAB協(xié)議并不像 Paxos 算法那樣，是一種通用的分布式一致性算法，它是一種特別為Zookeeper設(shè)計(jì)的崩潰可恢復(fù)的原子消息廣播算法。

5.2 ZAB 協(xié)議介紹

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協(xié)議是為分布式協(xié)調(diào)服務(wù) ZooKeeper 專門(mén)設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議。 在 ZooKeeper 中，主要依賴 ZAB 協(xié)議來(lái)實(shí)現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，ZooKeeper 實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來(lái)保持集群中各個(gè)副本之間的數(shù)據(jù)一致性。

5.3 ZAB 協(xié)議兩種基本的模式：崩潰恢復(fù)和消息廣播

ZAB協(xié)議包括兩種基本的模式，分別是 崩潰恢復(fù)和消息廣播。當(dāng)整個(gè)服務(wù)框架在啟動(dòng)過(guò)程中，或是當(dāng) Leader 服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出與重啟等異常情況時(shí)，ZAB 協(xié)議就會(huì)進(jìn)人恢復(fù)模式并選舉產(chǎn)生新的Leader服務(wù)器。當(dāng)選舉產(chǎn)生了新的 Leader 服務(wù)器，同時(shí)集群中已經(jīng)有過(guò)半的機(jī)器與該Leader服務(wù)器完成了狀態(tài)同步之后，ZAB協(xié)議就會(huì)退出恢復(fù)模式。其中，所謂的狀態(tài)同步是指數(shù)據(jù)同步，用來(lái)保證集群中存在過(guò)半的機(jī)器能夠和Leader服務(wù)器的數(shù)據(jù)狀態(tài)保持一致。

當(dāng)集群中已經(jīng)有過(guò)半的Follower服務(wù)器完成了和Leader服務(wù)器的狀態(tài)同步，那么整個(gè)服務(wù)框架就可以進(jìn)人消息廣播模式了。 當(dāng)一臺(tái)同樣遵守ZAB協(xié)議的服務(wù)器啟動(dòng)后加人到集群中時(shí)，如果此時(shí)集群中已經(jīng)存在一個(gè)Leader服務(wù)器在負(fù)責(zé)進(jìn)行消息廣播，那么新加人的服務(wù)器就會(huì)自覺(jué)地進(jìn)人數(shù)據(jù)恢復(fù)模式：找到Leader所在的服務(wù)器，并與其進(jìn)行數(shù)據(jù)同步，然后一起參與到消息廣播流程中去。正如上文介紹中所說(shuō)的，ZooKeeper設(shè)計(jì)成只允許唯一的一個(gè)Leader服務(wù)器來(lái)進(jìn)行事務(wù)請(qǐng)求的處理。Leader服務(wù)器在接收到客戶端的事務(wù)請(qǐng)求后，會(huì)生成對(duì)應(yīng)的事務(wù)提案并發(fā)起一輪廣播協(xié)議；而如果集群中的其他機(jī)器接收到客戶端的事務(wù)請(qǐng)求，那么這些非Leader服務(wù)器會(huì)首先將這個(gè)事務(wù)請(qǐng)求轉(zhuǎn)發(fā)給Leader服務(wù)器。

到此，相信大家對(duì)“zookeeper基礎(chǔ)知識(shí)點(diǎn)有哪些”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！