劉皓

摘要：隨著互聯(lián)網(wǎng)技術(shù)的日益普及，分布式計算模型在企業(yè)中的應(yīng)用越發(fā)顯得重要。以往在要求高性能、高可用性環(huán)境下進(jìn)行業(yè)務(wù)復(fù)雜計算往往注重于單臺高價計算機(jī)的運(yùn)算性能和可靠性，目前在分布式計算模型趨于成熟之后已經(jīng)逐步轉(zhuǎn)向采用多臺廉價計算機(jī)協(xié)同計算來達(dá)到相同的目的，對企業(yè)應(yīng)用架構(gòu)而言，這不但大大降低了企業(yè)采用高性能計算的成本，也在業(yè)務(wù)可擴(kuò)展性上提供了敏捷的渠道。在眾多的分布式環(huán)境下的計算通信模型中，JGroups作為一個可靠的組播通信工具提供了一個非常優(yōu)秀的輕量級分布式計算模型及實(shí)現(xiàn)。本文試圖從分布式計算需要解決的幾個重要問題出發(fā)，詳細(xì)剖析JGroups框架在分布式計算的可靠性和通信協(xié)議上所提供的完整解決方案。

關(guān)鍵詞：分布式計算；JGroups技術(shù)；組播；通信協(xié)議；高可用；集群

中圖分類號：TP391.41

文獻(xiàn)標(biāo)識碼：A

DOI：10.3969/j.issn.1003-6970.2015.09.029

0 引言

JGroups最初是由Bela Ban于1998年到1999年間在美國康奈爾大學(xué)攻讀博士后學(xué)位時期著手開發(fā)的一款解決分布式環(huán)境下的計算機(jī)之間通訊的軟件。2000年5月，SourceForge成立之后，Bela Ban看到了開源的力量，并決定將JGroups的源代碼共享給互聯(lián)網(wǎng)上其他有共同興趣的愛好者。隨著更多的開源軟件愛好者的加入，JGroups迅速壯大起來。2003年，在JBOSS的創(chuàng)始人Sacha Labourey的邀請下，JGroups加入到JBoss的隊(duì)伍中并成為之后JBoss Cache框架的核心通訊組件。2006年5月，著名的Linux操作系統(tǒng)產(chǎn)商Red Hat宣布收購JBoss，JGroups也隨之成為了目前世界上主流開源軟件服務(wù)提供商的核心軟件框架之一。到目前為止，JGroups提供的分布式計算模型和通信協(xié)議通過軟件開源過程的不斷錘煉已經(jīng)逐步成熟，事實(shí)上已經(jīng)成為小規(guī)模計算機(jī)集群底層狀態(tài)復(fù)制的行業(yè)標(biāo)準(zhǔn)。

1 分布式計算模型

JGroups是由java編寫的一個可靠的組播/多播通訊工具包，它不但支持可靠的組播通訊，也支持采用TCP協(xié)議來進(jìn)行消息傳遞。其工作模式基于IP多播，可以在可靠性和群組成員管理上進(jìn)行擴(kuò)展。其基本思想是在計算機(jī)網(wǎng)絡(luò)環(huán)境下，通過配置通信協(xié)議將多臺計算機(jī)進(jìn)行分組，在計算機(jī)分組中通過多套協(xié)議來保證可靠的消息通信和分組中每個成員異常狀態(tài)監(jiān)測，在此基礎(chǔ)上可以為應(yīng)用程序提供完整的分布式環(huán)境下的業(yè)務(wù)狀態(tài)同步、任務(wù)分配和計算結(jié)果的收集。

從設(shè)計上來看，它提供了一種靈活兼容多種協(xié)議的協(xié)議棧。協(xié)議?？梢韵嗷ソM合使用，用來適應(yīng)不同產(chǎn)品的可靠性需求。這種協(xié)議?？梢宰層脩舾鶕?jù)自己的應(yīng)用的需求進(jìn)行調(diào)整，主要是根據(jù)特定的網(wǎng)絡(luò)環(huán)境下需要同步的數(shù)據(jù)量大小、計算節(jié)點(diǎn)集群的規(guī)模以及需要同步的頻率定制適合自己的協(xié)議棧。

從應(yīng)用上來看，它提供了分布式環(huán)境下有效的同步機(jī)制，提供了在集群計算節(jié)點(diǎn)之間通信統(tǒng)一的API，包含了從點(diǎn)到點(diǎn)以及由單個計算節(jié)點(diǎn)到全組的通信接口，可以很方便的保持各個計算節(jié)點(diǎn)狀態(tài)一致性。

