建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
ZooKeeper 是一個(gè)針對(duì)大型分布式系統(tǒng)的可靠協(xié)調(diào)系統(tǒng)，提供的功能包括：配置維護(hù)、名字服務(wù)、分布式同步、組服務(wù)等，下面為大家詳細(xì)講解一下ZooKeeper工作原理。
創(chuàng)新互聯(lián)建站專(zhuān)注為客戶(hù)提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、彝良網(wǎng)絡(luò)推廣、微信小程序開(kāi)發(fā)、彝良網(wǎng)絡(luò)營(yíng)銷(xiāo)、彝良企業(yè)策劃、彝良品牌公關(guān)、搜索引擎seo、人物專(zhuān)訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)建站為所有大學(xué)生創(chuàng)業(yè)者提供彝良建站搭建服務(wù)，24小時(shí)服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
ZooKeeper設(shè)計(jì)目的
-
最終一致性：client不論連接到哪個(gè)Server，展示給它都是同一個(gè)視圖，這是zookeeper最重要的性能。
-
可靠性：具有簡(jiǎn)單、健壯、良好的性能，如果消息m被到一臺(tái)服務(wù)器接受，那么它將被所有的服務(wù)器接受。
-
實(shí)時(shí)性：Zookeeper保證客戶(hù)端將在一個(gè)時(shí)間間隔范圍內(nèi)獲得服務(wù)器的更新信息，或者服務(wù)器失效的信息。但由于網(wǎng)絡(luò)延時(shí)等原因，Zookeeper不能保證兩個(gè)客戶(hù)端能同時(shí)得到剛更新的數(shù)據(jù)，如果需要最新數(shù)據(jù)，應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口。
-
等待無(wú)關(guān)(wait-free)：慢的或者失效的client不得干預(yù)快速的client的請(qǐng)求，使得每個(gè)client都能有效的等待。
-
原子性：更新只能成功或者失敗，沒(méi)有中間狀態(tài)。
-
順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺(tái)服務(wù)器上消息a在消息b前發(fā)布，則在所有Server上消息a都將在消息b前被發(fā)布;偏序是指如果一個(gè)消息b在消息a后被同一個(gè)發(fā)送者發(fā)布，a必將排在b前面。
ZooKeeper數(shù)據(jù)模型
Zookeeper會(huì)維護(hù)一個(gè)具有層次關(guān)系的數(shù)據(jù)結(jié)構(gòu)，它非常類(lèi)似于一個(gè)標(biāo)準(zhǔn)的文件系統(tǒng)，如圖所示：
來(lái)系統(tǒng)學(xué)習(xí)一下ZooKeeper基本的原理來(lái)系統(tǒng)學(xué)習(xí)一下ZooKeeper基本的原理
Zookeeper這種數(shù)據(jù)結(jié)構(gòu)有如下這些特點(diǎn)：
1)每個(gè)子目錄項(xiàng)如NameService都被稱(chēng)作為znode，這個(gè)znode是被它所在的路徑唯一標(biāo)識(shí)，如Server1這個(gè)znode的標(biāo)識(shí)為/NameService/Server1。
2)znode可以有子節(jié)點(diǎn)目錄，并且每個(gè)znode可以存儲(chǔ)數(shù)據(jù)，注意EPHEMERAL(臨時(shí)的)類(lèi)型的目錄節(jié)點(diǎn)不能有子節(jié)點(diǎn)目錄。
3)znode是有版本的(version)，每個(gè)znode中存儲(chǔ)的數(shù)據(jù)可以有多個(gè)版本，也就是一個(gè)訪問(wèn)路徑中可以存儲(chǔ)多份數(shù)據(jù)，version號(hào)自動(dòng)增加。
4)znode的類(lèi)型：
-
Persistent 節(jié)點(diǎn)，一旦被創(chuàng)建，便不會(huì)意外丟失，即使服務(wù)器全部重啟也依然存在。每個(gè) Persist 節(jié)點(diǎn)即可包含數(shù)據(jù)，也可包含子節(jié)點(diǎn)。
-
Ephemeral 節(jié)點(diǎn)，在創(chuàng)建它的客戶(hù)端與服務(wù)器間的 Session 結(jié)束時(shí)自動(dòng)被刪除。服務(wù)器重啟會(huì)導(dǎo)致 Session 結(jié)束，因此 Ephemeral 類(lèi)型的 znode 此時(shí)也會(huì)自動(dòng)刪除。
-
Non-sequence 節(jié)點(diǎn)，多個(gè)客戶(hù)端同時(shí)創(chuàng)建同一 Non-sequence 節(jié)點(diǎn)時(shí)，只有一個(gè)可創(chuàng)建成功，其它勻失敗。并且創(chuàng)建出的節(jié)點(diǎn)名稱(chēng)與創(chuàng)建時(shí)指定的節(jié)點(diǎn)名完全一樣。
-
Sequence 節(jié)點(diǎn)，創(chuàng)建出的節(jié)點(diǎn)名在指定的名稱(chēng)之后帶有10位10進(jìn)制數(shù)的序號(hào)。多個(gè)客戶(hù)端創(chuàng)建同一名稱(chēng)的節(jié)點(diǎn)時(shí)，都能創(chuàng)建成功，只是序號(hào)不同。
5)znode可以被監(jiān)控，包括這個(gè)目錄節(jié)點(diǎn)中存儲(chǔ)的數(shù)據(jù)的修改，子節(jié)點(diǎn)目錄的變化等，一旦變化可以通知設(shè)置監(jiān)控的客戶(hù)端，這個(gè)是Zookeeper的核心特性，Zookeeper的很多功能都是基于這個(gè)特性實(shí)現(xiàn)的。
6)ZXID：每次對(duì)Zookeeper的狀態(tài)的改變都會(huì)產(chǎn)生一個(gè)zxid(ZooKeeper Transaction Id)，zxid是全局有序的，如果zxid1小于zxid2，則zxid1在zxid2之前發(fā)生。
ZooKeeper Session
Client和Zookeeper集群建立連接，整個(gè)session狀態(tài)變化如圖所示：
來(lái)系統(tǒng)學(xué)習(xí)一下ZooKeeper基本的原理來(lái)系統(tǒng)學(xué)習(xí)一下ZooKeeper基本的原理
如果Client因?yàn)門(mén)imeout和Zookeeper Server失去連接，client處在CONNECTING狀態(tài)，會(huì)自動(dòng)嘗試再去連接Server，如果在session有效期內(nèi)再次成功連接到某個(gè)Server，則回到CONNECTED狀態(tài)。
注意：如果因?yàn)榫W(wǎng)絡(luò)狀態(tài)不好，client和Server失去聯(lián)系，client會(huì)停留在當(dāng)前狀態(tài)，會(huì)嘗試主動(dòng)再次連接Zookeeper Server。client不能宣稱(chēng)自己的session expired，session expired是由Zookeeper Server來(lái)決定的，client可以選擇自己主動(dòng)關(guān)閉session。
ZooKeeper Watch
Zookeeper watch是一種監(jiān)聽(tīng)通知機(jī)制。Zookeeper所有的讀操作getData(), getChildren()和 exists()都可以設(shè)置監(jiān)視(watch)，監(jiān)視事件可以理解為一次性的觸發(fā)器
官方定義如下：
a watch event is one-time trigger, sent to the client that set the watch, whichoccurs when the data for which the watch was set changes。
Watch的三個(gè)關(guān)鍵點(diǎn)：
(一次性觸發(fā))One-time trigger
當(dāng)設(shè)置監(jiān)視的數(shù)據(jù)發(fā)生改變時(shí)，該監(jiān)視事件會(huì)被發(fā)送到客戶(hù)端，例如，如果客戶(hù)端調(diào)用了getData(“/znode1”, true) 并且稍后 /znode1 節(jié)點(diǎn)上的數(shù)據(jù)發(fā)生了改變或者被刪除了，客戶(hù)端將會(huì)獲取到 /znode1 發(fā)生變化的監(jiān)視事件，而如果 /znode1 再一次發(fā)生了變化，除非客戶(hù)端再次對(duì)/znode1 設(shè)置監(jiān)視，否則客戶(hù)端不會(huì)收到事件通知。
(發(fā)送至客戶(hù)端)Sent to the client
Zookeeper客戶(hù)端和服務(wù)端是通過(guò) socket 進(jìn)行通信的，由于網(wǎng)絡(luò)存在故障，所以監(jiān)視事件很有可能不會(huì)成功地到達(dá)客戶(hù)端，監(jiān)視事件是異步發(fā)送至監(jiān)視者的，Zookeeper 本身提供了順序保證(ordering guarantee)：即客戶(hù)端只有首先看到了監(jiān)視事件后，才會(huì)感知到它所設(shè)置監(jiān)視的znode發(fā)生了變化(a client will never see a change for which it has set a watch until it first sees the watch event)。
網(wǎng)絡(luò)延遲或者其他因素可能導(dǎo)致不同的客戶(hù)端在不同的時(shí)刻感知某一監(jiān)視事件，但是不同的客戶(hù)端所看到的一切具有一致的順序。
(被設(shè)置 watch 的數(shù)據(jù))The data for which the watch was set
這意味著znode節(jié)點(diǎn)本身具有不同的改變方式。你也可以想象 Zookeeper 維護(hù)了兩條監(jiān)視鏈表：數(shù)據(jù)監(jiān)視和子節(jié)點(diǎn)監(jiān)視(data watches and child watches) getData() 和exists()設(shè)置數(shù)據(jù)監(jiān)視，getChildren()設(shè)置子節(jié)點(diǎn)監(jiān)視。或者你也可以想象 Zookeeper 設(shè)置的不同監(jiān)視返回不同的數(shù)據(jù)，getData() 和 exists() 返回znode節(jié)點(diǎn)的相關(guān)信息，而getChildren() 返回子節(jié)點(diǎn)列表。
因此，setData() 會(huì)觸發(fā)設(shè)置在某一節(jié)點(diǎn)上所設(shè)置的數(shù)據(jù)監(jiān)視(假定數(shù)據(jù)設(shè)置成功)，而一次成功的create() 操作則會(huì)出發(fā)當(dāng)前節(jié)點(diǎn)上所設(shè)置的數(shù)據(jù)監(jiān)視以及父節(jié)點(diǎn)的子節(jié)點(diǎn)監(jiān)視。一次成功的 delete操作將會(huì)觸發(fā)當(dāng)前節(jié)點(diǎn)的數(shù)據(jù)監(jiān)視和子節(jié)點(diǎn)監(jiān)視事件，同時(shí)也會(huì)觸發(fā)該節(jié)點(diǎn)父節(jié)點(diǎn)的child watch。
Zookeeper 中的監(jiān)視是輕量級(jí)的，因此容易設(shè)置、維護(hù)和分發(fā)。當(dāng)客戶(hù)端與 Zookeeper 服務(wù)器失去聯(lián)系時(shí)，客戶(hù)端并不會(huì)收到監(jiān)視事件的通知，只有當(dāng)客戶(hù)端重新連接后，若在必要的情況下，以前注冊(cè)的監(jiān)視會(huì)重新被注冊(cè)并觸發(fā)，對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)這通常是透明的。
只有一種情況會(huì)導(dǎo)致監(jiān)視事件的丟失，即：通過(guò)exists()設(shè)置了某個(gè)znode節(jié)點(diǎn)的監(jiān)視，但是如果某個(gè)客戶(hù)端在此znode節(jié)點(diǎn)被創(chuàng)建和刪除的時(shí)間間隔內(nèi)與zookeeper服務(wù)器失去了聯(lián)系，該客戶(hù)端即使稍后重新連接 zookeeper服務(wù)器后也得不到事件通知。
Consistency Guarantees
Zookeeper是一個(gè)高效的、可擴(kuò)展的服務(wù)，read和write操作都被設(shè)計(jì)為快速的，read比write操作更快。
-
順序一致性(Sequential Consistency)：從一個(gè)客戶(hù)端來(lái)的更新請(qǐng)求會(huì)被順序執(zhí)行。
-
原子性(Atomicity)：更新要么成功要么失敗，沒(méi)有部分成功的情況。
-
唯一的系統(tǒng)鏡像(Single System Image)：無(wú)論客戶(hù)端連接到哪個(gè)Server，看到系統(tǒng)鏡像是一致的。
-
可靠性(Reliability)：更新一旦有效，持續(xù)有效，直到被覆蓋。
-
時(shí)間線(Timeliness)：保證在一定的時(shí)間內(nèi)各個(gè)客戶(hù)端看到的系統(tǒng)信息是一致的。
ZooKeeper的工作原理
在zookeeper的集群中，各個(gè)節(jié)點(diǎn)共有下面3種角色和4種狀態(tài)：
-
角色：leader,follower,observer
-
狀態(tài)：leading,following,observing,looking
Zookeeper的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè)Server之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議(ZooKeeper Atomic Broadcast protocol)。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式(Recovery選主)和廣播模式(Broadcast同步)。
當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來(lái)，且大多數(shù)Server完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。
為了保證事務(wù)的順序一致性，zookeeper采用了遞增的事務(wù)id號(hào)(zxid)來(lái)標(biāo)識(shí)事務(wù)。所有的提議(proposal)都在被提出的時(shí)候加上了zxid。
實(shí)現(xiàn)中zxid是一個(gè)64位的數(shù)字，它高32位是epoch用來(lái)標(biāo)識(shí)leader關(guān)系是否改變，每次一個(gè)leader被選出來(lái)，它都會(huì)有一個(gè)新的epoch，標(biāo)識(shí)當(dāng)前屬于那個(gè)leader的統(tǒng)治時(shí)期。低32位用于遞增計(jì)數(shù)。
每個(gè)Server在工作過(guò)程中有4種狀態(tài)：
-
LOOKING：當(dāng)前Server不知道leader是誰(shuí)，正在搜尋。
-
LEADING：當(dāng)前Server即為選舉出來(lái)的leader。
-
FOLLOWING：leader已經(jīng)選舉出來(lái)，當(dāng)前Server與之同步。
-
OBSERVING：observer的行為在大多數(shù)情況下與follower完全一致，但是他們不參加選舉和投票，而僅僅接受(observing)選舉和投票的結(jié)果。
Leader Election
當(dāng)leader崩潰或者leader失去大多數(shù)的follower，這時(shí)候zk進(jìn)入恢復(fù)模式，恢復(fù)模式需要重新選舉出一個(gè)新的leader，讓所有的Server都恢復(fù)到一個(gè)正確的狀態(tài)。Zk的選舉算法有兩種：一種是基于basic paxos實(shí)現(xiàn)的，另外一種是基于fast paxos算法實(shí)現(xiàn)的。系統(tǒng)默認(rèn)的選舉算法為fast paxos。先介紹basic paxos流程：
-
選舉線程由當(dāng)前Server發(fā)起選舉的線程擔(dān)任，其主要功能是對(duì)投票結(jié)果進(jìn)行統(tǒng)計(jì)，并選出推薦的Server;
-
選舉線程首先向所有Server發(fā)起一次詢(xún)問(wèn)(包括自己);
-
選舉線程收到回復(fù)后，驗(yàn)證是否是自己發(fā)起的詢(xún)問(wèn)(驗(yàn)證zxid是否一致)，然后獲取對(duì)方的id(myid)，并存儲(chǔ)到當(dāng)前詢(xún)問(wèn)對(duì)象列表中，最后獲取對(duì)方提議的leader相關(guān)信息(id,zxid)，并將這些信息存儲(chǔ)到當(dāng)次選舉的投票記錄表中;
-
收到所有Server回復(fù)以后，就計(jì)算出zxid最大的那個(gè)Server，并將這個(gè)Server相關(guān)信息設(shè)置成下一次要投票的Server;
-
線程將當(dāng)前zxid最大的Server設(shè)置為當(dāng)前Server要推薦的Leader，如果此時(shí)獲勝的Server獲得n/2 + 1的Server票數(shù)，設(shè)置當(dāng)前推薦的leader為獲勝的Server，將根據(jù)獲勝的Server相關(guān)信息設(shè)置自己的狀態(tài)，否則，繼續(xù)這個(gè)過(guò)程，直到leader被選舉出來(lái)。
通過(guò)流程分析我們可以得出：要使Leader獲得多數(shù)Server的支持，則Server總數(shù)必須是奇數(shù)2n+1，且存活的Server的數(shù)目不得少于n+1.
每個(gè)Server啟動(dòng)后都會(huì)重復(fù)以上流程。在恢復(fù)模式下，如果是剛從崩潰狀態(tài)恢復(fù)的或者剛啟動(dòng)的server還會(huì)從磁盤(pán)快照中恢復(fù)數(shù)據(jù)和會(huì)話(huà)信息，zk會(huì)記錄事務(wù)日志并定期進(jìn)行快照，方便在恢復(fù)時(shí)進(jìn)行狀態(tài)恢復(fù)。
fast paxos流程是在選舉過(guò)程中，某Server首先向所有Server提議自己要成為leader，當(dāng)其它Server收到提議以后，解決epoch和zxid的沖突，并接受對(duì)方的提議，然后向?qū)Ψ桨l(fā)送接受提議完成的消息，重復(fù)這個(gè)流程，最后一定能選舉出Leader。
Leader工作流程
Leader主要有三個(gè)功能：
-
恢復(fù)數(shù)據(jù);
-
維持與follower的心跳，接收f(shuō)ollower請(qǐng)求并判斷follower的請(qǐng)求消息類(lèi)型;
-
follower的消息類(lèi)型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據(jù)不同的消息類(lèi)型，進(jìn)行不同的處理。
說(shuō)明：
PING消息是指follower的心跳信息;REQUEST消息是follower發(fā)送的提議信息，包括寫(xiě)請(qǐng)求及同步請(qǐng)求;
ACK消息是follower的對(duì)提議的回復(fù)，超過(guò)半數(shù)的follower通過(guò)，則commit該提議;
REVALIDATE消息是用來(lái)延長(zhǎng)SESSION有效時(shí)間。
Follower工作流程
Follower主要有四個(gè)功能：
-
向Leader發(fā)送請(qǐng)求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息);
-
接收Leader消息并進(jìn)行處理;
-
接收Client的請(qǐng)求，如果為寫(xiě)請(qǐng)求，發(fā)送給Leader進(jìn)行投票;
-
返回Client結(jié)果。
Follower的消息循環(huán)處理如下幾種來(lái)自Leader的消息：
-
PING消息：心跳消息
-
PROPOSAL消息：Leader發(fā)起的提案，要求Follower投票
-
COMMIT消息：服務(wù)器端最新一次提案的信息
-
UPTODATE消息：表明同步完成
-
REVALIDATE消息：根據(jù)Leader的REVALIDATE結(jié)果，關(guān)閉待revalidate的session還是允許其接受消息
-
SYNC消息：返回SYNC結(jié)果到客戶(hù)端，這個(gè)消息最初由客戶(hù)端發(fā)起，用來(lái)強(qiáng)制得到最新的更新。
Zab: Broadcasting State Updates
Zookeeper Server接收到一次request，如果是follower，會(huì)轉(zhuǎn)發(fā)給leader，Leader執(zhí)行請(qǐng)求并通過(guò)Transaction的形式廣播這次執(zhí)行。Zookeeper集群如何決定一個(gè)Transaction是否被commit執(zhí)行?通過(guò)“兩段提交協(xié)議”(a two-phase commit)：
-
Leader給所有的follower發(fā)送一個(gè)PROPOSAL消息。
-
一個(gè)follower接收到這次PROPOSAL消息，寫(xiě)到磁盤(pán)，發(fā)送給leader一個(gè)ACK消息，告知已經(jīng)收到。
-
當(dāng)Leader收到法定人數(shù)(quorum)的follower的ACK時(shí)候，發(fā)送commit消息執(zhí)行。
Zab協(xié)議保證：
-
如果leader以T1和T2的順序廣播，那么所有的Server必須先執(zhí)行T1，再執(zhí)行T2。
-
如果任意一個(gè)Server以T1、T2的順序commit執(zhí)行，其他所有的Server也必須以T1、T2的順序執(zhí)行。
“兩段提交協(xié)議”最大的問(wèn)題是如果Leader發(fā)送了PROPOSAL消息后crash或暫時(shí)失去連接，會(huì)導(dǎo)致整個(gè)集群處在一種不確定的狀態(tài)(follower不知道該放棄這次提交還是執(zhí)行提交)。Zookeeper這時(shí)會(huì)選出新的leader，請(qǐng)求處理也會(huì)移到新的leader上，不同的leader由不同的epoch標(biāo)識(shí)。切換Leader時(shí)，需要解決下面兩個(gè)問(wèn)題：
1. Never forget delivered messages
Leader在COMMIT投遞到任何一臺(tái)follower之前crash，只有它自己commit了。新Leader必須保證這個(gè)事務(wù)也必須commit。
2. Let go of messages that are skipped
Leader產(chǎn)生某個(gè)proposal，但是在crash之前，沒(méi)有follower看到這個(gè)proposal。該server恢復(fù)時(shí)，必須丟棄這個(gè)proposal。
Zookeeper會(huì)盡量保證不會(huì)同時(shí)有2個(gè)活動(dòng)的Leader，因?yàn)?個(gè)不同的Leader會(huì)導(dǎo)致集群處在一種不一致的狀態(tài)，所以Zab協(xié)議同時(shí)保證：
-
在新的leader廣播Transaction之前，先前Leader commit的Transaction都會(huì)先執(zhí)行。
-
在任意時(shí)刻，都不會(huì)有2個(gè)Server同時(shí)有法定人數(shù)(quorum)的支持者。
這里的quorum是一半以上的Server數(shù)目，確切的說(shuō)是有投票權(quán)力的Server(不包括Observer)。
總結(jié)
簡(jiǎn)單介紹了Zookeeper的基本原理，數(shù)據(jù)模型，Session，Watch機(jī)制，一致性保證，Leader Election，Leader和Follower的工作流程和Zab協(xié)議。
文章名稱(chēng)：詳解ZooKeeper工作原理
鏈接地址：http://fisionsoft.com.cn/article/djdogdd.html
