建站
咨詢
售后
建站咨詢
新聞中心
簡單了解Zookeeper
- Tips: 如果之前對Zookeeper不了解的話，這里大概留個(gè)印象就好了
Zookeeper是一個(gè)分布式協(xié)調(diào)服務(wù)，可以用于元數(shù)據(jù)管理、分布式鎖、分布式協(xié)調(diào)、發(fā)布訂閱、服務(wù)命名等等。
10年積累的成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有銅陵免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
例如，Kafka中就是用Zookeeper來保存其集群中的相關(guān)元數(shù)據(jù)，例如Broker、Topic以及Partition等等。同時(shí)，基于Zookeeper的Watch監(jiān)聽機(jī)制，還可以用其實(shí)現(xiàn)發(fā)布、訂閱的功能。
在平常的常規(guī)業(yè)務(wù)使用場景下，我們幾乎只會(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ì)將對應(yīng)的client創(chuàng)建的節(jié)點(diǎn)全部刪除
Zookeeper的節(jié)點(diǎn)創(chuàng)建方式
接下來我們來分別看看幾種節(jié)點(diǎn)的創(chuàng)建方式，給出幾個(gè)簡單的示例。
創(chuàng)建持久節(jié)點(diǎn)
- create /node_name SH的全棧筆記
這里需要注意的是，命令中所有的節(jié)點(diǎn)名稱必須要以/開頭，否則會(huì)創(chuàng)建失敗，因?yàn)樵赯ookeeper中是不能使用相對路徑，必須要使用絕對路徑。
創(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í)流程很簡單。首先我們需要知道加分布式鎖的本質(zhì)是什么?
- 答案是創(chuàng)建臨時(shí)順序節(jié)點(diǎn)
當(dāng)某個(gè)客戶端加鎖成功之后，實(shí)際上則是成功的在Zookeeper上創(chuàng)建了臨時(shí)順序節(jié)點(diǎn)。我們知道，分布式鎖能夠使同一時(shí)間只能有一個(gè)能夠訪問某種資源。那這就必然會(huì)涉及到分布式鎖的競爭，那問題來了，當(dāng)前這個(gè)客戶端是如何感知搶到了鎖呢?
其實(shí)在客戶端側(cè)會(huì)有一定的邏輯，假設(shè)加鎖的key為/locks/modify_users。
首先，客戶端會(huì)發(fā)起加鎖請求，然后會(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)知，如果沒有競爭到分布式鎖，則會(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ì)對節(jié)點(diǎn)modify_users0000000001注冊一個(gè)監(jiān)聽器，對于該節(jié)點(diǎn)的任意更新都將觸發(fā)對應(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)
我們都知道，在很多場景下要保證一致性都會(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)上注冊了監(jiān)聽器，那么該配置一旦發(fā)布變更，對應(yīng)的服務(wù)就能實(shí)時(shí)的感知到配置更改，從而達(dá)到配置的動(dòng)態(tài)更新的目的。
給個(gè)簡單的Watch使用示例。
命名服務(wù)
用大白話來說，命名服務(wù)主要有兩種。
- 單純的利用Zookeeper的文件系統(tǒng)特性，存儲(chǔ)結(jié)構(gòu)化的文件
- 利用文件特性和順序節(jié)點(diǎn)的特性，來生成全局的唯一標(biāo)識(shí)
前者可以用于在系統(tǒng)之間共享某種業(yè)務(wù)上的特定資源，后者則可以用于實(shí)現(xiàn)分布式鎖。
網(wǎng)站題目：Zookeeper基礎(chǔ)原理&應(yīng)用場景詳解
文章地址：http://www.5511xx.com/article/cccjsoe.html