1.1 可靠的消息傳輸

在分布式計算環(huán)境中，保證計算節(jié)點(diǎn)之間數(shù)據(jù)通信的可靠性是計算機(jī)集群需要考察的一個最基本的能力。目前最通用的網(wǎng)絡(luò)通信協(xié)議主要是TCP協(xié)議和UDP協(xié)議。在多臺計算機(jī)協(xié)同工作的環(huán)境中，采用TCP協(xié)議可以很方便的達(dá)到消息可靠傳輸?shù)哪康?，但是TCP協(xié)議要求計算機(jī)在網(wǎng)絡(luò)中創(chuàng)建點(diǎn)到點(diǎn)之間有狀態(tài)的SOCKET資源，如果需要將同一條消息發(fā)送給集群中的每一個節(jié)點(diǎn)，采用TCP協(xié)議將比采用UDP協(xié)議需要更多的網(wǎng)絡(luò)流量，這在大規(guī)模的網(wǎng)絡(luò)實(shí)時通信中對應(yīng)用程序而言是一筆不小的開。UDP協(xié)議對網(wǎng)絡(luò)資源的消耗代價很低，但UDP協(xié)議本身并不能保證通信過程中消息可以可靠的從消息發(fā)送者傳遞到消息接收者手中，所以如果要在集群環(huán)境中使用UDP協(xié)議達(dá)到可靠的消息傳輸?shù)哪康?，需要在UDP協(xié)議之上增加新的協(xié)議進(jìn)行控制。

在集群環(huán)境下使用UDP協(xié)議進(jìn)行通信可以有效的降低集群網(wǎng)絡(luò)環(huán)境的數(shù)據(jù)傳輸壓力，JGroups通過UNICAST協(xié)議來保證消息的可靠傳輸，UNICAST協(xié)議在UDP的基礎(chǔ)上增加了消息響應(yīng)的步驟，以保證傳輸過程的完整性。原始的UDP協(xié)議不要求消息的接收者反饋給消息的發(fā)送者是否已經(jīng)成功接收到消息，UNICAST在此基礎(chǔ)上完善了消息反饋的過程。消息的反饋方式分為ACK和NAKACK兩種：

ACK：消息的發(fā)送者不斷的重復(fù)發(fā)送消息，直到所有的接收者都返回了確認(rèn)消息已經(jīng)收到，

NAKACK：消息的接收者不斷請求消息發(fā)送者發(fā)送消息，直到消息的接收者確認(rèn)所有收到的消息是完整的。

UNICAST協(xié)議需要保證消息的傳輸過程是可靠的，它依賴于一個不斷發(fā)送消息的時間周期來進(jìn)行循環(huán)，因此UNICAST的一項(xiàng)重要的配置屬性timeout就來源于此：如果timeout值被設(shè)置為100，200，400，800，就表示如果消息發(fā)送者在等待100毫秒還沒有接收到消息接收者的ACK消息，則消息發(fā)送者重新發(fā)送消息（第一次重發(fā)），消息發(fā)送者繼續(xù)等待200毫秒仍然沒有接收到ACK消息，則消息發(fā)送者再次重新發(fā)送消息（第二次重發(fā)），這樣直到等待800毫秒進(jìn)行第四次重發(fā)。在多播環(huán)境下，NAKACK協(xié)議基于ACK協(xié)議進(jìn)行了擴(kuò)展，在這種協(xié)議下，每個消息綁定一個序列號，消息接收者根據(jù)序列號確保消息按正確的順序傳遞。如果接收者發(fā)現(xiàn)了一個序列號的缺失，接收者安排一個周期性的任務(wù)去要求發(fā)送者重新發(fā)送該序列號的消息，當(dāng)缺失的序列號的消息收到，則請求數(shù)據(jù)同步的任務(wù)取消，并向消息的發(fā)送者提供消息完全抵達(dá)確認(rèn)反饋。

1.2 分布式垃圾回收

