Zookeeper的基礎(chǔ)原理及應(yīng)用場(chǎng)景

本篇內(nèi)容介紹了“Zookeeper的基礎(chǔ)原理及應(yīng)用場(chǎng)景”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

簡(jiǎn)單了解Zookeeper

• Tips: 如果之前對(duì)Zookeeper不了解的話(huà)，這里大概留個(gè)印象就好了

Zookeeper是一個(gè)分布式協(xié)調(diào)服務(wù)，可以用于元數(shù)據(jù)管理、分布式鎖、分布式協(xié)調(diào)、發(fā)布訂閱、服務(wù)命名等等。

例如，Kafka中就是用Zookeeper來(lái)保存其集群中的相關(guān)元數(shù)據(jù)，例如Broker、Topic以及Partition等等。同時(shí)，基于Zookeeper的Watch監(jiān)聽(tīng)機(jī)制，還可以用其實(shí)現(xiàn)發(fā)布、訂閱的功能。

在平常的常規(guī)業(yè)務(wù)使用場(chǎng)景下，我們幾乎只會(huì)使用到分布式鎖這一個(gè)用途。

Zookeeper內(nèi)部運(yùn)行機(jī)制

Zookeeper的底層存儲(chǔ)原理，有點(diǎn)類(lèi)似于Linux中的文件系統(tǒng)。Zookeeper中的文件系統(tǒng)中的每個(gè)文件都是節(jié)點(diǎn)(Znode)。根據(jù)文件之間的層級(jí)關(guān)系，Zookeeper內(nèi)部就會(huì)形成這個(gè)這樣一個(gè)文件樹(shù)。

在Linux中，文件(節(jié)點(diǎn))其實(shí)是分類(lèi)型的，例如分為文件、目錄。在Zookeeper中同理，Znode同樣的有類(lèi)型。在Zookeeper中，所有的節(jié)點(diǎn)類(lèi)型如下：

• 持久節(jié)點(diǎn)(Persistent)

• 持久順序節(jié)點(diǎn)(Persistent Sequential)

• 臨時(shí)節(jié)點(diǎn)(Ephemeral)

• 臨時(shí)順序節(jié)點(diǎn)(Ephemeral Sequential)

所謂持久節(jié)點(diǎn)，就和我們自己在電腦上新建一個(gè)文件一樣，除非你主動(dòng)刪除，否則一直存在。

而持久順序節(jié)點(diǎn)除了繼承了持久節(jié)點(diǎn)的特性之外，還會(huì)為其下創(chuàng)建的子節(jié)點(diǎn)保證其先后順序，并且會(huì)自動(dòng)地為節(jié)點(diǎn)加上10位自增序列號(hào)作為節(jié)點(diǎn)名，以此來(lái)保證節(jié)點(diǎn)名的唯一性。這一點(diǎn)上圖中的subfiles已經(jīng)給出了示例。

而臨時(shí)節(jié)點(diǎn)，其生命周期和client的連接是否活躍相關(guān)，如果client一旦斷開(kāi)連接，該節(jié)點(diǎn)(可以理解為文件)就都會(huì)被刪除，并且臨時(shí)節(jié)點(diǎn)無(wú)法創(chuàng)建子節(jié)點(diǎn);

• PS：這里的斷開(kāi)連接其實(shí)不是我們直覺(jué)上理解的斷開(kāi)連接，Zookeeper有其Session機(jī)制，當(dāng)某個(gè)client的Session過(guò)期之后，會(huì)將對(duì)應(yīng)的client創(chuàng)建的節(jié)點(diǎn)全部刪除

Zookeeper的節(jié)點(diǎn)創(chuàng)建方式

接下來(lái)我們來(lái)分別看看幾種節(jié)點(diǎn)的創(chuàng)建方式，給出幾個(gè)簡(jiǎn)單的示例。

創(chuàng)建持久節(jié)點(diǎn)

create /node_name SH的全棧筆記

這里需要注意的是，命令中所有的節(jié)點(diǎn)名稱(chēng)必須要以/開(kāi)頭，否則會(huì)創(chuàng)建失敗，因?yàn)樵赯ookeeper中是不能使用相對(duì)路徑，必須要使用絕對(duì)路徑。

創(chuàng)建持久順序節(jié)點(diǎn)

create -s /node_name SH的全棧筆記

可以看到，Zookeeper為key自動(dòng)的加上了10位的自增后綴。

創(chuàng)建臨時(shí)節(jié)點(diǎn)

create -e /test SH的全棧筆記

創(chuàng)建臨時(shí)順序節(jié)點(diǎn)

create -e -s /node_name SH的全棧筆記

Zookeeper的用途

我們通過(guò)一些具體的例子，來(lái)了解Zookeeper的詳細(xì)用途，它不僅僅只是被當(dāng)作分布式鎖使用。

元數(shù)據(jù)管理

我們都知道，Kafka在運(yùn)行時(shí)會(huì)依賴(lài)一個(gè)Zookeeper的集群。Kafka通過(guò)Zookeeper來(lái)管理集群的相關(guān)元數(shù)據(jù)，并通過(guò)Zookeeper進(jìn)行Leader選舉。

• Tips: 但是即將發(fā)布的Kafka  2.8版本中，Zookeeper已經(jīng)不是一個(gè)必需的組件了。這塊我暫時(shí)還沒(méi)有時(shí)間去細(xì)看，不過(guò)我估計(jì)可能會(huì)跟RocketMQ中處理的方式差不多，將其集群的元數(shù)據(jù)放到Kafka本身來(lái)處理。

分布式鎖

基于Zookeeper的分布式鎖其實(shí)流程很簡(jiǎn)單。首先我們需要知道加分布式鎖的本質(zhì)是什么?

