国产 无码 综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

ZooKeeper的應(yīng)用場(chǎng)景(集群管理、Master選舉)

這篇具有很好參考價(jià)值的文章主要介紹了ZooKeeper的應(yīng)用場(chǎng)景(集群管理、Master選舉)。希望對(duì)大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方,請(qǐng)大家不吝賜教,您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問(wèn)。

5 集群管理

隨著分布式系統(tǒng)規(guī)模的日益擴(kuò)大,集群中的機(jī)器規(guī)模也隨之變大,因此,如何更好地進(jìn)行集群管理也顯得越來(lái)越重要了。

所謂集群管理,包括集群監(jiān)控與集群控制兩大塊,前者側(cè)重對(duì)集群運(yùn)行時(shí)狀態(tài)的收集,后者則是對(duì)集群進(jìn)行操作與控制。在日常開發(fā)和運(yùn)維過(guò)程中,我們經(jīng)常會(huì)有類似于如下的需求。

(1)希望知道當(dāng)前集群中究竟有多少機(jī)器在工作。

(2)對(duì)集群中每臺(tái)機(jī)器的運(yùn)行時(shí)狀態(tài)進(jìn)行數(shù)據(jù)收集。

(3)對(duì)集群中機(jī)器進(jìn)行上下線操作。

在傳統(tǒng)的基于Agent的分布式集群管理體系中,都是通過(guò)在集群中的每臺(tái)機(jī)器上部署一個(gè)Agent,由這個(gè)Agent負(fù)責(zé)主動(dòng)向指定的一個(gè)監(jiān)控中心系統(tǒng)(監(jiān)控中心系統(tǒng)負(fù)責(zé)將所有數(shù)據(jù)進(jìn)行集中處理,形成一系列報(bào)表,并負(fù)責(zé)實(shí)時(shí)報(bào)警,以下簡(jiǎn)稱“監(jiān)控中心”)匯報(bào)自己所在機(jī)器的狀態(tài)。在集群規(guī)模適中的場(chǎng)景下,這確實(shí)是一種在生產(chǎn)實(shí)踐中廣泛使用的解決方案,能夠快速有效地實(shí)現(xiàn)分布式環(huán)境集群監(jiān)控,但是一旦系統(tǒng)的業(yè)務(wù)場(chǎng)景增多,集群規(guī)模變大之后,該解決方案的弊端也就顯現(xiàn)出來(lái)了。

大規(guī)模升級(jí)困難

以客戶端形式存在的Agent,在大規(guī)模使用后,一旦遇上需要大規(guī)模升級(jí)的情況,就非常麻煩,在升級(jí)成本和升級(jí)進(jìn)度的控制上面臨巨大的挑戰(zhàn)。

統(tǒng)一的Agent無(wú)法滿足多樣的需求

對(duì)于機(jī)器的CPU使用率、負(fù)載(Load)、內(nèi)存使用率、網(wǎng)絡(luò)吞吐以及磁盤容量等機(jī)器基本的物理狀態(tài),使用統(tǒng)一的Agent來(lái)進(jìn)行監(jiān)控或許都可以滿足。但是,如果需要深入應(yīng)用內(nèi)部,對(duì)一些業(yè)務(wù)狀態(tài)進(jìn)行監(jiān)控,例如,在一個(gè)分布式消息中間件中,希望監(jiān)控到每個(gè)消費(fèi)者對(duì)消息的消費(fèi)狀態(tài);或者在一個(gè)分布式任務(wù)調(diào)度系統(tǒng)中,需要對(duì)每個(gè)機(jī)器上任務(wù)的執(zhí)行情況進(jìn)行監(jiān)控。很顯然,對(duì)于這些業(yè)務(wù)耦合緊密的監(jiān)控需求,不適合由一個(gè)統(tǒng)一的Agent來(lái)提供。

編程語(yǔ)言多樣性

隨著越來(lái)越多編程語(yǔ)言的出現(xiàn),各種異構(gòu)系統(tǒng)層出不窮。如果使用傳統(tǒng)的Agent方式,那么需要提供各種語(yǔ)言的Agent 客戶端。另一方面,“監(jiān)控中心”在對(duì)異構(gòu)系統(tǒng)的數(shù)據(jù)進(jìn)行整合上面臨巨大挑戰(zhàn)。

ZooKeeper具有以下兩大特性。

(1)客戶端如果對(duì)ZooKeeper的一個(gè)數(shù)據(jù)節(jié)點(diǎn)注冊(cè)Watcher監(jiān)聽,那么當(dāng)該數(shù)據(jù)節(jié)點(diǎn)的內(nèi)容或是其子節(jié)點(diǎn)列表發(fā)生變更時(shí),ZooKeeper服務(wù)器就會(huì)向訂閱的客戶端發(fā)送變更通知。

(2)對(duì)在ZooKeeper上創(chuàng)建的臨時(shí)節(jié)點(diǎn),一旦客戶端與服務(wù)器之間的會(huì)話失效,那么該臨時(shí)節(jié)點(diǎn)也就被自動(dòng)清除。

