5 集群管理

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

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

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

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

(3)對集群中機器進行上下線操作。

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

大規(guī)模升級困難

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

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

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

編程語言多樣性

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

ZooKeeper具有以下兩大特性。

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

(2)對在ZooKeeper上創(chuàng)建的臨時節(jié)點，一旦客戶端與服務器之間的會話失效，那么該臨時節(jié)點也就被自動清除。

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

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

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

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

(1)變化的日志源機器

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

(2)變化的收集器機器

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

上面兩個問題，無論是日志源機器還是收集器機器的變更，最終都歸結為一點：如何快速、合理、動態(tài)地為每個收集器分配對應的日志源機器，這也成為了整個日志系統(tǒng)正確穩(wěn)定運轉(zhuǎn)的前提，也是日志收集過程中最大的技術挑戰(zhàn)之一。在這種情況下，引入ZooKeeper是個不錯的選擇，下面我們就來看ZooKeeper在這個場景中的使用。

注冊收集器機器

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

?

任務分發(fā)

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

狀態(tài)匯報

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

動態(tài)分配

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

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

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

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

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

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

注意事項

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

(1)節(jié)點類型

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

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

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

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

在線云主機管理

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

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

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

如何快速地獲取到機器上/下線的情況？

如何實時監(jiān)控集群中每臺主機的運行時狀態(tài)？

機器上/下線

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

?

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

機器監(jiān)控

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

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

6 Master選舉

Master選舉是一個在分布式系統(tǒng)中非常常見的應用場景。分布式最核心的特性就是能夠?qū)⒕哂歇毩⒂嬎隳芰Φ南到y(tǒng)單元部署在不同的機器上，構成一個完整的分布式系統(tǒng)。而與此同時，實際場景中往往也需要在這些分布在不同機器上的獨立系統(tǒng)單元中選出一個所謂的“老大”，在計算機科學中，我們稱之為Master。

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

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

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

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

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

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

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

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

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

從上面的講解中，我們可以看到，如果僅僅只是想實現(xiàn)Master選舉的話，那么其實只需要有一個能夠保證數(shù)據(jù)唯一性的組件即可，例如關系型數(shù)據(jù)庫的主鍵模型就是非常不錯的選擇。但是，如果希望能夠快速地進行集群Master動態(tài)選舉，那么基于ZooKeeper來實現(xiàn)是一個不錯的新思路。