由于UNICAST協(xié)議通過循環(huán)通信過程消息反復(fù)比對來保證消息傳輸?shù)目煽啃?，這就要求集群中的所有節(jié)點(diǎn)必須保存已經(jīng)接收到的消息用以判別消息是否存在錯誤以及是否需要進(jìn)行消息重發(fā)。但是如果應(yīng)用程序一直保存接收到的消息，則會面臨內(nèi)存溢出的問題。為了解決這個矛盾，JGroups通過STABLE協(xié)議負(fù)責(zé)周期性的釋放所有節(jié)點(diǎn)上已經(jīng)被所有節(jié)點(diǎn)收到的消息，從而達(dá)到回收各個節(jié)點(diǎn)上內(nèi)存的目的。分布式垃圾回收過程定義了由集群的協(xié)調(diào)者組織的定期執(zhí)行回收的周期，它可以通過控制每個節(jié)點(diǎn)上允許保留的消息數(shù)量或者單個節(jié)點(diǎn)上可以保留的消息所占用的內(nèi)存空間大小來決定什么時間執(zhí)行分布式垃圾回收動作，一旦集群的協(xié)調(diào)者通過周期性的任務(wù)檢測到集群中的節(jié)點(diǎn)中保存的消息數(shù)量超過了預(yù)設(shè)的閥值，或者保留的消息占用的內(nèi)存空間超過了預(yù)設(shè)的閥值則發(fā)出統(tǒng)一的垃圾回收指令，以釋放全體計算節(jié)點(diǎn)的內(nèi)存空間。

1.3 集群計算節(jié)點(diǎn)發(fā)現(xiàn)

JGroups為分布式環(huán)境下的計算機(jī)集群提供了一個高級抽象：通道（JChannel），每一個計算節(jié)點(diǎn)在啟動之初都會通過通道連接到相應(yīng)的集群。每個集群都有唯一的標(biāo)識（ClusterName），計算節(jié)點(diǎn)通過通道和集群標(biāo)識來判斷自己屬于哪一個計算工作群組。當(dāng)集群中的節(jié)點(diǎn)開始工作時，它開始探測通道中是否存在有其他已經(jīng)在運(yùn)行的節(jié)點(diǎn)，如果存在多個已經(jīng)運(yùn)行的節(jié)點(diǎn)則需要找到集群當(dāng)中的集群協(xié)調(diào)者進(jìn)行通信。在通道中第一個啟動的計算節(jié)點(diǎn)被認(rèn)為是集群的協(xié)調(diào)者，它負(fù)責(zé)創(chuàng)建新的計算節(jié)點(diǎn)并將其通知到集群中的每個成員對象。集群成員發(fā)現(xiàn)協(xié)議用來發(fā)現(xiàn)集群中活躍的節(jié)點(diǎn)及集群的協(xié)調(diào)者，這個協(xié)議的名稱是PING協(xié)議。

PING協(xié)議位于傳輸協(xié)議之上，任意一個節(jié)點(diǎn)對PING消息的反饋消息包括協(xié)調(diào)者的地址和自己的地址。JOIN PING消息發(fā)送后等待timeout屬性定義的時間或num_initial_members屬性定義的節(jié)點(diǎn)回復(fù)后，該加入的節(jié)點(diǎn)會根據(jù)反饋消息確定協(xié)調(diào)者，并向其發(fā)送JOIN消息。如果沒有收到任何反饋，計算節(jié)點(diǎn)就認(rèn)為自己是集群中第一個節(jié)點(diǎn)而作為協(xié)調(diào)者運(yùn)行啟動。

計算節(jié)點(diǎn)利用PING協(xié)議收集到的信息接著傳遞給集群成員管理協(xié)議（GMS），GMS協(xié)議與協(xié)調(diào)者的GMS通信，將新加入的節(jié)點(diǎn)加入到集群。發(fā)現(xiàn)協(xié)議通常也協(xié)助合并協(xié)議（MERGE2）處理集群分裂的情形。發(fā)現(xiàn)協(xié)議位于傳輸協(xié)議之上，因此需要傳輸協(xié)議的不同使用相應(yīng)的發(fā)現(xiàn)協(xié)議。

1.4 計算節(jié)點(diǎn)狀態(tài)檢測與管理

集群中計算節(jié)點(diǎn)的狀態(tài)管理主要由心跳協(xié)議（FD）、群組成員關(guān)系協(xié)議（GMS）、錯誤探測協(xié)議（FD-SOCK）和確認(rèn)可疑協(xié)議（VERIFY_SUSPECT）等共同完成。

GMS協(xié)議

GMS即群組成員關(guān)系協(xié)議，該協(xié)議是JGroups協(xié)議棧中的重要協(xié)議，它維護(hù)者一個活著節(jié)點(diǎn)的列表。GMS負(fù)責(zé)群組成員加入和離開群組的請求，同時它也處理錯誤探測協(xié)議發(fā)送的SUSPECT協(xié)議。