利用ZooKeeper的這兩大特性,就可以實(shí)現(xiàn)另一種集群機(jī)器存活性監(jiān)控的系統(tǒng)。例如,監(jiān)控系統(tǒng)在/clusterServers節(jié)點(diǎn)上注冊(cè)一個(gè)Watcher監(jiān)聽,那么但凡進(jìn)行動(dòng)態(tài)添加機(jī)器的操作,就會(huì)在/clusterServers節(jié)點(diǎn)下創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn):/clusterervers/[Hostname]。這樣一來(lái),監(jiān)控系統(tǒng)就能夠?qū)崟r(shí)檢測(cè)到機(jī)器的變動(dòng)情況,至于后續(xù)處理就是監(jiān)控系統(tǒng)的業(yè)務(wù)了。下面我們就通過(guò)分布式日志收集系統(tǒng)和在線云主機(jī)管理這兩個(gè)典型例子來(lái)看看如何使用ZooKeeper實(shí)現(xiàn)集群管理。

分布式日志收集系統(tǒng)

分布式日志收集系統(tǒng)的核心工作就是收集分布在不同機(jī)器上的系統(tǒng)日志,在這里我們重點(diǎn)來(lái)看分布式日志系統(tǒng)(以下簡(jiǎn)稱“日志系統(tǒng)")的收集器模塊。

在一個(gè)典型的日志系統(tǒng)的架構(gòu)設(shè)計(jì)中,整個(gè)日志系統(tǒng)會(huì)把所有需要收集的日志機(jī)器(下文我們以“日志源機(jī)器”代表此類機(jī)器)分為多個(gè)組別,每個(gè)組別對(duì)應(yīng)一個(gè)收集器,這個(gè)收集器其實(shí)就是一個(gè)后臺(tái)機(jī)器(下文我們以“收集器機(jī)器”代表此類機(jī)器),用于收集日志。對(duì)于大規(guī)模的分布式日志收集系統(tǒng)場(chǎng)景,通常需要解決如下兩個(gè)問(wèn)題。

(1)變化的日志源機(jī)器

在生產(chǎn)環(huán)境中,伴隨著機(jī)器的變動(dòng),每個(gè)應(yīng)用的機(jī)器幾乎每天都是在變化的(機(jī)器硬件問(wèn)題、擴(kuò)容、機(jī)房遷移或是網(wǎng)絡(luò)問(wèn)題等都會(huì)導(dǎo)致一個(gè)應(yīng)用的機(jī)器變化),也就是說(shuō)每個(gè)組別中的日志源機(jī)器通常是在不斷變化的。

(2)變化的收集器機(jī)器

日志收集系統(tǒng)自身也會(huì)有機(jī)器的變更或擴(kuò)容,于是會(huì)出現(xiàn)新的收集器機(jī)器加入或是老的收集器機(jī)器退出的情況。

上面兩個(gè)問(wèn)題,無(wú)論是日志源機(jī)器還是收集器機(jī)器的變更,最終都?xì)w結(jié)為一點(diǎn):如何快速、合理、動(dòng)態(tài)地為每個(gè)收集器分配對(duì)應(yīng)的日志源機(jī)器,這也成為了整個(gè)日志系統(tǒng)正確穩(wěn)定運(yùn)轉(zhuǎn)的前提,也是日志收集過(guò)程中最大的技術(shù)挑戰(zhàn)之一。在這種情況下,引入ZooKeeper是個(gè)不錯(cuò)的選擇,下面我們就來(lái)看ZooKeeper在這個(gè)場(chǎng)景中的使用。

注冊(cè)收集器機(jī)器

使用ZooKeeper來(lái)進(jìn)行日志系統(tǒng)收集器的注冊(cè),典型做法是在ZooKeeper上創(chuàng)建一個(gè)節(jié)點(diǎn)作為收集器的根節(jié)點(diǎn),例如/logs/collector (下文我們以“收集器節(jié)點(diǎn)”代表該數(shù)據(jù)節(jié)點(diǎn)),每個(gè)收集器機(jī)器在啟動(dòng)的時(shí)候,都會(huì)在收集器節(jié)點(diǎn)下創(chuàng)建自己的節(jié)點(diǎn),例如/logs/collector/[Hostname],如下圖所示。

ZooKeeper的應(yīng)用場(chǎng)景(集群管理、Master選舉),微服務(wù),zookeeper,分布式,云原生

?

任務(wù)分發(fā)

待所有收集器機(jī)器都創(chuàng)建好自己對(duì)應(yīng)的節(jié)點(diǎn)后,系統(tǒng)根據(jù)收集器節(jié)點(diǎn)下子節(jié)點(diǎn)的個(gè)數(shù),將所有日志源機(jī)器分成對(duì)應(yīng)的若干組,然后將分組后的機(jī)器列表分別寫到這些收集器機(jī)器創(chuàng)建的子節(jié)點(diǎn)(例如/logs/collector/host1)上去。這樣一來(lái),每個(gè)收集器機(jī)器都能夠從自己對(duì)應(yīng)的收集器節(jié)點(diǎn)上獲取日志源機(jī)器列表,進(jìn)而開始進(jìn)行日志收集工作。

