zookeeper原理(轉(zhuǎn))

ZooKeeper是一個(gè)分布式的割择,開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)蒙具,它包含一個(gè)簡單的原語集,分布式應(yīng)用程序可以基于它實(shí)現(xiàn)同步服務(wù)充易,配置維護(hù)和命名服務(wù)等。Zookeeper是hadoop的一個(gè)子項(xiàng)目荸型,其發(fā)展歷程無需贅述盹靴。在分布式應(yīng)用中,由于工程師不能很好地使用鎖機(jī)制瑞妇,以及基于消息的協(xié)調(diào)機(jī)制不適合在某些應(yīng)用中使用稿静,因此需要有一種可靠的、可擴(kuò)展的踪宠、分布式的自赔、可配置的協(xié)調(diào)機(jī)制來統(tǒng)一系統(tǒng)的狀態(tài)。Zookeeper的目的就在于此柳琢。本文簡單分析zookeeper的工作原理绍妨,對(duì)于如何使用zookeeper不是本文討論的重點(diǎn)。

1 Zookeeper的基本概念

1.1 角色

Zookeeper中的角色主要有以下三類柬脸,如下表所示:

系統(tǒng)模型如圖所示:

1.2 設(shè)計(jì)目的

1.最終一致性:client不論連接到哪個(gè)Server他去,展示給它都是同一個(gè)視圖,這是zookeeper最重要的性能倒堕。

2 .可靠性:具有簡單灾测、健壯、良好的性能垦巴,如果消息m被到一臺(tái)服務(wù)器接受媳搪,那么它將被所有的服務(wù)器接受。

3 .實(shí)時(shí)性:Zookeeper保證客戶端將在一個(gè)時(shí)間間隔范圍內(nèi)獲得服務(wù)器的更新信息骤宣,或者服務(wù)器失效的信息秦爆。但由于網(wǎng)絡(luò)延時(shí)等原因,Zookeeper不能保證兩個(gè)客戶端能同時(shí)得到剛更新的數(shù)據(jù)憔披,如果需要最新數(shù)據(jù)等限,應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口。

4 .等待無關(guān)(wait-free):慢的或者失效的client不得干預(yù)快速的client的請(qǐng)求芬膝,使得每個(gè)client都能有效的等待望门。

5.原子性:更新只能成功或者失敗,沒有中間狀態(tài)锰霜。

6 .順序性:包括全局有序和偏序兩種:全局有序是指如果在一臺(tái)服務(wù)器上消息a在消息b前發(fā)布筹误,則在所有Server上消息a都將在消息b前被發(fā)布;偏序是指如果一個(gè)消息b在消息a后被同一個(gè)發(fā)送者發(fā)布癣缅,a必將排在b前面厨剪。

2 ZooKeeper的工作原理

Zookeeper的核心是原子廣播勘畔,這個(gè)機(jī)制保證了各個(gè)Server之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議丽惶。Zab協(xié)議有兩種模式,它們分別是恢復(fù)模式(選主)和廣播模式(同步)爬立。當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后钾唬,Zab就進(jìn)入了恢復(fù)模式,當(dāng)領(lǐng)導(dǎo)者被選舉出來侠驯,且大多數(shù)Server完成了和leader的狀態(tài)同步以后抡秆,恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)吟策。

為了保證事務(wù)的順序一致性儒士,zookeeper采用了遞增的事務(wù)id號(hào)(zxid)來標(biāo)識(shí)事務(wù)。所有的提議(proposal)都在被提出的時(shí)候加上了zxid檩坚。實(shí)現(xiàn)中zxid是一個(gè)64位的數(shù)字着撩,它高32位是epoch用來標(biāo)識(shí)leader關(guān)系是否改變,每次一個(gè)leader被選出來匾委,它都會(huì)有一個(gè)新的epoch拖叙,標(biāo)識(shí)當(dāng)前屬于那個(gè)leader的統(tǒng)治時(shí)期。低32位用于遞增計(jì)數(shù)赂乐。

