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

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

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

簡單了解Zookeeper

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

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

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

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

Zookeeper內(nèi)部運行機制

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

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

• 持久節(jié)點(Persistent)

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

• 臨時節(jié)點(Ephemeral)

• 臨時順序節(jié)點(Ephemeral Sequential)

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

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

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

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

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

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

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

create /node_name SH的全棧筆記

 

這里需要注意的是，命令中所有的節(jié)點名稱必須要以/開頭，否則會創(chuàng)建失敗，因為在Zookeeper中是不能使用相對路徑，必須要使用絕對路徑。

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

create -s /node_name SH的全棧筆記

 

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

創(chuàng)建臨時節(jié)點

create -e /test SH的全棧筆記

 

創(chuàng)建臨時順序節(jié)點

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

 

Zookeeper的用途

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

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

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

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

分布式鎖

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

• 答案是創(chuàng)建臨時順序節(jié)點

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

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

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

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

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

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

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

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

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

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

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

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

我們都知道，在很多場景下要保證一致性都會采用經(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é)點的執(zhí)行邏輯。具體協(xié)調(diào)啥呢?舉個例子。

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

發(fā)布訂閱

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

給個簡單的Watch使用示例。

命名服務(wù)

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

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

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

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

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

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

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

廣告

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