狀態(tài)匯報(bào)

完成收集器機(jī)器的注冊(cè)以及任務(wù)分發(fā)后,我們還要考慮到這些機(jī)器隨時(shí)都有掛掉的可能。因此,針對(duì)這個(gè)問(wèn)題,我們需要有一個(gè)收集器的狀態(tài)匯報(bào)機(jī)制:每個(gè)收集器機(jī)器在創(chuàng)建完自己的專屬節(jié)點(diǎn)后,還需要在對(duì)應(yīng)的子節(jié)點(diǎn)上創(chuàng)建一個(gè)狀態(tài)子節(jié)點(diǎn),例如/logs/collector/host1/status,每個(gè)收集器機(jī)器都需要定期向該節(jié)點(diǎn)寫入自己的狀態(tài)信息。我們可以把這種策略看作是一種心跳檢測(cè)機(jī)制,通常收集器機(jī)器都會(huì)在這個(gè)節(jié)點(diǎn)中寫入日志收集進(jìn)度信息。日志系統(tǒng)根據(jù)該狀態(tài)子節(jié)點(diǎn)的最后更新時(shí)間來(lái)判斷對(duì)應(yīng)的收集器機(jī)器是否存活。

動(dòng)態(tài)分配

如果收集器機(jī)器掛掉或是擴(kuò)容了,就需要?jiǎng)討B(tài)地進(jìn)行收集任務(wù)的分配。在運(yùn)行過(guò)程中,日志系統(tǒng)始終關(guān)注著/logs/collector這個(gè)節(jié)點(diǎn)下所有子節(jié)點(diǎn)的變更,一旦檢測(cè)到有收集器機(jī)器停止匯報(bào)或是有新的收集器機(jī)器加入,就要開始進(jìn)行任務(wù)的重新分配。無(wú)論是針對(duì)收集器機(jī)器停止匯報(bào)還是新機(jī)器加入的情況,日志系統(tǒng)都需要將之前分配給該收集器的所有任務(wù)進(jìn)行轉(zhuǎn)移。為了解決這個(gè)問(wèn)題,通常有兩種做法。

(1)全局動(dòng)態(tài)分配

這是一種簡(jiǎn)單粗暴的做法,在出現(xiàn)收集器機(jī)器掛掉或是新機(jī)器加入的時(shí)候,日志系統(tǒng)需要根據(jù)新的收集器機(jī)器列表,立即對(duì)所有的日志源機(jī)器重新進(jìn)行一次分組,然后將其分配給剩下的收集器機(jī)器。

(2)局部動(dòng)態(tài)分配

全局動(dòng)態(tài)分配方式雖然策略簡(jiǎn)單,但是存在一個(gè)問(wèn)題:一個(gè)或部分收集器機(jī)器的變更,就會(huì)導(dǎo)致全局動(dòng)態(tài)任務(wù)的分配,影響面比較大,因此風(fēng)險(xiǎn)也就比較大。所謂局部動(dòng)態(tài)分配,顧名思義就是在小范圍內(nèi)進(jìn)行任務(wù)的動(dòng)態(tài)分配。在這種策略中,每個(gè)收集器機(jī)器在匯報(bào)自己日志收集狀態(tài)的同時(shí),也會(huì)把自己的負(fù)載匯報(bào)上去。請(qǐng)注意,這里提到的負(fù)載并不僅僅只是簡(jiǎn)單地指機(jī)器CPU負(fù)載(Load),而是一個(gè)對(duì)當(dāng)前收集器任務(wù)執(zhí)行的綜合評(píng)估,這個(gè)評(píng)估算法和ZooKeeper本身并沒(méi)有太大的關(guān)系,這里不再贅述。

在這種策略中,如果一個(gè)收集器機(jī)器掛了,那么日志系統(tǒng)就會(huì)把之前分配給這個(gè)機(jī)器的任務(wù)重新分配到那些負(fù)載較低的機(jī)器上去。同樣,如果有新的收集器機(jī)器加入,會(huì)從那些負(fù)載高的機(jī)器上轉(zhuǎn)移部分任務(wù)給這個(gè)新加入的機(jī)器。

注意事項(xiàng)

在上面的介紹中,我們已經(jīng)了解了ZooKeeper是如何協(xié)調(diào)一個(gè)分布式日志收集系統(tǒng)工作的,接下來(lái)再來(lái)看看一些細(xì)節(jié)問(wèn)題。

(1)節(jié)點(diǎn)類型