每個(gè)Server在工作過程中有三種狀態(tài):

LOOKING:當(dāng)前Server不知道leader是誰薯鳍,正在搜尋

LEADING:當(dāng)前Server即為選舉出來的leader

FOLLOWING:leader已經(jīng)選舉出來,當(dāng)前Server與之同步

2.1 選主流程

當(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流程:

1 .選舉線程由當(dāng)前Server發(fā)起選舉的線程擔(dān)任砸民,其主要功能是對(duì)投票結(jié)果進(jìn)行統(tǒng)計(jì),并選出推薦的Server奋救;

2 .選舉線程首先向所有Server發(fā)起一次詢問(包括自己)岭参;

3 .選舉線程收到回復(fù)后,驗(yàn)證是否是自己發(fā)起的詢問(驗(yàn)證zxid是否一致)尝艘,然后獲取對(duì)方的id(myid)演侯,并存儲(chǔ)到當(dāng)前詢問對(duì)象列表中,最后獲取對(duì)方提議的leader相關(guān)信息(id,zxid)背亥,并將這些信息存儲(chǔ)到當(dāng)次選舉的投票記錄表中秒际;

4. ?收到所有Server回復(fù)以后悬赏,就計(jì)算出zxid最大的那個(gè)Server,并將這個(gè)Server相關(guān)信息設(shè)置成下一次要投票的Server娄徊;

5. ?線程將當(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è)過程橄仆,直到leader被選舉出來剩膘。

通過流程分析我們可以得出:要使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ì)從磁盤快照中恢復(fù)數(shù)據(jù)和會(huì)話信息您宪,zk會(huì)記錄事務(wù)日志并定期進(jìn)行快照奈懒,方便在恢復(fù)時(shí)進(jìn)行狀態(tài)恢復(fù)。選主的具體流程圖如下所示:

fast paxos流程是在選舉過程中蚕涤,某Server首先向所有Server提議自己要成為leader筐赔,當(dāng)其它Server收到提議以后,解決epoch和zxid的沖突揖铜,并接受對(duì)方的提議茴丰,然后向?qū)Ψ桨l(fā)送接受提議完成的消息,重復(fù)這個(gè)流程天吓,最后一定能選舉出Leader贿肩。其流程圖如下所示:

2.2 同步流程

選完leader以后,zk就進(jìn)入狀態(tài)同步過程龄寞。

1. leader等待server連接汰规;

2 .Follower連接leader,將最大的zxid發(fā)送給leader物邑;

3 .Leader根據(jù)follower的zxid確定同步點(diǎn)溜哮;

4 .完成同步后通知follower 已經(jīng)成為uptodate狀態(tài);

5 .Follower收到uptodate消息后色解,又可以重新接受client的請(qǐng)求進(jìn)行服務(wù)了茂嗓。

流程圖如下所示:

2.3 工作流程

2.3.1 Leader工作流程

Leader主要有三個(gè)功能:

1 .恢復(fù)數(shù)據(jù);

2 .維持與Learner的心跳科阎,接收Learner請(qǐng)求并判斷Learner的請(qǐng)求消息類型述吸;

3 .Learner的消息類型主要有PING消息、REQUEST消息锣笨、ACK消息蝌矛、REVALIDATE消息道批,根據(jù)不同的消息類型,進(jìn)行不同的處理入撒。

PING消息是指Learner的心跳信息隆豹;REQUEST消息是Follower發(fā)送的提議信息,包括寫請(qǐng)求及同步請(qǐng)求茅逮;ACK消息是Follower的對(duì)提議的回復(fù)噪伊,超過半數(shù)的Follower通過,則commit該提議氮唯;REVALIDATE消息是用來延長SESSION有效時(shí)間。

Leader的工作流程簡圖如下所示姨伟,在實(shí)際實(shí)現(xiàn)中惩琉,流程要比下圖復(fù)雜得多,啟動(dòng)了三個(gè)線程來實(shí)現(xiàn)功能夺荒。

