楊永凱，彭明田，王煒東

(1.中國(guó)民航信息網(wǎng)絡(luò)股份有限公司，北京 101318；2.民航旅客服務(wù)智能化應(yīng)用技術(shù)重點(diǎn)實(shí)驗(yàn)室，北京 101318)

0 引 言

在信息化工程領(lǐng)域，經(jīng)常需要面對(duì)局域網(wǎng)集群內(nèi)一對(duì)多模式下的數(shù)據(jù)文件分發(fā)問(wèn)題，即從一臺(tái)生產(chǎn)者主機(jī)向集群內(nèi)若干臺(tái)訂閱者主機(jī)進(jìn)行數(shù)據(jù)文件的分發(fā)傳輸。以民航信息化行業(yè)為例：航班的艙位狀態(tài)報(bào)文(SSIM報(bào))是一種高頻的數(shù)據(jù)文件，全球所有航班的任何一次艙位變化(銷售、取消、控制等)均會(huì)觸發(fā)SSIM報(bào)文；而全球的民航運(yùn)價(jià)數(shù)據(jù)在經(jīng)過(guò)預(yù)處理后會(huì)形成大體量的數(shù)據(jù)文件，部分文件壓縮后仍達(dá)到幾十G左右，這種數(shù)據(jù)文件在以約每小時(shí)一次的頻率更新變化。在民航工程應(yīng)用中，需要將這兩類數(shù)據(jù)文件從生產(chǎn)者主機(jī)高效準(zhǔn)確地分發(fā)到集群中數(shù)十甚至上百臺(tái)訂閱者主機(jī)上，進(jìn)而在訂閱者主機(jī)(即計(jì)算節(jié)點(diǎn))上實(shí)現(xiàn)高性能的可用機(jī)票搜索計(jì)算服務(wù)。在局域網(wǎng)集群內(nèi)的數(shù)據(jù)分發(fā)方案設(shè)計(jì)方面，高效和可靠往往意味著系統(tǒng)優(yōu)化的兩個(gè)不同方向：FTP、HTTP等基于TCP協(xié)議實(shí)現(xiàn)的通信協(xié)議，可以實(shí)現(xiàn)準(zhǔn)確可靠的數(shù)據(jù)傳輸，但是TCP協(xié)議只能支持一對(duì)一(端到端)的傳輸模式，在生產(chǎn)/訂閱這種一對(duì)多模式下，意味著必須重復(fù)多次傳輸，占用大量的網(wǎng)絡(luò)帶寬資源，無(wú)法實(shí)現(xiàn)高效的目的；而UDP協(xié)議可以實(shí)現(xiàn)一對(duì)多的數(shù)據(jù)傳輸，能夠大幅節(jié)省網(wǎng)絡(luò)帶寬資源，但是由于UDP協(xié)議本身是輕量級(jí)的無(wú)連接協(xié)議，無(wú)法保障傳輸?shù)臏?zhǔn)確可靠性。在工程實(shí)踐中，基于開源架構(gòu)的消息中間件ZeroMQ和自行設(shè)計(jì)的控制邏輯構(gòu)建了一套以UDP傳輸為主，輔以TCP協(xié)議進(jìn)行控制的集群內(nèi)高效可靠的多播數(shù)據(jù)文件分發(fā)方案，成功解決了高頻報(bào)文或者大體量數(shù)據(jù)文件的一對(duì)多數(shù)據(jù)分發(fā)問(wèn)題[1-5]。

1 ZeroMQ簡(jiǎn)介

ZeroMQ不是單獨(dú)的服務(wù)或者程序，僅僅是一套組件，其封裝了網(wǎng)絡(luò)通信、消息隊(duì)列、線程調(diào)度等功能，向上層提供簡(jiǎn)潔的API，應(yīng)用程序通過(guò)加載庫(kù)文件，調(diào)用API函數(shù)來(lái)實(shí)現(xiàn)高性能網(wǎng)絡(luò)通信。由于ZeroMQ是用C/C++開發(fā)地，并且其協(xié)議格式定義得很簡(jiǎn)單，所以它的性能遠(yuǎn)遠(yuǎn)高于其他消息隊(duì)列中間件。

ZeroMQ提供了4種基礎(chǔ)消息通訊模式，分別是一對(duì)一結(jié)對(duì)模式(Exclusive-Pair)、請(qǐng)求應(yīng)答模式(Request-Reply)、發(fā)布訂閱模式(Publish-Subscribe)和推拉模式(Push-Pull)。這4種模式總結(jié)出了通用的網(wǎng)絡(luò)通信模型，使用者可以根據(jù)具體應(yīng)用場(chǎng)景，使用其中的任何一種或多種模式，構(gòu)建自己的通訊架構(gòu)解決方案。文中方案所涉及的主要是發(fā)布訂閱模式。