FD協(xié)議

FD協(xié)議基于心跳消息（are-you-alive）。該協(xié)議需要任意一個節(jié)點(diǎn)周期性的Ping它的鄰居節(jié)點(diǎn)，如果鄰居節(jié)點(diǎn)沒有返回，發(fā)生心跳消息的節(jié)點(diǎn)發(fā)送SUSPECT消息給集群協(xié)調(diào)者，集群協(xié)調(diào)者接收到SUSPECT消息后驗(yàn)證懷疑的節(jié)點(diǎn)是否死掉（VERIFY_SUSPECT），如果節(jié)點(diǎn)被確認(rèn)為死掉，協(xié)調(diào)者更新集群成員關(guān)系視圖，死掉的節(jié)點(diǎn)被移除。

FD-SOCK協(xié)議

錯誤探測協(xié)議FD_SOCK基于群組成員創(chuàng)建的TCP套接字環(huán)，F(xiàn)D_SOCK協(xié)議不使用心跳消息作為探測手段。集群中的任何一個節(jié)點(diǎn)都連接到它的鄰居，集群中第一個節(jié)點(diǎn)連接到第二個節(jié)點(diǎn)，第二個節(jié)點(diǎn)連接到第三個節(jié)點(diǎn)，這樣最后一個節(jié)點(diǎn)連接到第一個節(jié)點(diǎn)。這樣如果某一個節(jié)點(diǎn)發(fā)送異常，它的鄰居節(jié)點(diǎn)會發(fā)現(xiàn)異常，檢測到錯誤。

VERIFY_SUSPECT協(xié)議

VERIFY_SUSPECT協(xié)議通過向被懷疑的對象發(fā)送確認(rèn)消息來確認(rèn)被懷疑的節(jié)點(diǎn)是否確實(shí)死掉了。這個操作是被集群的協(xié)調(diào)者執(zhí)行的。如果確認(rèn)節(jié)點(diǎn)死掉，則該節(jié)點(diǎn)將會被移至異常集群成員列表視圖。

1.5 通訊流量控制

FC協(xié)議（Flow Control流量控制協(xié)議）用來在集群中調(diào)節(jié)單位時間內(nèi)計算節(jié)點(diǎn)發(fā)送消息的字節(jié)數(shù)和消息接收的字節(jié)數(shù)。在現(xiàn)實(shí)中情況復(fù)雜的應(yīng)用網(wǎng)絡(luò)環(huán)境下，如果消息發(fā)送者的數(shù)據(jù)發(fā)送的速度超過了消息接收者數(shù)據(jù)處理消息的速度，經(jīng)常會導(dǎo)致接收方陷入異?；蛘邅G失消息，這將觸發(fā)消息重發(fā)機(jī)制同時導(dǎo)致消息傳輸效率的急劇下降，流量控制協(xié)議負(fù)責(zé)調(diào)解此類狀況。事實(shí)上，JGroups流量控制協(xié)議基于類似金融信貸的設(shè)計，一開始消息發(fā)送者和消息接收者都配置有相同的額度（字節(jié)數(shù)），發(fā)送者通過不斷發(fā)送消息的字節(jié)數(shù)減少額度，接收者則通過計算已接收到的字節(jié)數(shù)增加額度，如果發(fā)送者的發(fā)送額度降低到某一閾值，接收者將已經(jīng)接收到的字節(jié)數(shù)反饋給發(fā)送者，要求發(fā)送者繼續(xù)發(fā)送后續(xù)的消息，如果發(fā)送者用完自己的額度，則發(fā)送者處于阻塞狀態(tài)直到接收到接收者的所有消息數(shù)據(jù)。

消息裂解協(xié)議（FRAG2協(xié)議）用于處理超大消息數(shù)據(jù)的通信。當(dāng)一個消息的大小大于某一確定的值時，通常這種字節(jié)數(shù)過大的消息經(jīng)常會造成網(wǎng)絡(luò)擁堵甚至在極端情況下會觸發(fā)網(wǎng)絡(luò)交換機(jī)的自我保護(hù)機(jī)制而直接斷開通信端口，為了避免此類情況的發(fā)生，分裂協(xié)議將消息分裂成多個小消息，然后進(jìn)行發(fā)送；而在接收端，同樣分裂協(xié)議將分裂的消息進(jìn)行重組。不管多播還是單播發(fā)送消息，分裂協(xié)議都可以起作用。