2.3.2 Follower工作流程

Follower主要有四個(gè)功能:

1. 向Leader發(fā)送請(qǐng)求(PING消息瞒渠、REQUEST消息、ACK消息技扼、REVALIDATE消息)伍玖;

2 .接收Leader消息并進(jìn)行處理;

3 .接收Client的請(qǐng)求剿吻,如果為寫請(qǐng)求窍箍,發(fā)送給Leader進(jìn)行投票;

4 .返回Client結(jié)果丽旅。

Follower的消息循環(huán)處理如下幾種來自Leader的消息:

1 .PING消息: 心跳消息椰棘;

2 .PROPOSAL消息:Leader發(fā)起的提案讼昆,要求Follower投票赋荆;

3 .COMMIT消息:服務(wù)器端最新一次提案的信息;

4 .UPTODATE消息:表明同步完成次伶;

5 .REVALIDATE消息:根據(jù)Leader的REVALIDATE結(jié)果茅撞,關(guān)閉待revalidate的session還是允許其接受消息帆卓;

6 .SYNC消息:返回SYNC結(jié)果到客戶端,這個(gè)消息最初由客戶端發(fā)起米丘,用來強(qiáng)制得到最新的更新剑令。

Follower的工作流程簡圖如下所示,在實(shí)際實(shí)現(xiàn)中蠕蚜,F(xiàn)ollower是通過5個(gè)線程來實(shí)現(xiàn)功能的尚洽。

對(duì)于observer的流程不再敘述,observer流程和Follower的唯一不同的地方就是observer不會(huì)參加leader發(fā)起的投票靶累。

主流應(yīng)用場景:

Zookeeper的主流應(yīng)用場景實(shí)現(xiàn)思路(除去官方示例)

(1)配置管理集中式的配置管理在應(yīng)用集群中是非常常見的腺毫,一般商業(yè)公司內(nèi)部都會(huì)實(shí)現(xiàn)一套集中的配置管理中心癣疟,應(yīng)對(duì)不同的應(yīng)用集群對(duì)于共享各自配置的需求,并且在配置變更時(shí)能夠通知到集群中的每一個(gè)機(jī)器潮酒。

Zookeeper很容易實(shí)現(xiàn)這種集中式的配置管理睛挚,比如將APP1的所有配置配置到/APP1 znode下,APP1所有機(jī)器一啟動(dòng)就對(duì)/APP1這個(gè)節(jié)點(diǎn)進(jìn)行監(jiān)控(zk.exist("/APP1",true)),并且實(shí)現(xiàn)回調(diào)方法Watcher急黎,那么在zookeeper上/APP1 znode節(jié)點(diǎn)下數(shù)據(jù)發(fā)生變化的時(shí)候扎狱,每個(gè)機(jī)器都會(huì)收到通知,Watcher方法將會(huì)被執(zhí)行勃教,那么應(yīng)用再取下數(shù)據(jù)即可(zk.getData("/APP1",false,null));

以上這個(gè)例子只是簡單的粗顆粒度配置監(jiān)控淤击,細(xì)顆粒度的數(shù)據(jù)可以進(jìn)行分層級(jí)監(jiān)控,這一切都是可以設(shè)計(jì)和控制的故源。

(2)集群管理

應(yīng)用集群中污抬,我們常常需要讓每一個(gè)機(jī)器知道集群中(或依賴的其他某一個(gè)集群)哪些機(jī)器是活著的,并且在集群機(jī)器因?yàn)殄礄C(jī)绳军,網(wǎng)絡(luò)斷鏈等原因能夠不在人工介入的情況下迅速通知到每一個(gè)機(jī)器印机。