ZeroMQ的發(fā)布訂閱模式封裝了UDP通信協(xié)議的實(shí)現(xiàn)細(xì)節(jié)，簡(jiǎn)化了系統(tǒng)設(shè)計(jì)和編程實(shí)現(xiàn)的開發(fā)工作，基于ZeroMQ組件可以簡(jiǎn)單快捷地實(shí)現(xiàn)基于UDP協(xié)議的高效的多播數(shù)據(jù)分發(fā)。在ZeroMQ的發(fā)布訂閱模式下，發(fā)布端負(fù)責(zé)單向分發(fā)數(shù)據(jù)，且不關(guān)心是否把全部數(shù)據(jù)發(fā)送給訂閱端。如果發(fā)布端開始發(fā)布數(shù)據(jù)時(shí)，訂閱端尚未連接上來(lái)，則這些數(shù)據(jù)會(huì)被直接丟棄。訂閱端只負(fù)責(zé)接收數(shù)據(jù)，而不能反饋，且在訂閱端處理速度慢于發(fā)布端處理速度的情況下，會(huì)在訂閱端堆積數(shù)據(jù)。其結(jié)構(gòu)如圖1所示[6-7]。

圖1 發(fā)布訂閱模式

在工程實(shí)踐中，除了需要考慮高效外，還要兼顧可靠性。為了保障數(shù)據(jù)文件分發(fā)傳輸?shù)目煽啃?，必須在UDP多播的基礎(chǔ)上增加控制流，以實(shí)現(xiàn)對(duì)多播分發(fā)的有效調(diào)度，從而避免丟包、亂序、不一致、數(shù)據(jù)堆積等方面的問(wèn)題?？刂屏鞯膶?shí)現(xiàn)必須通過(guò)可靠的TCP協(xié)議來(lái)自行設(shè)計(jì)實(shí)現(xiàn)。

2 系統(tǒng)設(shè)計(jì)

2.1 總體結(jié)構(gòu)

系統(tǒng)在設(shè)計(jì)實(shí)現(xiàn)上采取了數(shù)據(jù)流和控制流相對(duì)分離的設(shè)計(jì)機(jī)制，系統(tǒng)整體結(jié)構(gòu)如圖2所示。數(shù)據(jù)流基于ZeroMQ包裝的UDP協(xié)議實(shí)現(xiàn)，圖中用實(shí)線箭頭表示；控制流通過(guò)自主設(shè)計(jì)的基于TCP協(xié)議的控制機(jī)制實(shí)現(xiàn)，圖中用虛線箭頭表示。數(shù)據(jù)流和控制流結(jié)合達(dá)到數(shù)據(jù)文件分發(fā)過(guò)程中高效和可靠的目的。

圖2 系統(tǒng)整體結(jié)構(gòu)

將集群中負(fù)責(zé)數(shù)據(jù)文件分發(fā)的主機(jī)定義為Master主機(jī)，Master主機(jī)實(shí)現(xiàn)發(fā)布者Publisher的功能，將集群中接收數(shù)據(jù)文件的主機(jī)定義為Node主機(jī)，Node主機(jī)實(shí)現(xiàn)訂閱者Subscriber的功能，Master和Node之間通過(guò)ZeroMQ的發(fā)布訂閱模式實(shí)現(xiàn)多播數(shù)據(jù)的傳輸，從而構(gòu)成數(shù)據(jù)流的設(shè)計(jì)。

控制流的設(shè)計(jì)主要由Master主機(jī)上的監(jiān)控服務(wù)(Monitor)模塊、調(diào)速服務(wù)(Shift)模塊以及Node主機(jī)上的檢測(cè)服務(wù)(Check)模塊、計(jì)速服務(wù)(Meter)模塊組成。Master主機(jī)上的Monitor服務(wù)與各Node主機(jī)上的Check服務(wù)配對(duì)實(shí)現(xiàn)針對(duì)數(shù)據(jù)流的傳輸開關(guān)控制，包括傳輸端口的控制(打開及關(guān)閉)以及數(shù)據(jù)流的啟停等。Master主機(jī)上的Shift模塊與各Node主機(jī)上的Meter模塊配對(duì)實(shí)現(xiàn)針對(duì)數(shù)據(jù)流的傳輸速率控制，兼顧網(wǎng)絡(luò)環(huán)境和Node節(jié)點(diǎn)的處理效率，保障Master主機(jī)以合適的速率在集群內(nèi)分發(fā)數(shù)據(jù)文件。