我們首先來(lái)看/logs/collector這個(gè)節(jié)點(diǎn)下面子節(jié)點(diǎn)的節(jié)點(diǎn)類型。在上面已經(jīng)提到,/logs/collector節(jié)點(diǎn)下面的所有子節(jié)點(diǎn)都代表了每個(gè)收集器機(jī)器,那么初步認(rèn)為這些子節(jié)點(diǎn)必須選擇臨時(shí)節(jié)點(diǎn),原因是日志系統(tǒng)可以根據(jù)這些臨時(shí)節(jié)點(diǎn)來(lái)判斷收集器機(jī)器的存活性。但是,同時(shí)還需要注意的一點(diǎn)是:在分布式日志收集這個(gè)場(chǎng)景中,收集器節(jié)點(diǎn)上還會(huì)存放所有已經(jīng)分配給該收集器機(jī)器的日志源機(jī)器列表,如果只是簡(jiǎn)單地依靠ZooKeeper自身的臨時(shí)節(jié)點(diǎn)機(jī)制,那么當(dāng)一個(gè)收集器機(jī)器掛掉或是當(dāng)這個(gè)收集器機(jī)器中斷“心跳匯報(bào)”的時(shí)候,待該收集器節(jié)點(diǎn)的會(huì)話失效后,ZooKeeper就會(huì)立即刪除該節(jié)點(diǎn),于是,記錄在該節(jié)點(diǎn)上的所有日志源機(jī)器列表也就隨之被清除掉了。

從上面的描述中可以知道,臨時(shí)節(jié)點(diǎn)顯然無(wú)法滿足這里的業(yè)務(wù)需求,所以我們選擇了使用持久節(jié)點(diǎn)來(lái)標(biāo)識(shí)每一個(gè)收集器機(jī)器,同時(shí)在這個(gè)持久節(jié)點(diǎn)下面分別創(chuàng)建/logs/collector/[Hostname]/status節(jié)點(diǎn)來(lái)表征每一個(gè)收集器機(jī)器的狀態(tài)。這樣一來(lái),既能實(shí)現(xiàn)日志系統(tǒng)對(duì)所有收集器的監(jiān)控,同時(shí)在收集器機(jī)器掛掉后,依然能夠準(zhǔn)確地將分配于其中的任務(wù)還原。

(2)日志系統(tǒng)節(jié)點(diǎn)監(jiān)聽

在實(shí)際生產(chǎn)運(yùn)行過(guò)程中,每一個(gè)收集器機(jī)器更改自己狀態(tài)節(jié)點(diǎn)的頻率可能非常高(如每秒1次或更短),而且收集器的數(shù)量可能非常大,如果日志系統(tǒng)監(jiān)聽所有這些節(jié)點(diǎn)變化,那么通知的消息量可能會(huì)非常大。另一方面,在收集器機(jī)器正常工作的情況下,日志系統(tǒng)沒(méi)有必要去實(shí)時(shí)地接收每次節(jié)點(diǎn)狀態(tài)變更,因此大部分這些狀態(tài)變更通知都是無(wú)用的。因此我們考慮放棄監(jiān)聽設(shè)置,而是采用日志系統(tǒng)主動(dòng)輪詢收集器節(jié)點(diǎn)的策略,這樣就節(jié)省了不少網(wǎng)卡流量,唯一的缺陷就是有一定的延時(shí)(考慮到分布式日志收集系統(tǒng)的定位,這個(gè)延時(shí)是可以接受的)。

在線云主機(jī)管理

在線云主機(jī)管理通常出現(xiàn)在那些虛擬主機(jī)提供商的應(yīng)用場(chǎng)景中。在這類集群管理中,有很重要的一塊就是集群機(jī)器的監(jiān)控。這個(gè)場(chǎng)景通常對(duì)于集群中的機(jī)器狀態(tài),尤其是機(jī)器在線率的統(tǒng)計(jì)有較高的要求,同時(shí)需要能夠快速地對(duì)集群中機(jī)器的變更做出響應(yīng)。

在傳統(tǒng)的實(shí)現(xiàn)方案中,監(jiān)控系統(tǒng)通過(guò)某種手段(比如檢測(cè)主機(jī)的指定端口)來(lái)對(duì)每臺(tái)機(jī)器進(jìn)行定時(shí)檢測(cè),或者每臺(tái)機(jī)器自己定時(shí)向監(jiān)控系統(tǒng)匯報(bào)“我還活著”。但是這種方式需要每一個(gè)業(yè)務(wù)系統(tǒng)的開發(fā)人員自己來(lái)處理網(wǎng)絡(luò)通信、協(xié)議設(shè)計(jì)、調(diào)度和容災(zāi)等諸多瑣碎的問(wèn)題。下面來(lái)看看使用ZooKeeper實(shí)現(xiàn)的另一種集群機(jī)器存活性監(jiān)控系統(tǒng)。針對(duì)這個(gè)系統(tǒng),我們的需求點(diǎn)通常如下。

如何快速地統(tǒng)計(jì)出當(dāng)前生產(chǎn)環(huán)境一共有多少臺(tái)機(jī)器?

如何快速地獲取到機(jī)器上/下線的情況?

如何實(shí)時(shí)監(jiān)控集群中每臺(tái)主機(jī)的運(yùn)行時(shí)狀態(tài)?

機(jī)器上/下線