• 答案是創(chuàng)建臨時(shí)順序節(jié)點(diǎn)

當(dāng)某個(gè)客戶(hù)端加鎖成功之后，實(shí)際上則是成功的在Zookeeper上創(chuàng)建了臨時(shí)順序節(jié)點(diǎn)。我們知道，分布式鎖能夠使同一時(shí)間只能有一個(gè)能夠訪(fǎng)問(wèn)某種資源。那這就必然會(huì)涉及到分布式鎖的競(jìng)爭(zhēng)，那問(wèn)題來(lái)了，當(dāng)前這個(gè)客戶(hù)端是如何感知搶到了鎖呢?

其實(shí)在客戶(hù)端側(cè)會(huì)有一定的邏輯，假設(shè)加鎖的key為/locks/modify_users。

首先，客戶(hù)端會(huì)發(fā)起加鎖請(qǐng)求，然后會(huì)在Zookeeper上創(chuàng)建持久節(jié)點(diǎn)locks，然后會(huì)在該節(jié)點(diǎn)下創(chuàng)建臨時(shí)順序節(jié)點(diǎn)。臨時(shí)順序節(jié)點(diǎn)的創(chuàng)建示例，如下圖所示。

當(dāng)客戶(hù)端成功創(chuàng)建了節(jié)點(diǎn)之后，還會(huì)獲取其同級(jí)的所有節(jié)點(diǎn)。也就是上圖中的所有modify_users000000000x的節(jié)點(diǎn)。

此時(shí)客戶(hù)端會(huì)根據(jù)10位的自增序號(hào)去判斷，當(dāng)前自己創(chuàng)建的節(jié)點(diǎn)是否是所有的節(jié)點(diǎn)中最小的那個(gè)，如果是最小的則自己獲取到了分布式鎖。

你可能會(huì)問(wèn)，那如果我不是最小的怎么辦呢?而且我的節(jié)點(diǎn)都已經(jīng)創(chuàng)建了。如果不是最小的，說(shuō)明當(dāng)前客戶(hù)端并沒(méi)有搶到鎖。按照我們的認(rèn)知，如果沒(méi)有競(jìng)爭(zhēng)到分布式鎖，則會(huì)等待。等待的底層都做了什么?我們用實(shí)際例子來(lái)捋一遍。

假設(shè)Zookeeper中已經(jīng)有了如下的節(jié)點(diǎn)。

例如當(dāng)前客戶(hù)端是B創(chuàng)建的節(jié)點(diǎn)是modify_users0000000002，那么很明顯B沒(méi)有搶到鎖，因?yàn)橐呀?jīng)有比它還要小的由客戶(hù)端A創(chuàng)建的節(jié)點(diǎn)modify_users0000000001。

此時(shí)客戶(hù)端B會(huì)對(duì)節(jié)點(diǎn)modify_users0000000001注冊(cè)一個(gè)監(jiān)聽(tīng)器，對(duì)于該節(jié)點(diǎn)的任意更新都將觸發(fā)對(duì)應(yīng)的操作。

當(dāng)其被刪除之后，就會(huì)喚醒客戶(hù)端B的線(xiàn)程，此時(shí)客戶(hù)端B會(huì)再次進(jìn)行判斷自己是否是序號(hào)最小的一個(gè)節(jié)點(diǎn)，此時(shí)modify_users0000000002明顯是最小的節(jié)點(diǎn)，故客戶(hù)端B加鎖成功。

為了讓你更加直觀的了解這個(gè)過(guò)程，我把流程濃縮成了下面這幅流程圖。

分布式協(xié)調(diào)

我們都知道，在很多場(chǎng)景下要保證一致性都會(huì)采用經(jīng)典的2PC(兩階段提交)，例如MySQL中Redo  Log和Binlog提交的數(shù)據(jù)一致性保障就是采用的2PC，詳情可以看基于Redo Log和Undo Log的MySQL崩潰恢復(fù)流程。

在2PC中存在兩種角色，分別是參與者(Participant)和協(xié)調(diào)者(Coordinator)，協(xié)調(diào)者負(fù)責(zé)統(tǒng)一的調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行邏輯。具體協(xié)調(diào)啥呢?舉個(gè)例子。

例如在2PC的Commit階段，兩個(gè)參與者A、B，A的commit操作成功了，但不幸的是B失敗了。此時(shí)協(xié)調(diào)者就需要向A發(fā)送Rollback操作。Zookeeper大概就是這樣一個(gè)角色。

發(fā)布訂閱

由于Zookeeper自帶了監(jiān)聽(tīng)器(Watch)的功能，所以發(fā)布訂閱也順理成章的成為了Zookeeper的應(yīng)用之一。例如在某個(gè)配置節(jié)點(diǎn)上注冊(cè)了監(jiān)聽(tīng)器，那么該配置一旦發(fā)布變更，對(duì)應(yīng)的服務(wù)就能實(shí)時(shí)的感知到配置更改，從而達(dá)到配置的動(dòng)態(tài)更新的目的。

給個(gè)簡(jiǎn)單的Watch使用示例。

命名服務(wù)

用大白話(huà)來(lái)說(shuō)，命名服務(wù)主要有兩種。

• 單純的利用Zookeeper的文件系統(tǒng)特性，存儲(chǔ)結(jié)構(gòu)化的文件

• 利用文件特性和順序節(jié)點(diǎn)的特性，來(lái)生成全局的唯一標(biāo)識(shí)

前者可以用于在系統(tǒng)之間共享某種業(yè)務(wù)上的特定資源，后者則可以用于實(shí)現(xiàn)分布式鎖。

“Zookeeper的基礎(chǔ)原理及應(yīng)用場(chǎng)景”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！