另外在Master主機(jī)設(shè)計(jì)了Register服務(wù)模塊，當(dāng)有新的Node主機(jī)連接入集群時(shí)，其本地的Check服務(wù)首先與Master主機(jī)的Register服務(wù)建立TCP連接，將新加入的Node主機(jī)的信息注冊(cè)到Master主機(jī)，從而達(dá)到新加入的Node主機(jī)實(shí)時(shí)參與數(shù)據(jù)流多播的目的。

為了保障數(shù)據(jù)文件的完整，在Node主機(jī)設(shè)計(jì)了File Slot模塊，用來(lái)開辟緩存存儲(chǔ)大體量數(shù)據(jù)文件和高頻報(bào)文文件的多播數(shù)據(jù)包，待傳輸完成后，將相應(yīng)數(shù)據(jù)文件存入Node主機(jī)的指定位置。

高效可靠的多播數(shù)據(jù)傳輸方案的設(shè)計(jì)核心是控制流和數(shù)據(jù)流的交互模式，重點(diǎn)體現(xiàn)在控制流對(duì)數(shù)據(jù)流的傳輸開關(guān)控制和傳輸速率控制兩個(gè)方面。傳輸開關(guān)控制和傳輸速率控制的目的是在可接受的傳輸速率下，盡可能降低同一份文件的多播分發(fā)輪次，最理想的情況是Master主機(jī)執(zhí)行一次多播傳輸即可完成所有Node主機(jī)的數(shù)據(jù)文件接收，從而實(shí)現(xiàn)傳輸效率的最大化[8-12]。

2.2 數(shù)據(jù)流的傳輸開關(guān)控制

傳輸開關(guān)控制的目的是確定一個(gè)文件是否成功完成了分發(fā)傳輸，即所有Node主機(jī)均接收到了該文件，并啟動(dòng)下一個(gè)新文件的分發(fā)傳輸。具體流程如下：當(dāng)Master主機(jī)需要分發(fā)數(shù)據(jù)文件時(shí)，會(huì)通過(guò)Monitor服務(wù)告知各個(gè)Node主機(jī)節(jié)點(diǎn)的Check服務(wù)，隨后Check服務(wù)會(huì)檢查本地是否已經(jīng)有Master主機(jī)所要分發(fā)的數(shù)據(jù)文件，如果沒(méi)有則啟用數(shù)據(jù)流的Subscriber服務(wù)，Subscriber服務(wù)打開相應(yīng)的UDP端口，準(zhǔn)備接收數(shù)據(jù)；如果有則不啟用Subscriber服務(wù)，不打開相應(yīng)的UDP端口。Node主機(jī)的Check服務(wù)會(huì)將最后的檢查結(jié)果通過(guò)TCP連接告知Master主機(jī)，Master主機(jī)會(huì)檢測(cè)所有Node主機(jī)的返回結(jié)果，判斷集群中是否有節(jié)點(diǎn)需要接收當(dāng)前的數(shù)據(jù)文件，如果有則啟用本地的Publisher服務(wù)，Publisher服務(wù)會(huì)打開相應(yīng)的UDP端口通過(guò)多播分發(fā)數(shù)據(jù)文件；如果沒(méi)有則不啟用Publisher服務(wù)，不進(jìn)行當(dāng)前數(shù)據(jù)文件的分發(fā)，也標(biāo)志著Master主機(jī)已經(jīng)完成了當(dāng)前數(shù)據(jù)文件的分發(fā)。綜上所述，Monitor服務(wù)的操作流程如圖3所示，Check服務(wù)的操作流程如圖4所示[10-11]。

圖3 Monitor服務(wù)流程

圖4 Check服務(wù)流程

2.3 數(shù)據(jù)流的傳輸速率控制

傳輸速率控制的目的是保障Master主機(jī)的數(shù)據(jù)傳輸速率能夠和Node主機(jī)的數(shù)據(jù)處理速率適配，從而提升多播傳輸?shù)囊淮纬晒β?。根?jù)集群網(wǎng)絡(luò)的帶寬情況和Master與Node主機(jī)的硬件情況，確定多播傳輸速率的上限和下限數(shù)值，在數(shù)據(jù)流傳輸過(guò)程中，傳輸速率始終保持在上限和下限區(qū)間內(nèi)，這個(gè)速率區(qū)間可以定義為集群的高效多播區(qū)間。超過(guò)上限可能會(huì)頻繁出現(xiàn)Node接收失敗的問(wèn)題，導(dǎo)致同一個(gè)數(shù)據(jù)文件的多輪次分發(fā)，低于下限可能導(dǎo)致多播傳輸速率過(guò)低，文件分發(fā)時(shí)間過(guò)長(zhǎng)。