為了實(shí)現(xiàn)自動(dòng)化的線上運(yùn)維,我們必須對(duì)機(jī)器的上/下線情況有一個(gè)全局的監(jiān)控。通常在新增機(jī)器的時(shí)候,需要首先將指定的Agent部署到這些機(jī)器上去。Agent部署啟動(dòng)之后,會(huì)首先向ZooKeeper的指定節(jié)點(diǎn)進(jìn)行注冊(cè),具體的做法就是在機(jī)器列表節(jié)點(diǎn)下面創(chuàng)建一個(gè)臨時(shí)子節(jié)點(diǎn),例如/XAE/machine/[Hostname](下文我們以“主機(jī)節(jié)點(diǎn)”代表這個(gè)節(jié)點(diǎn)),如下圖所示。

ZooKeeper的應(yīng)用場(chǎng)景(集群管理、Master選舉),微服務(wù),zookeeper,分布式,云原生

?

當(dāng)Agent在ZooKeeper上創(chuàng)建完這個(gè)臨時(shí)子節(jié)點(diǎn)后,對(duì)/XAE/machines節(jié)點(diǎn)關(guān)注的監(jiān)控中心就會(huì)接收到“子節(jié)點(diǎn)變更”事件,即上線通知,于是就可以對(duì)這個(gè)新加入的機(jī)器開啟相應(yīng)的后臺(tái)管理邏輯。另一方面,監(jiān)控中心同樣可以獲取到機(jī)器下線的通知,這樣便實(shí)現(xiàn)了對(duì)機(jī)器上/下線的檢測(cè),同時(shí)能夠很容易地獲取到在線的機(jī)器列表,對(duì)于大規(guī)模的擴(kuò)容和容量評(píng)估都有很大的幫助。

機(jī)器監(jiān)控

對(duì)于一個(gè)在線云主機(jī)系統(tǒng),不僅要對(duì)機(jī)器的在線狀態(tài)進(jìn)行檢測(cè),還需要對(duì)機(jī)器的運(yùn)行時(shí)狀態(tài)進(jìn)行監(jiān)控。在運(yùn)行的過(guò)程中,Agent 會(huì)定時(shí)將主機(jī)的運(yùn)行狀態(tài)信息寫入ZooKeeper上的主機(jī)節(jié)點(diǎn),監(jiān)控中心通過(guò)訂閱這些節(jié)點(diǎn)的數(shù)據(jù)變更通知來(lái)間接地獲取主機(jī)的運(yùn)行時(shí)信息。

隨著分布式系統(tǒng)規(guī)模變得越來(lái)越龐大,對(duì)集群機(jī)器的監(jiān)控和管理顯得越來(lái)越重要。上面提到的這種借助ZooKeeper來(lái)實(shí)現(xiàn)的方式,不僅能夠?qū)崟r(shí)地檢測(cè)到集群中機(jī)器的上/下線情況,而且能夠?qū)崟r(shí)地獲取到主機(jī)的運(yùn)行時(shí)信息,從而能夠構(gòu)建出一個(gè)大規(guī)模集群的主機(jī)圖譜。

6 Master選舉

Master選舉是一個(gè)在分布式系統(tǒng)中非常常見的應(yīng)用場(chǎng)景。分布式最核心的特性就是能夠?qū)⒕哂歇?dú)立計(jì)算能力的系統(tǒng)單元部署在不同的機(jī)器上,構(gòu)成一個(gè)完整的分布式系統(tǒng)。而與此同時(shí),實(shí)際場(chǎng)景中往往也需要在這些分布在不同機(jī)器上的獨(dú)立系統(tǒng)單元中選出一個(gè)所謂的“老大”,在計(jì)算機(jī)科學(xué)中,我們稱之為Master。

在分布式系統(tǒng)中,Master往往用來(lái)協(xié)調(diào)集群中其他系統(tǒng)單元,具有對(duì)分布式系統(tǒng)狀態(tài)變更的決定權(quán)。例如,在一些讀寫分離的應(yīng)用場(chǎng)景中,客戶端的寫請(qǐng)求往往是由Master來(lái)處理的;而在另一些場(chǎng)景中,Master則常常負(fù)責(zé)處理--些復(fù)雜的邏輯,并將處理結(jié)果同步給集群中其他系統(tǒng)單元。Master選舉可以說(shuō)是ZooKeeper最典型的應(yīng)用場(chǎng)景了,在本文中,我們就結(jié)合“一種海量數(shù)據(jù)處理與共享模型”這個(gè)具體例子來(lái)看看ZooKeeper在集群Master選舉中的應(yīng)用場(chǎng)景。

在分布式環(huán)境中,經(jīng)常會(huì)碰到這樣的應(yīng)用場(chǎng)景:集群中的所有系統(tǒng)單元需要對(duì)前端業(yè)務(wù)提供數(shù)據(jù),比如一個(gè)商品ID,或者是一個(gè)網(wǎng)站輪播廣告的廣告ID (通常出現(xiàn)在一些廣告投放系統(tǒng)中)等,而這些商品ID或是廣告ID往往需要從一系列的海量數(shù)據(jù)處理中計(jì)算得到一這通常是一個(gè)非常耗費(fèi) I/O和CPU資源的過(guò)程。鑒于該計(jì)算過(guò)程的復(fù)雜性,如果讓集群中的所有機(jī)器都執(zhí)行這個(gè)計(jì)算邏輯的話,那么將耗費(fèi)非常多的資源。一種比較好的方法就是只讓集群中的部分,甚至只讓其中的一臺(tái)機(jī)器去處理數(shù)據(jù)計(jì)算,一旦計(jì)算出數(shù)據(jù)結(jié)果,就可以共享給整個(gè)集群中的其他所有客戶端機(jī)器,這樣可以大大減少重復(fù)勞動(dòng),提升性能。

