更新時(shí)間:2020-11-06 來(lái)源:黑馬程序員 瀏覽量:
ZooKeeper是一個(gè)分布式的,開(kāi)放源碼的分布式 應(yīng)用程序協(xié)調(diào)服務(wù) ,是Google的Chubby一個(gè)開(kāi)源的實(shí)現(xiàn), 它是集群的管理者,監(jiān)視著集群中各個(gè)節(jié)點(diǎn)的狀態(tài)根據(jù)節(jié)點(diǎn)提交的反饋進(jìn)行下一步合理操作。最終,將簡(jiǎn)單易 用的接口和性能高效、功能穩(wěn)定的系統(tǒng)提供給用戶(hù)。 客戶(hù)端的 讀請(qǐng)求 可以被集群中的 任意一臺(tái)機(jī)器處理 ,如果讀請(qǐng)求在節(jié)點(diǎn)上注冊(cè)了監(jiān)聽(tīng)器,這個(gè)監(jiān)聽(tīng)器也是由所 連接的zookeeper機(jī)器來(lái)處理。對(duì)于 寫(xiě)請(qǐng)求 ,這些請(qǐng)求會(huì)同 時(shí)發(fā)給其他 zookeeper 機(jī)器并且達(dá)成一致后,請(qǐng) 求才會(huì)返回成功 。因此,隨著 zookeeper 的集群機(jī)器增多,讀請(qǐng)求的吞吐會(huì)提高但是寫(xiě)請(qǐng)求的吞吐會(huì)下降 。有序性是zookeeper中非常重要的一個(gè)特性,所有的 更新都是全局有序的 ,每個(gè)更新都有一個(gè) 唯一的時(shí)間戳 , 這個(gè)時(shí)間戳稱(chēng)為 zxid ( Zookeeper Transaction Id ) 。而 讀請(qǐng)求只會(huì)相對(duì)于更新有序 ,也就是讀請(qǐng)求的返回 結(jié)果中會(huì)帶有這個(gè) zookeeper 最新的 zxid 。
1、文件系統(tǒng)
2、通知機(jī)制
Zookeeper提供一個(gè)多層級(jí)的節(jié)點(diǎn)命名空間(節(jié)點(diǎn)稱(chēng)為znode)。與文件系統(tǒng)不同的是,這些節(jié)點(diǎn) 都可以設(shè)置 關(guān)聯(lián)的數(shù)據(jù) ,而文件系統(tǒng)中只有文件節(jié)點(diǎn)可以存放數(shù)據(jù)而目錄節(jié)點(diǎn)不行。Zookeeper為了保證高吞吐和低延 遲,在內(nèi)存中維護(hù)了這個(gè)樹(shù)狀的目錄結(jié)構(gòu),這種特性使得Zookeeper 不能用于存放大量的數(shù)據(jù) ,每個(gè)節(jié)點(diǎn)的存 放數(shù)據(jù)上限為 1M 。
1、PERSISTENT- 持久化目錄節(jié)點(diǎn) 客戶(hù)端與zookeeper斷開(kāi)連接后,該節(jié)點(diǎn)依舊存在
2、PERSISTENT_SEQUENTIAL- 持久化順序編號(hào)目錄節(jié)點(diǎn)
客戶(hù)端與zookeeper斷開(kāi)連接后,該節(jié)點(diǎn)依舊存在,只是Zookeeper給該節(jié)點(diǎn)名稱(chēng)進(jìn)行順序編號(hào)
3、EPHEMERAL- 臨時(shí)目錄節(jié)點(diǎn)
客戶(hù)端與zookeeper斷開(kāi)連接后,該節(jié)點(diǎn)被刪除
4、EPHEMERAL_SEQUENTIAL- 臨時(shí)順序編號(hào)目錄節(jié)點(diǎn)客戶(hù)端與zookeeper斷開(kāi)連接后,該節(jié)點(diǎn)被刪除,只是Zookeeper給該節(jié)點(diǎn)名稱(chēng)進(jìn)行順序編號(hào)。
client端會(huì)對(duì)某個(gè)znode建立一個(gè)watcher 事件 ,當(dāng)該znode發(fā)生變化時(shí),這些client會(huì)收到zk的通知, 然后client可以根據(jù)znode變化來(lái)做出業(yè)務(wù)上的改變等。
1、命名服務(wù) 2、配置管理 3、集群管理 4、分布式鎖 5、隊(duì)列管理
命名服務(wù)是指通過(guò)指定的名字來(lái)獲取資源或者服務(wù)的地址,利用zk創(chuàng)建一個(gè)全局的路徑,即是唯一的路徑,這個(gè)路徑就可以作為一個(gè)名字,指向集群中的集群,提供的服務(wù)的地址,或者一個(gè)遠(yuǎn)程的對(duì)象等等。
程序分布式的部署在不同的機(jī)器上,將程序的配置信息放在zk的znode 下,當(dāng)有配置發(fā)生改變時(shí),也就是 znode發(fā)生變化時(shí),可以通過(guò)改變zk中某個(gè)目錄節(jié)點(diǎn)的內(nèi)容,利用 watcher 通知給各個(gè)客戶(hù)端,從而更改配置。
所謂集群管理無(wú)在乎兩點(diǎn):是否有機(jī)器退出和加入、選舉master。對(duì)于第一點(diǎn),所有機(jī)器約定在父目錄下創(chuàng)建臨時(shí)目錄節(jié)點(diǎn),然后監(jiān)聽(tīng)父目錄節(jié)點(diǎn)的子節(jié)點(diǎn)變化消息。一旦有機(jī)器掛掉,該機(jī)器與 zookeeper的連接斷開(kāi),其所創(chuàng)建的臨時(shí)目錄節(jié)點(diǎn)被刪除,所有其他機(jī)器都收到通知:某個(gè)兄弟目錄被刪除,于是,所有人都知道:它上船了。新機(jī)器加入也是類(lèi)似,所有機(jī)器收到通知:新兄弟目錄加入,highcount又有了,對(duì)于第二點(diǎn),我們稍微改變 一下,所有機(jī)器創(chuàng)建臨時(shí)順序編號(hào)目錄節(jié)點(diǎn),每次選取編號(hào)最小的機(jī)器作為 master 就好。
有了zookeeper的一致性文件系統(tǒng),鎖的問(wèn)題變得容易。鎖服務(wù)可以分為兩類(lèi),一個(gè)是保持獨(dú)占,另一個(gè)是控制時(shí)序 。 對(duì)于第一類(lèi),我們將zookeeper上的一個(gè)znode看作是一把鎖,通過(guò)createznode的方式來(lái)實(shí)現(xiàn)。所有客戶(hù) 端都去創(chuàng)建 /distribute_lock 節(jié)點(diǎn),最終成功創(chuàng)建的那個(gè)客戶(hù)端也即擁有了這把鎖。用完刪除掉自己創(chuàng)建的 distribute_lock 節(jié)點(diǎn)就釋放出鎖。(驚群)
對(duì)于第二類(lèi), /distribute_lock 已經(jīng)預(yù)先存在,所有客戶(hù)端在它下面創(chuàng)建臨時(shí)順序編號(hào)目錄節(jié)點(diǎn),和選 master一樣, 編號(hào)最小的獲得鎖 ,用完刪除,依次方便。
1、Zookeeper當(dāng)master掛了,會(huì)在30-120s進(jìn)行l(wèi)eader選舉,這點(diǎn)類(lèi)似于redis的哨兵機(jī)制,在選舉期間Zookeeper是不可用的,這么長(zhǎng)時(shí)間不能進(jìn)行服務(wù)注冊(cè),是無(wú)法忍受的,別說(shuō)30s,5s都不能忍受。這時(shí)Zookeeper集群會(huì)癱瘓,這也是Zookeeper的CP,保持節(jié)點(diǎn)的一致性,犧牲了A/高可用。
2、而Eureka不會(huì),即使Eureka有部分掛掉,還有其他節(jié)點(diǎn)可以使用的,他們保持平級(jí)的關(guān)系,只不過(guò)信息有可能不一致,這就是AP,犧牲了C/一致性。并且Eureka還提供了自我保護(hù)機(jī)制(15分鐘內(nèi)超過(guò)85%的服務(wù)節(jié)點(diǎn)沒(méi)有心跳/down),這點(diǎn)我覺(jué)得確實(shí)要比Zookeeper好,即使服務(wù)不可用,也會(huì)保留當(dāng)前失效的微服務(wù),默認(rèn)90秒,在這90秒Eureka不會(huì)注銷(xiāo)微服務(wù),在這90秒內(nèi)仍然可以接受新的服務(wù)注冊(cè),只是不會(huì)同步到其他節(jié)點(diǎn)上。當(dāng)壞掉的服務(wù)恢復(fù)的時(shí)候,會(huì)自動(dòng)加入到節(jié)點(diǎn)上,也是高可用的一種。然后退出自我保護(hù)機(jī)制,這也是應(yīng)對(duì)網(wǎng)絡(luò)異常的一種機(jī)制。
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)者被選舉出來(lái),且大多數(shù)Server完成了和leader的狀態(tài)同步以后,恢復(fù) 模式就結(jié)束了。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。
zookeeper采用了 遞增的事務(wù) Id 來(lái)標(biāo)識(shí),所有的proposal(提議)都在被提出的時(shí)候加上了zxid,zxid實(shí)際 上是一個(gè)64位的數(shù)字,高32位是epoch(時(shí)期; 紀(jì)元; 世; 新時(shí)代)用來(lái)標(biāo)識(shí)leader是否發(fā)生改變,如果有 新的leader產(chǎn)生出來(lái),epoch會(huì)自增, 低 32 位用來(lái)遞增計(jì)數(shù) 。當(dāng)新產(chǎn)生proposal的時(shí)候,會(huì)依據(jù)數(shù)據(jù)庫(kù)的 兩階段過(guò)程,首先會(huì)向其他的server發(fā)出事務(wù)執(zhí)行請(qǐng)求,如果超過(guò)半數(shù)的機(jī)器都能執(zhí)行并且能夠成功,那么就 會(huì)開(kāi)始執(zhí)行。
每個(gè)Server在工作過(guò)程中有三種狀態(tài):LOOKING:當(dāng)前Server不知道leader是誰(shuí) ,正在搜尋 LEADING:當(dāng)前Server即為選舉出來(lái)的leader FOLLOWING:leader已經(jīng)選舉出來(lái),當(dāng)前Server與之同步。
當(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 。
1、Zookeeper選主流程(basic paxos)
(1)選舉線程由當(dāng)前Server發(fā)起選舉的線程擔(dān)任,其主要功能是對(duì)投票結(jié)果進(jìn)行統(tǒng)計(jì),并選出推薦的 Server;
(2)選舉線程首先向所有Server發(fā)起一次詢(xún)問(wèn)(包括自己);
(3)選舉線程收到回復(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)次選舉的投 票記錄表中;
(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è)過(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ù)。
2、Zookeeper選主流程(fast paxos)
fast paxos流程是在選舉過(guò)程中,某Server首先向所有Server提議自己要成為leader,當(dāng)其它Server收到提 議以后,解決epoch和 zxid的沖突,并接受對(duì)方的提議,然后向?qū)Ψ桨l(fā)送接受提議完成的消息,重復(fù)這個(gè)流程,最后一定能選舉出Leader。
選完Leader以后,zk就進(jìn)入狀態(tài)同步過(guò)程。
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ù)了。
對(duì)于系統(tǒng)調(diào)度來(lái)說(shuō):操作人員發(fā)送通知實(shí)際是通過(guò)控制臺(tái)改變某個(gè)節(jié)點(diǎn)的狀態(tài), 然后zk將這些變化發(fā)送給注冊(cè)了這個(gè)節(jié)點(diǎn)的watcher的所有客戶(hù)端。對(duì)于執(zhí)行情況匯報(bào):每個(gè)工作進(jìn)程都在某個(gè)目錄下創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn)。并攜帶工作的進(jìn)度數(shù)據(jù),這樣匯總的進(jìn)程可以監(jiān)控目錄子節(jié)點(diǎn)的變化獲得工作進(jìn)度的實(shí)時(shí)的全局情況 。
在分布式環(huán)境中,有些業(yè)務(wù)邏輯只需要集群中的某一臺(tái)機(jī)器進(jìn)行執(zhí)行, 其他的機(jī)器可以共享這個(gè)結(jié)果 ,這樣可 以大大 減少重復(fù)計(jì)算 , 提高性能 ,于是就需要進(jìn)行l(wèi)eader選舉。
Zookeeper本身也是集群,推薦配置不少于3個(gè)服務(wù)器。Zookeeper自身也要保證當(dāng)一個(gè)節(jié)點(diǎn)宕機(jī)時(shí),其他 節(jié)點(diǎn)會(huì)繼續(xù)提供服務(wù)。 如果是一個(gè)Follower宕機(jī),還有2臺(tái)服務(wù)器提供訪問(wèn),因?yàn)閆ookeeper上的數(shù)據(jù)是有多個(gè)副本的,數(shù)據(jù)并不 會(huì)丟失; 如果是一個(gè)Leader宕機(jī),Zookeeper會(huì)選舉出新的Leader。 ZK集群的機(jī)制是只要超過(guò)半數(shù)的節(jié)點(diǎn)正常,集群就能正常提供服務(wù)。只有在ZK節(jié)點(diǎn)掛得太多,只剩一半或不 到一半節(jié)點(diǎn)能工作,集群才失效。 所以 3個(gè)節(jié)點(diǎn)的cluster可以?huà)斓?個(gè)節(jié)點(diǎn)(leader可以得到2票>1.5) 2個(gè)節(jié)點(diǎn)的cluster就不能掛掉任何1個(gè)節(jié)點(diǎn)了(leader可以得到1票<=1) 。
zk的負(fù)載均衡是可以調(diào)控,nginx只是能調(diào)權(quán)重,其他需要可控的都需要自己寫(xiě)插件;但是nginx的吞吐量比 zk大很多,應(yīng)該說(shuō)按業(yè)務(wù)選擇用哪種方式。
Watch機(jī)制官方聲明:一個(gè)Watch事件是一個(gè)一次性的觸發(fā)器,當(dāng)被設(shè)置了Watch的數(shù)據(jù)發(fā)生了改變的時(shí) 候,則服務(wù)器將這個(gè)改變發(fā)送給設(shè)置了Watch的客戶(hù)端,以便通知它們。 Zookeeper機(jī)制的特點(diǎn):
1、一次性觸發(fā)數(shù)據(jù)發(fā)生改變時(shí),一個(gè)watcher event會(huì)被發(fā)送到client,但是client只會(huì)收到一次這樣的信息 。
2、watcher event異步發(fā)送watcher的通知事件從server發(fā)送到client是 異步 的,這就存在一個(gè)問(wèn)題,不同 的客戶(hù)端和服務(wù)器之間通過(guò)socket進(jìn)行通信,由于 網(wǎng)絡(luò)延遲或其他因素導(dǎo)致客戶(hù)端在不通的時(shí)刻監(jiān)聽(tīng)到事件 , 由于Zookeeper本身提供了 ordering guarantee ,即客戶(hù)端監(jiān)聽(tīng)事件后,才會(huì)感知它所監(jiān)視 znode 發(fā)生了變化 。所以我們使用Zookeeper不能期望能夠監(jiān)控到節(jié)點(diǎn)每次的變化。Zookeeper 只能保證最終的一致性, 而無(wú)法保證強(qiáng)一致性 。
3、數(shù)據(jù)監(jiān)視Zookeeper有數(shù)據(jù)監(jiān)視和子數(shù)據(jù)監(jiān)視getdata() and exists()設(shè)置數(shù)據(jù)監(jiān)視,getchildren()設(shè)置了 子節(jié)點(diǎn)監(jiān)視。
4、注冊(cè)watcher getData、exists、getChildren。
5、觸發(fā)watcher create 、 delete 、 setData。
6、 setData()會(huì)觸發(fā)znode上設(shè)置的data watch(如果set成功的話(huà))。一個(gè)成功的 create()操作會(huì)觸發(fā)被創(chuàng)建的znode上的數(shù)據(jù)watch,以及其父節(jié)點(diǎn)上的child watch。而一個(gè)成功的delete() 操作將會(huì)同時(shí)觸發(fā)一個(gè)znode的data watch和child watch(因?yàn)檫@樣就沒(méi)有子節(jié)點(diǎn)了),同時(shí)也會(huì)觸發(fā)其父節(jié)點(diǎn)的child watch。
7、當(dāng)一個(gè)客戶(hù)端連接到一個(gè)新的服務(wù)器上時(shí),watch將會(huì)被以任意會(huì)話(huà)事件觸發(fā)。當(dāng)與一個(gè)服務(wù)器失去連接的時(shí)候,是無(wú)法接收到watch的。而當(dāng)client重新連接時(shí),如果需要的話(huà),所有先前注冊(cè)過(guò)的watch,都會(huì)被重新注冊(cè)。通常這是完全透明的。只有在一個(gè)特殊情況下,watch可能會(huì)丟失:對(duì)于一個(gè)未創(chuàng)建的znode的exist watch,如果在客戶(hù)端斷開(kāi)連接期間被創(chuàng)建了,并且隨后在客戶(hù)端連接上之前又刪除了,這種情況下,這個(gè)watch事件可能會(huì)被丟失。
8、Watch是輕量級(jí)的,其實(shí)就是本地JVM的Callback,服務(wù)器端只是存了是否有設(shè)置了Watcher的布爾類(lèi)型。
猜你喜歡: