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

目前創(chuàng)新互聯(lián)已為超過千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機(jī)、網(wǎng)站托管維護(hù)、企業(yè)網(wǎng)站設(shè)計(jì)、桓仁網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

簡(jiǎn)單了解Zookeeper

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

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

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

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

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

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

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

• 持久節(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)名，以此來保證節(jié)點(diǎn)名的唯一性。這一點(diǎn)上圖中的subfiles已經(jīng)給出了示例。

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

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

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

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

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

create /node_name SH的全棧筆記

 

這里需要注意的是，命令中所有的節(jié)點(diǎn)名稱必須要以/開頭，否則會(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的用途

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

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

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

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

分布式鎖

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

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

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

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

首先，客戶端會(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)客戶端成功創(chuàng)建了節(jié)點(diǎn)之后，還會(huì)獲取其同級(jí)的所有節(jié)點(diǎn)。也就是上圖中的所有modify_users000000000x的節(jié)點(diǎn)。

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

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

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

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

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

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

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

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

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

命名服務(wù)

用大白話來說，命名服務(wù)主要有兩種。

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

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

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

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

當(dāng)前標(biāo)題：Zookeeper的基礎(chǔ)原理及應(yīng)用場(chǎng)景
網(wǎng)頁鏈接：http://www.rwnh.cn/article22/jdcjjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、搜索引擎優(yōu)化、面包屑導(dǎo)航、動(dòng)態(tài)網(wǎng)站、微信小程序、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)