這里我們以一個(gè)簡(jiǎn)單的廣告投放系統(tǒng)后臺(tái)場(chǎng)景為例來(lái)講解這個(gè)模型。整個(gè)系統(tǒng)大體上可以分成客戶端集群、分布式緩存系統(tǒng)、海量數(shù)據(jù)處理總線和ZooKeeper四個(gè)部分,如下圖所示。

ZooKeeper的應(yīng)用場(chǎng)景(集群管理、Master選舉),微服務(wù),zookeeper,分布式,云原生

首先我們來(lái)看整個(gè)系統(tǒng)的運(yùn)行機(jī)制。上圖中的Client集群每天定時(shí)會(huì)通過(guò)ZooKeeper來(lái)實(shí)現(xiàn)Master選舉。選舉產(chǎn)生Master客戶端之后,這個(gè)Master就會(huì)負(fù)責(zé)進(jìn)行一系列的海量數(shù)據(jù)處理,最終計(jì)算得到一個(gè)數(shù)據(jù)結(jié)果,并將其放置在一個(gè)內(nèi)存/數(shù)據(jù)庫(kù)中。同時(shí),Master還需要通知集群中其他所有的客戶端從這個(gè)內(nèi)存/數(shù)據(jù)庫(kù)中共享計(jì)算結(jié)果。

接下去,我們將重點(diǎn)來(lái)看Master選舉的過(guò)程,首先來(lái)明確下Master選舉的需求:在集群的所有機(jī)器中選舉出一臺(tái)機(jī)器作為Master。針對(duì)這個(gè)需求,通常情況下,我們可以選擇常見的關(guān)系型數(shù)據(jù)庫(kù)中的主鍵特性來(lái)實(shí)現(xiàn):集群中的所有機(jī)器都向數(shù)據(jù)庫(kù)中插入一條相同主鍵ID的記錄,數(shù)據(jù)庫(kù)會(huì)幫助我們自動(dòng)進(jìn)行主鍵沖突檢查,也就是說(shuō),所有進(jìn)行插入操作的客戶端機(jī)器中,只有一臺(tái)機(jī)器能夠成功——那么我們就認(rèn)為向數(shù)據(jù)庫(kù)中成功插入數(shù)據(jù)的客戶端機(jī)器成為Master。

乍一看,這個(gè)方案確實(shí)可行,依靠關(guān)系型數(shù)據(jù)庫(kù)的主鍵特性能夠很好地保證在集群中選舉出唯一的一個(gè)Master。但是我們需要考慮的另一個(gè)問(wèn)題是,如果當(dāng)前選舉出的Master掛了,那么該如何處理?誰(shuí)來(lái)告訴我Master掛了呢?顯然,關(guān)系型數(shù)據(jù)庫(kù)沒(méi)法通知我們這個(gè)事件。那么,如果使用ZooKeeper是否可以做到這一點(diǎn)呢?

ZooKeeper創(chuàng)建節(jié)點(diǎn)的API接口其中提到的一個(gè)重要特性便是:利用ZooKeeper的強(qiáng)一致性,能夠很好地保證在分布式高并發(fā)情況下節(jié)點(diǎn)的創(chuàng)建一定能夠保證全局唯一性,即ZooKeeper將會(huì)保證客戶端無(wú)法重復(fù)創(chuàng)建一個(gè)已經(jīng)存在的數(shù)據(jù)節(jié)點(diǎn)。也就是說(shuō),如果同時(shí)有多個(gè)客戶端請(qǐng)求創(chuàng)建同一個(gè)節(jié)點(diǎn),那么最終一定只有一個(gè)客戶端請(qǐng)求能夠創(chuàng)建成功。利用這個(gè)特性,就能很容易地在分布式環(huán)境中進(jìn)行Master選舉了。

在這個(gè)系統(tǒng)中,首先會(huì)在ZooKeeper上創(chuàng)建一個(gè)日期節(jié)點(diǎn),例如“2013-09-20”, 如下圖所示。

ZooKeeper的應(yīng)用場(chǎng)景(集群管理、Master選舉),微服務(wù),zookeeper,分布式,云原生