1.6 集群的分裂與重組

在情況復(fù)雜的網(wǎng)絡(luò)環(huán)境中，處于工作狀態(tài)中的集群分組可能由于網(wǎng)絡(luò)故障而斷開了網(wǎng)絡(luò)通信，這將導(dǎo)致計算集群的分裂，每個分裂后的子集群將由GMS協(xié)議推舉出最年長（最早啟動的計算節(jié)點(diǎn)）的節(jié)點(diǎn)作為網(wǎng)絡(luò)協(xié)調(diào)者。一旦網(wǎng)絡(luò)恢復(fù)通信，兩個分裂的集群通過JGroups通道和集群的唯一標(biāo)識發(fā)現(xiàn)在集群中出現(xiàn)了兩個網(wǎng)絡(luò)協(xié)調(diào)者，它們將啟動一個集群合并的進(jìn)程，這個進(jìn)程主要由集群合并協(xié)議（MERGE2）來負(fù)責(zé)調(diào)度完成。在合并的過程中，兩個網(wǎng)絡(luò)協(xié)調(diào)者將交換節(jié)點(diǎn)啟動信息，從而推舉出最年長的節(jié)點(diǎn)作為新的網(wǎng)絡(luò)協(xié)調(diào)者。為了確保在集群環(huán)境中各個網(wǎng)絡(luò)協(xié)調(diào)者都能達(dá)成一致的結(jié)果，每個協(xié)調(diào)者將所有成員的地址合并在一個列表中，然后對列表依據(jù)啟動時間進(jìn)行排序，在排序列表的第一位成員即是新的網(wǎng)絡(luò)協(xié)調(diào)者。

1.7 集群的網(wǎng)絡(luò)安全

為了保證只有經(jīng)過驗(yàn)證的計算節(jié)點(diǎn)才能加入到集群計算，JGroups提供了通信安全加密協(xié)議。通常情況下，計算節(jié)點(diǎn)通訊的加密過程只針對消息主體內(nèi)容進(jìn)行加密，消息頭數(shù)據(jù)是不經(jīng)過加密的。如果需要對整個包含消息發(fā)送端的地址和消息接收端的地址完整通信報文進(jìn)行加密，需要配置額外的屬性encrypt_entire_message的值為true。需要注意的是，消息加密的過程可能會導(dǎo)致網(wǎng)絡(luò)通信效率的下降，因?yàn)樵诿恳淮蔚木W(wǎng)絡(luò)通信過程中處理字符加密的過程也會消耗額外的計算機(jī)資源。

2 小結(jié)

本文對組成網(wǎng)絡(luò)環(huán)境的計算機(jī)集群所需要考慮的數(shù)據(jù)通訊協(xié)議進(jìn)行了分析。創(chuàng)建一個計算集群需要考慮如何在計算成員之間進(jìn)行可靠的消息傳輸，集群服務(wù)啟動之后如何探測和發(fā)現(xiàn)集群中網(wǎng)絡(luò)計算成員，如何確定網(wǎng)絡(luò)協(xié)調(diào)者的身份。網(wǎng)絡(luò)協(xié)調(diào)者在運(yùn)行狀態(tài)下需要隨時了解集群中每個成員的健康狀態(tài)，一旦集群中某臺機(jī)器出現(xiàn)了故障則需要將它從成員列表中刪除，如果集群中加入了新的計算成員則需要由網(wǎng)絡(luò)協(xié)調(diào)者將其加入到成員列表中并安排新成員的排序位置。同時需要考慮，如果網(wǎng)絡(luò)通信出現(xiàn)故障后如何組織新的集群，網(wǎng)絡(luò)通信恢復(fù)正常后如何將分裂的集群進(jìn)行合并以恢復(fù)集群的運(yùn)行。并在此基礎(chǔ)上，討論了集群環(huán)境下網(wǎng)絡(luò)通信的安全性和網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)牧髁靠刂茀f(xié)議。

當(dāng)前大數(shù)據(jù)計算技術(shù)越來越引起了人們的興趣，從根本上來說，大數(shù)據(jù)的分布式計算模型也需要考慮到文中所討論的這些應(yīng)用場景，作為一個小型的網(wǎng)絡(luò)集群解決方案，JGroups提供了很好的思路可以進(jìn)行參考和學(xué)習(xí)。