Zookeeper同樣很容易實(shí)現(xiàn)這個(gè)功能,比如我在zookeeper服務(wù)器端有一個(gè)znode叫/APP1SERVERS,那么集群中每一個(gè)機(jī)器啟動(dòng)的時(shí)候都去這個(gè)節(jié)點(diǎn)下創(chuàng)建一個(gè)EPHEMERAL類型的節(jié)點(diǎn)门驾,比如server1創(chuàng)建/APP1SERVERS/SERVER1(可以使用ip,保證不重復(fù))射赛,server2創(chuàng)建/APP1SERVERS/SERVER2,然后SERVER1和SERVER2都watch /APP1SERVERS這個(gè)父節(jié)點(diǎn)奶是,那么也就是這個(gè)父節(jié)點(diǎn)下數(shù)據(jù)或者子節(jié)點(diǎn)變化都會(huì)通知對(duì)該節(jié)點(diǎn)進(jìn)行watch的客戶端楣责。因?yàn)镋PHEMERAL類型節(jié)點(diǎn)有一個(gè)很重要的特性,就是客戶端和服務(wù)器端連接斷掉或者session過期就會(huì)使節(jié)點(diǎn)消失聂沙,那么在某一個(gè)機(jī)器掛掉或者斷鏈的時(shí)候腐魂,其對(duì)應(yīng)的節(jié)點(diǎn)就會(huì)消失,然后集群中所有對(duì)/APP1SERVERS進(jìn)行watch的客戶端都會(huì)收到通知逐纬,然后取得最新列表即可蛔屹。

另外有一個(gè)應(yīng)用場景就是集群選master,一旦master掛掉能夠馬上能從slave中選出一個(gè)master,實(shí)現(xiàn)步驟和前者一樣,只是機(jī)器在啟動(dòng)的時(shí)候在APP1SERVERS創(chuàng)建的節(jié)點(diǎn)類型變?yōu)镋PHEMERAL_SEQUENTIAL類型豁生,這樣每個(gè)節(jié)點(diǎn)會(huì)自動(dòng)被編號(hào)

我們默認(rèn)規(guī)定編號(hào)最小的為master,所以當(dāng)我們對(duì)/APP1SERVERS節(jié)點(diǎn)做監(jiān)控的時(shí)候兔毒,得到服務(wù)器列表,只要所有集群機(jī)器邏輯認(rèn)為最小編號(hào)節(jié)點(diǎn)為master甸箱,那么master就被選出育叁,而這個(gè)master宕機(jī)的時(shí)候,相應(yīng)的znode會(huì)消失芍殖,然后新的服務(wù)器列表就被推送到客戶端豪嗽,然后每個(gè)節(jié)點(diǎn)邏輯認(rèn)為最小編號(hào)節(jié)點(diǎn)為master,這樣就做到動(dòng)態(tài)master選舉。

Zookeeper 監(jiān)視(Watches) 簡介

Zookeeper C API 的聲明和描述在 include/zookeeper.h 中可以找到龟梦,另外大部分的 Zookeeper C API 常量隐锭、結(jié)構(gòu)體聲明也在 zookeeper.h 中,如果如果你在使用 C API 是遇到不明白的地方计贰,最好看看 zookeeper.h钦睡,或者自己使用 doxygen 生成 Zookeeper C API 的幫助文檔。

Zookeeper 中最有特色且最不容易理解的是監(jiān)視(Watches)躁倒。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, which occurs when the data for which the watch was set changes秧秉。對(duì)此需要作出如下理解:

(一次性觸發(fā))One-time trigger

當(dāng)設(shè)置監(jiān)視的數(shù)據(jù)發(fā)生改變時(shí)褐桌,該監(jiān)視事件會(huì)被發(fā)送到客戶端,例如象迎,如果客戶端調(diào)用了 getData("/znode1", true) 并且稍后 /znode1 節(jié)點(diǎn)上的數(shù)據(jù)發(fā)生了改變或者被刪除了撩嚼,客戶端將會(huì)獲取到 /znode1 發(fā)生變化的監(jiān)視事件,而如果 /znode1 再一次發(fā)生了變化挖帘,除非客戶端再次對(duì) /znode1 設(shè)置監(jiān)視,否則客戶端不會(huì)收到事件通知恋技。