客戶端集群每天都會(huì)定時(shí)往ZooKeeper上創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn),例如/master_ election/2013-09- 20/binding。在這個(gè)過(guò)程中,只有一個(gè)客戶端能夠成功創(chuàng)建這個(gè)節(jié)點(diǎn),那么這個(gè)客戶端所在的機(jī)器就成為了Master。同時(shí),其他沒(méi)有在ZooKeeper上成功創(chuàng)建節(jié)點(diǎn)的客戶端,都會(huì)在節(jié)點(diǎn)/master_election/2013-09-20上注冊(cè)一個(gè)子節(jié)點(diǎn)變更的Watcher,用于監(jiān)控當(dāng)前的Master機(jī)器是否存活,一旦發(fā)現(xiàn)當(dāng)前的Master掛了,那么其余的客戶端將會(huì)重新進(jìn)行Master選舉。

從上面的講解中,我們可以看到,如果僅僅只是想實(shí)現(xiàn)Master選舉的話,那么其實(shí)只需要有一個(gè)能夠保證數(shù)據(jù)唯一性的組件即可,例如關(guān)系型數(shù)據(jù)庫(kù)的主鍵模型就是非常不錯(cuò)的選擇。但是,如果希望能夠快速地進(jìn)行集群Master動(dòng)態(tài)選舉,那么基于ZooKeeper來(lái)實(shí)現(xiàn)是一個(gè)不錯(cuò)的新思路。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-652376.html

到了這里,關(guān)于ZooKeeper的應(yīng)用場(chǎng)景(集群管理、Master選舉)的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!

本文來(lái)自互聯(lián)網(wǎng)用戶投稿,該文觀點(diǎn)僅代表作者本人,不代表本站立場(chǎng)。本站僅提供信息存儲(chǔ)空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如若轉(zhuǎn)載,請(qǐng)注明出處: 如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實(shí)不符,請(qǐng)點(diǎn)擊違法舉報(bào)進(jìn)行投訴反饋,一經(jīng)查實(shí),立即刪除!

領(lǐng)支付寶紅包贊助服務(wù)器費(fèi)用

