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]，如下圖所示。

?

任務(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))，如下圖所示。

?

當(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è)部分，如下圖所示。

首先我們來(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”， 如下圖所示。

客戶端集群每天都會(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)！