具體流程如下：Master主機(jī)的Shift服務(wù)讀取Config配置信息，包括多播速率的上下限、初始速率等，之后將相關(guān)信息發(fā)送給Publisher服務(wù)和Node主機(jī)上的Meter服務(wù)；根據(jù)數(shù)據(jù)流的傳輸開關(guān)控制機(jī)制，在本輪次多播分發(fā)啟動(dòng)后，Publisher服務(wù)會(huì)按照初始速率通過(guò)多播分發(fā)數(shù)據(jù)，Node主機(jī)的Subscriber服務(wù)負(fù)責(zé)接收多播數(shù)據(jù)；如果在接收數(shù)據(jù)的過(guò)程中，Subscriber服務(wù)出現(xiàn)數(shù)據(jù)積壓的情況會(huì)反饋給Meter服務(wù)，或者當(dāng)監(jiān)控到網(wǎng)絡(luò)繁忙的情況后，Meter服務(wù)會(huì)主動(dòng)和Master主機(jī)上的Shift服務(wù)通信，Shift服務(wù)會(huì)調(diào)整Publisher的多播速率以適應(yīng)所有Node的處理速率；如果Shift服務(wù)將速率調(diào)整到速率下限后仍舊有Node主機(jī)反饋存在數(shù)據(jù)積壓的情況，則通知相應(yīng)Node主機(jī)的Meter服務(wù)停止接收本輪次多播分發(fā)，并提升整個(gè)集群多播傳輸速率；被停止的Node主機(jī)可以等待當(dāng)前文件的下一輪次多播來(lái)完成文件接收，等待的過(guò)程同時(shí)也是該Node主機(jī)恢復(fù)數(shù)據(jù)處理的過(guò)程。傳輸速率控制的設(shè)計(jì)如圖5所示[11-12]。

圖5 傳輸速率控制的設(shè)計(jì)

3 系統(tǒng)實(shí)現(xiàn)和工程驗(yàn)證

基于上述數(shù)據(jù)流和控制流相結(jié)合的設(shè)計(jì)方案，在工程上進(jìn)行了編碼實(shí)現(xiàn)和實(shí)踐驗(yàn)證，具體的開發(fā)環(huán)境和部署環(huán)境如表1所示。

表1 工程實(shí)踐的應(yīng)用環(huán)境

目前該套系統(tǒng)已經(jīng)部署在生產(chǎn)環(huán)境，負(fù)責(zé)集群內(nèi)大體量文件的分發(fā)和高頻報(bào)文的分發(fā)任務(wù)。為了驗(yàn)證該方案針對(duì)大體量文件分發(fā)的有效性，任意截取了連續(xù)15天的文件分發(fā)數(shù)據(jù)作為15份樣本進(jìn)行方案驗(yàn)證，每1天的數(shù)據(jù)組成1份樣本。在每天內(nèi)的每個(gè)整點(diǎn)啟動(dòng)1個(gè)輪次多播分發(fā)，根據(jù)實(shí)際業(yè)務(wù)的更新情況，每輪次分發(fā)的數(shù)據(jù)文件總數(shù)在10至15個(gè)左右，最大的文件40 G左右，最小的10 M左右，每輪次需分發(fā)的文件總?cè)萘看蠹s為90 G左右。

定義n次分發(fā)成功率參數(shù)分別為R1,R2,…,Rn：

如果R1越接近于1，且Rn越早收斂到1，則表明該方案的控制流有效性越高。對(duì)上述工程實(shí)踐中樣本的匯總?cè)绫?所示：R1的平均值為0.983 3，絕大多數(shù)樣本R2即收斂為1，只有1個(gè)樣本在R3收斂為1，另外每組樣本的多播平均傳輸速率接近設(shè)定的上限100 Mib/s。從實(shí)際工程角度看，該方案的控制流有效性較高，可以滿足實(shí)際項(xiàng)目的需求[13-15]。

表2 工程實(shí)踐的驗(yàn)證結(jié)果

該方案同時(shí)還承擔(dān)高頻報(bào)文的分發(fā)任務(wù)，報(bào)文的大小基本在1至5K，非常適合于多播模式的傳輸，基于控制流的輔助，在生產(chǎn)集群中高頻報(bào)文的分發(fā)成功率R1基本約等于1，不再贅述。

4 結(jié)束語(yǔ)

綜上所述，該方案通過(guò)基于UDP多播的數(shù)據(jù)流和基于TCP協(xié)議的控制流相結(jié)合的方式，有效解決了集群內(nèi)數(shù)據(jù)文件分發(fā)過(guò)程中的高效和可靠兼得的問(wèn)題，即適用于集群內(nèi)大體量的數(shù)據(jù)文件分發(fā)，又適用于集群內(nèi)高頻報(bào)文文件的分發(fā)，在工程實(shí)踐中具有很重要的典型意義。