相關(guān)文章

  • 【ZooKeeper】ZooKeeper 應(yīng)用場(chǎng)景

    【ZooKeeper】ZooKeeper 應(yīng)用場(chǎng)景

    ZooKeeper:分布式協(xié)調(diào)服務(wù),仲裁機(jī)構(gòu)。基于ZNode數(shù)據(jù)模型和Watcher監(jiān)聽機(jī)制可以解決很多問(wèn)題,比如分布式鎖問(wèn)題。 應(yīng)用場(chǎng)景如下: 1、發(fā)布/訂閱 2、命名服務(wù) 3、配置管理 4、集群管理 5、分布式鎖 6、隊(duì)列管理 7、負(fù)載均衡 應(yīng)用服務(wù)器集群可能存在兩個(gè)問(wèn)題: 1、集群中有很多

    2024年02月04日
    瀏覽(29)
  • 【zookeeper】ZooKeeper的特點(diǎn)及應(yīng)用場(chǎng)景

    【zookeeper】ZooKeeper的特點(diǎn)及應(yīng)用場(chǎng)景

    ZooKeeper(動(dòng)物園管理員) ,顧名思義,是用來(lái)管理Hadoop(大象)、Hive(蜜蜂)、Pig(小豬)的管理員,同時(shí)Apache HBase、Apache Solr等眾多項(xiàng)目中都采用了ZooKeeper。作為一個(gè)集群提供數(shù)據(jù)一致的分布式協(xié)調(diào)服務(wù),它最好的方式就是在整個(gè)集群中的各服務(wù)節(jié)點(diǎn)進(jìn)行數(shù)據(jù)的復(fù)制和同步

    2024年02月09日
    瀏覽(15)
  • 【Zookeeper專題】Zookeeper經(jīng)典應(yīng)用場(chǎng)景實(shí)戰(zhàn)(一)

    【Zookeeper專題】Zookeeper經(jīng)典應(yīng)用場(chǎng)景實(shí)戰(zhàn)(一)

    在學(xué)習(xí)本節(jié)課之前,至少需要掌握Z(yǔ)ookeeper的節(jié)點(diǎn)特性,以及基本操作。 《【Zookeeper專題】Zookeeper特性與節(jié)點(diǎn)數(shù)據(jù)類型詳解》 Zookeeper的客戶端有很多,這邊主要介紹的是兩種: Zookeeper官方的Java客戶端API 第三方的Java客戶端API,Curator ZooKeeper官方的客戶端API提供了基本的操作,

    2024年02月08日
    瀏覽(16)
  • Zookeeper的應(yīng)用場(chǎng)景

    Zookeeper的應(yīng)用場(chǎng)景

    配置中心:Zookeeper可以用來(lái)存儲(chǔ)和管理配置信息,例如集群中的機(jī)器配置、服務(wù)地址配置等。通過(guò)Zookeeper,可以將配置信息統(tǒng)一管理,同時(shí)實(shí)現(xiàn)動(dòng)態(tài)加載和更新。 統(tǒng)一命名服務(wù):Zookeeper可以用來(lái)實(shí)現(xiàn)命名服務(wù),例如將集群中的機(jī)器名稱和IP地址進(jìn)行映射,或者將服務(wù)的唯一標(biāo)

    2024年02月15日
    瀏覽(19)
  • ZooKeeper 應(yīng)用場(chǎng)景深度解析

    目錄 引言 1. 分布式配置管理 2. 分布式鎖 3. 分布式隊(duì)列 4. 分布式協(xié)調(diào) 5. 分布式協(xié)同 6、數(shù)據(jù)發(fā)布與訂閱 7、命名服務(wù) 8、集群管理 結(jié)論 ZooKeeper 是一個(gè)分布式協(xié)調(diào)服務(wù),被廣泛應(yīng)用于構(gòu)建高可用、可靠性強(qiáng)的分布式系統(tǒng)。它提供了一組簡(jiǎn)單而強(qiáng)大的原語(yǔ),用于解決分布式系統(tǒng)

    2024年01月17日
    瀏覽(26)
  • Zookeeper六大應(yīng)用場(chǎng)景詳解

    Zookeeper六大應(yīng)用場(chǎng)景詳解

    ZooKeeper是?個(gè)典型的發(fā)布/訂閱模式的分布式數(shù)據(jù)管理與協(xié)調(diào)框架,我們可以使用它來(lái)進(jìn)行分布式數(shù)據(jù)的發(fā)布與訂閱。另?方面,通過(guò)對(duì)ZooKeeper中豐富的數(shù)據(jù)節(jié)點(diǎn)類型進(jìn)行交叉使用,配合Watcher 事件通知機(jī)制,可以非常方便地構(gòu)建?系列分布式應(yīng)用中都會(huì)涉及的核心功能,如數(shù)

    2024年02月07日
    瀏覽(20)
  • zookeeper應(yīng)用場(chǎng)景(二)

    zookeeper應(yīng)用場(chǎng)景(二)

    單機(jī)環(huán)境下可以利用jvm級(jí)別的鎖,比如synchronized、Lock等來(lái)實(shí)現(xiàn)鎖,如果是多機(jī)部署就需要一個(gè)共享數(shù)據(jù)存儲(chǔ)區(qū)域來(lái)實(shí)現(xiàn)分布式鎖 1、基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式鎖 可以用數(shù)據(jù)庫(kù)唯一索引來(lái)實(shí)現(xiàn) 2、基于redis實(shí)現(xiàn)分布式鎖 redis實(shí)現(xiàn)的分布式鎖始終會(huì)有一些問(wèn)題,即便使用多數(shù)寫入,

    2024年02月07日
    瀏覽(26)
  • Zookeeper選舉機(jī)制(通俗易懂)

    SID: 服務(wù)器ID。用來(lái)唯一標(biāo)識(shí)一臺(tái)ZooKeeper集群中的機(jī)器,每臺(tái)機(jī)器不能重復(fù),和myid一致。 ZXID: 事務(wù)ID。ZXID是一個(gè)事務(wù)ID,用來(lái)標(biāo)識(shí)一次服務(wù)器狀態(tài)的變更。在某一時(shí)刻,集群中的每臺(tái)機(jī)器的ZXID值不一定完全一致,這和 ZooKeeper服務(wù)器對(duì)于客戶端“更新請(qǐng)求”的處理邏輯有關(guān)

    2024年01月22日
    瀏覽(24)
  • zookeeper選舉流程源碼分析

    zookeeper選舉流程源碼分析 選舉的代碼主要是在 QuorumPeer.java 這個(gè)類中。 它有一個(gè)內(nèi)部枚舉類,用來(lái)表示當(dāng)前節(jié)點(diǎn)的狀態(tài)。 LOOKING: 當(dāng)前節(jié)點(diǎn)在選舉過(guò)程中 FOLLOWING:當(dāng)前節(jié)點(diǎn)是從節(jié)點(diǎn) LEADING: 當(dāng)前節(jié)點(diǎn)是主節(jié)點(diǎn) OBSERVING: 當(dāng)前節(jié)點(diǎn)是觀察者狀態(tài),這種狀態(tài)的節(jié)點(diǎn)不參與選舉的投

    2024年02月11日
    瀏覽(21)
  • Zookeeper的選舉機(jī)制

    是一個(gè)分布式的系統(tǒng),多個(gè)節(jié)點(diǎn) 并且節(jié)點(diǎn)中記錄的數(shù)據(jù)是完全一致(一致性) , 當(dāng)某個(gè)zk的節(jié)點(diǎn)宕機(jī)之后不會(huì)影響工作。因?yàn)閆ookeeper的主節(jié)點(diǎn)不存在單點(diǎn)故障!Zookeeper的主節(jié)點(diǎn)是可以動(dòng)態(tài)選舉出來(lái)的! zookeeper的進(jìn)程在不同的工作模式下,有不同的通信端口(比如選舉時(shí),通過(guò)端口

    2024年02月16日
    瀏覽(19)

覺得文章有用就打賞一下文章作者

支付寶掃一掃打賞

博客贊助

微信掃一掃打賞

請(qǐng)作者喝杯咖啡吧~博客贊助

支付寶掃一掃領(lǐng)取紅包,優(yōu)惠每天領(lǐng)

二維碼1

領(lǐng)取紅包

二維碼2

領(lǐng)紅包