(發(fā)送至客戶端)Sent to the client

Zookeeper 客戶端和服務(wù)端是通過 socket 進(jìn)行通信的拇舀,由于網(wǎng)絡(luò)存在故障,所以監(jiān)視事件很有可能不會(huì)成功地到達(dá)客戶端蜻底,監(jiān)視事件是異步發(fā)送至監(jiān)視者的骄崩,Zookeeper 本身提供了保序性(ordering guarantee):即客戶端只有首先看到了監(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)致不同的客戶端在不同的時(shí)刻感知某一監(jiān)視事件薄辅,但是不同的客戶端所看到的一切具有一致的順序要拂。

(被設(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() and 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)客戶端與 Zookeeper 服務(wù)器端失去聯(lián)系時(shí)叉橱,客戶端并不會(huì)收到監(jiān)視事件的通知,只有當(dāng)客戶端重新連接后痴颊,若在必要的情況下赏迟,以前注冊(cè)的監(jiān)視會(huì)重新被注冊(cè)并觸發(fā),對(duì)于開發(fā)人員來說 這通常是透明的蠢棱。只有一種情況會(huì)導(dǎo)致監(jiān)視事件的丟失锌杀,即:通過 exists() 設(shè)置了某個(gè) znode 節(jié)點(diǎn)的監(jiān)視,但是如果某個(gè)客戶端在此 znode 節(jié)點(diǎn)被創(chuàng)建和刪除的時(shí)間間隔內(nèi)與 zookeeper 服務(wù)器失去了聯(lián)系泻仙,該客戶端即使稍后重新連接 zookeeper服務(wù)器后也得不到事件通知糕再。

Zookeeper C API 常量與部分結(jié)構(gòu)(struct)介紹

與 ACL 相關(guān)的結(jié)構(gòu)與常量:

struct Id 結(jié)構(gòu)為:

struct?Id?{?????char?*?scheme;?????char?*?id;?};

struct ACL 結(jié)構(gòu)為:

struct?ACL?{?????int32_t?perms;?????struct?Id?id;?};

struct ACL_vector 結(jié)構(gòu)為:

struct?ACL_vector?{?????int32_t?count;?????struct?ACL?*data;?};

與 znode 訪問權(quán)限有關(guān)的常量

constintZOO_PERM_READ; //允許客戶端讀取 znode 節(jié)點(diǎn)的值以及子節(jié)點(diǎn)列表。

constintZOO_PERM_WRITE;// 允許客戶端設(shè)置 znode 節(jié)點(diǎn)的值玉转。

constintZOO_PERM_CREATE; //允許客戶端在該 znode 節(jié)點(diǎn)下創(chuàng)建子節(jié)點(diǎn)突想。

constintZOO_PERM_DELETE;//允許客戶端刪除子節(jié)點(diǎn)。

constintZOO_PERM_ADMIN; //允許客戶端執(zhí)行 set_acl()究抓。

constintZOO_PERM_ALL;//允許客戶端執(zhí)行所有操作猾担,等價(jià)與上述所有標(biāo)志的或(OR) 。

與 ACL IDs 相關(guān)的常量

structId ZOO_ANYONE_ID_UNSAFE; //(‘world’,’anyone’)

structId ZOO_AUTH_IDS;// (‘a(chǎn)uth’,’’)

三種標(biāo)準(zhǔn)的 ACL

structACL_vector ZOO_OPEN_ACL_UNSAFE; //(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE)

structACL_vector ZOO_READ_ACL_UNSAFE;// (ZOO_PERM_READ, ZOO_ANYONE_ID_UNSAFE)

structACL_vector ZOO_CREATOR_ALL_ACL; //(ZOO_PERM_ALL,ZOO_AUTH_IDS)

與 Interest 相關(guān)的常量:ZOOKEEPER_WRITE,ZOOKEEPER_READ

這 兩個(gè)常量用于標(biāo)識(shí)感興趣的事件并通知 zookeeper 發(fā)生了哪些事件刺下。Interest 常量可以進(jìn)行組合或(OR)來標(biāo)識(shí)多種興趣(multiple interests: write, read)绑嘹,這兩個(gè)常量一般用于 zookeeper_interest() 和 zookeeper_process()兩個(gè)函數(shù)中。

與節(jié)點(diǎn)創(chuàng)建相關(guān)的常量:ZOO_EPHEMERAL,ZOO_SEQUENCE

zoo_create 函數(shù)標(biāo)志橘茉,ZOO_EPHEMERAL用來標(biāo)識(shí)創(chuàng)建臨時(shí)節(jié)點(diǎn)工腋,ZOO_SEQUENCE用來標(biāo)識(shí)節(jié)點(diǎn)命名具有遞增的后綴序號(hào)(一般是節(jié)點(diǎn)名稱后填充 10 位字符的序號(hào),如 /xyz0000000000, /xyz0000000001, /xyz0000000002, ...)畅卓,同樣地擅腰,ZOO_EPHEMERAL,ZOO_SEQUENCE可以組合。

與連接狀態(tài) Stat 相關(guān)的常量

以下常量均與 Zookeeper 連接狀態(tài)有關(guān)翁潘,他們通常用作監(jiān)視器回調(diào)函數(shù)的參數(shù)趁冈。

ZOOAPI const intZOO_EXPIRED_SESSION_STATE

ZOOAPI const intZOO_AUTH_FAILED_STATE

ZOOAPI const intZOO_CONNECTING_STATE

ZOOAPI const intZOO_ASSOCIATING_STATE

ZOOAPI const intZOO_CONNECTED_STATE

與監(jiān)視類型(Watch Types)相關(guān)的常量

以下常量標(biāo)識(shí)監(jiān)視事件的類型,他們通常用作監(jiān)視器回調(diào)函數(shù)的第一個(gè)參數(shù)拜马。

ZOO_CREATED_EVENT; // 節(jié)點(diǎn)被創(chuàng)建(此前該節(jié)點(diǎn)不存在)箱歧,通過 zoo_exists() 設(shè)置監(jiān)視。

ZOO_DELETED_EVENT; // 節(jié)點(diǎn)被刪除一膨,通過 zoo_exists() 和 zoo_get() 設(shè)置監(jiān)視呀邢。

ZOO_CHANGED_EVENT; // 節(jié)點(diǎn)發(fā)生變化,通過 zoo_exists() 和 zoo_get() 設(shè)置監(jiān)視豹绪。

ZOO_CHILD_EVENT; // 子節(jié)點(diǎn)事件价淌,通過zoo_get_children() 和 zoo_get_children2()設(shè)置監(jiān)視申眼。

ZOO_SESSION_EVENT; // 會(huì)話丟失

ZOO_NOTWATCHING_EVENT; // 監(jiān)視被移除。

Zookeeper C API 錯(cuò)誤碼介紹ZOO_ERRORS

ZOK正常返回

ZSYSTEMERROR系統(tǒng)或服務(wù)器端錯(cuò)誤(System and server-side errors)蝉衣,服務(wù)器不會(huì)拋出該錯(cuò)誤括尸,該錯(cuò)誤也只是用來標(biāo)識(shí)錯(cuò)誤范圍的,即大于該錯(cuò)誤值病毡,且小于 ZAPIERROR 都是系統(tǒng)錯(cuò)誤濒翻。

ZRUNTIMEINCONSISTENCY運(yùn)行時(shí)非一致性錯(cuò)誤。

ZDATAINCONSISTENCY數(shù)據(jù)非一致性錯(cuò)誤啦膜。

ZCONNECTIONLOSSZookeeper 客戶端與服務(wù)器端失去連接

ZMARSHALLINGERROR在marshalling和unmarshalling數(shù)據(jù)時(shí)出現(xiàn)錯(cuò)誤(Error while marshalling or unmarshalling data)

ZUNIMPLEMENTED該操作未實(shí)現(xiàn)(Operation is unimplemented)

ZOPERATIONTIMEOUT該操作超時(shí)(Operation timeout)

ZBADARGUMENTS非法參數(shù)錯(cuò)誤(Invalid arguments)

ZINVALIDSTATE非法句柄狀態(tài)(Invliad zhandle state)

ZAPIERRORAPI 錯(cuò)誤(API errors)有送,服務(wù)器不會(huì)拋出該錯(cuò)誤,該錯(cuò)誤也只是用來標(biāo)識(shí)錯(cuò)誤范圍的僧家,錯(cuò)誤值大于該值的標(biāo)識(shí) API 錯(cuò)誤雀摘,而小于該值的標(biāo)識(shí) ZSYSTEMERROR。

ZNONODE節(jié)點(diǎn)不存在(Node does not exist)

ZNOAUTH沒有經(jīng)過授權(quán)(Not authenticated)

ZBADVERSION版本沖突(Version conflict)

ZNOCHILDRENFOREPHEMERALS臨時(shí)節(jié)點(diǎn)不能擁有子節(jié)點(diǎn)(Ephemeral nodes may not have children)

ZNODEEXISTS節(jié)點(diǎn)已經(jīng)存在(The node already exists)

ZNOTEMPTY該節(jié)點(diǎn)具有自身的子節(jié)點(diǎn)(The node has children)

ZSESSIONEXPIRED會(huì)話過期(The session has been expired by the server)

ZINVALIDCALLBACK非法的回調(diào)函數(shù)(Invalid callback specified)

ZINVALIDACL非法的ACL(Invalid ACL specified)

ZAUTHFAILED客戶端授權(quán)失敗(Client authentication failed)

ZCLOSINGZookeeper 連接關(guān)閉(ZooKeeper is closing)

ZNOTHING并非錯(cuò)誤八拱,客戶端不需要處理服務(wù)器的響應(yīng)(not error, no server responses to process)

ZSESSIONMOVED會(huì)話轉(zhuǎn)移至其他服務(wù)器阵赠,所以操作被忽略(session moved to another server, so operation is ignored)

Watch事件類型:

ZOO_CREATED_EVENT:節(jié)點(diǎn)創(chuàng)建事件,需要watch一個(gè)不存在的節(jié)點(diǎn)肌稻,當(dāng)節(jié)點(diǎn)被創(chuàng)建時(shí)觸發(fā)清蚀,此watch通過zoo_exists()設(shè)置

ZOO_DELETED_EVENT:節(jié)點(diǎn)刪除事件,此watch通過zoo_exists()或zoo_get()設(shè)置

ZOO_CHANGED_EVENT:節(jié)點(diǎn)數(shù)據(jù)改變事件爹谭,此watch通過zoo_exists()或zoo_get()設(shè)置

ZOO_CHILD_EVENT:子節(jié)點(diǎn)列表改變事件枷邪,此watch通過zoo_get_children()或zoo_get_children2()設(shè)置

ZOO_SESSION_EVENT:會(huì)話失效事件,客戶端與服務(wù)端斷開或重連時(shí)觸發(fā)

ZOO_NOTWATCHING_EVENT:watch移除事件旦棉,服務(wù)端出于某些原因不再為客戶端watch節(jié)點(diǎn)時(shí)觸發(fā)

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市药薯,隨后出現(xiàn)的幾起案子绑洛,更是在濱河造成了極大的恐慌,老刑警劉巖童本,帶你破解...
    沈念sama閱讀 206,214評(píng)論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件真屯,死亡現(xiàn)場離奇詭異,居然都是意外死亡穷娱,警方通過查閱死者的電腦和手機(jī)绑蔫,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,307評(píng)論 2 382
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來泵额,“玉大人配深,你說我怎么就攤上這事〖廾ぃ” “怎么了篓叶?”我有些...
    開封第一講書人閱讀 152,543評(píng)論 0 341
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我缸托,道長左敌,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 55,221評(píng)論 1 279
  • 正文 為了忘掉前任俐镐,我火速辦了婚禮矫限,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘佩抹。我一直安慰自己叼风,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 64,224評(píng)論 5 371
  • 文/花漫 我一把揭開白布匹摇。 她就那樣靜靜地躺著咬扇,像睡著了一般。 火紅的嫁衣襯著肌膚如雪廊勃。 梳的紋絲不亂的頭發(fā)上懈贺,一...
    開封第一講書人閱讀 49,007評(píng)論 1 284
  • 那天,我揣著相機(jī)與錄音坡垫,去河邊找鬼梭灿。 笑死,一個(gè)胖子當(dāng)著我的面吹牛冰悠,可吹牛的內(nèi)容都是我干的堡妒。 我是一名探鬼主播,決...
    沈念sama閱讀 38,313評(píng)論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼溉卓,長吁一口氣:“原來是場噩夢(mèng)啊……” “哼皮迟!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起桑寨,我...
    開封第一講書人閱讀 36,956評(píng)論 0 259
  • 序言:老撾萬榮一對(duì)情侶失蹤伏尼,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后尉尾,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體爆阶,經(jīng)...
    沈念sama閱讀 43,441評(píng)論 1 300
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 35,925評(píng)論 2 323
  • 正文 我和宋清朗相戀三年沙咏,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了辨图。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 38,018評(píng)論 1 333
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡肢藐,死狀恐怖故河,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情吆豹,我是刑警寧澤忧勿,帶...
    沈念sama閱讀 33,685評(píng)論 4 322
  • 正文 年R本政府宣布杉女,位于F島的核電站,受9級(jí)特大地震影響鸳吸,放射性物質(zhì)發(fā)生泄漏熏挎。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,234評(píng)論 3 307
  • 文/蒙蒙 一晌砾、第九天 我趴在偏房一處隱蔽的房頂上張望坎拐。 院中可真熱鬧,春花似錦养匈、人聲如沸哼勇。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,240評(píng)論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽积担。三九已至,卻和暖如春猬仁,著一層夾襖步出監(jiān)牢的瞬間帝璧,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,464評(píng)論 1 261
  • 我被黑心中介騙來泰國打工湿刽, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留的烁,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 45,467評(píng)論 2 352
  • 正文 我出身青樓诈闺,卻偏偏與公主長得像渴庆,于是被迫代替她去往敵國和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子雅镊,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,762評(píng)論 2 345

推薦閱讀更多精彩內(nèi)容

  • ZooKeeper是一個(gè)分布式的襟雷,開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù),它包含一個(gè)簡單的原語集仁烹,分布式應(yīng)用程序可以基于...
    rthsfjhtrj閱讀 553評(píng)論 0 1
  • ZooKeeper是一個(gè)分布式的耸弄,開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù),它包含一個(gè)簡單的原語集晃危,分布式應(yīng)用程序可以基于...
    Prize閱讀 240評(píng)論 0 1
  • ZooKeeper是一個(gè)分布式的叙赚,開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)老客,它包含一個(gè)簡單的原語集僚饭,分布式應(yīng)用程序可以基于...
    藍(lán)色的咖啡閱讀 467評(píng)論 0 2
  • 一個(gè)真正的寫數(shù)據(jù)流程是怎么樣的?一個(gè)真正的讀數(shù)據(jù)流程是怎么樣的胧砰?一個(gè)真正的同步數(shù)據(jù)流程是怎么樣的鳍鸵?從哪里到哪里?什...
    時(shí)待吾閱讀 4,004評(píng)論 0 14
  • #紅點(diǎn)移動(dòng)的原理 params.leftMargin = 間距間的滑動(dòng)距離 公式: 間距間的滑動(dòng)距離 : 間距 =...
    ZebraWei閱讀 549評(píng)論 0 1