楊永凱，彭明田，王煒東

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

0 引 言

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

1 ZeroMQ簡介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

傳輸開關(guān)控制的目的是確定一個文件是否成功完成了分發(fā)傳輸，即所有Node主機均接收到了該文件，并啟動下一個新文件的分發(fā)傳輸。具體流程如下：當(dāng)Master主機需要分發(fā)數(shù)據(jù)文件時，會通過Monitor服務(wù)告知各個Node主機節(jié)點的Check服務(wù)，隨后Check服務(wù)會檢查本地是否已經(jīng)有Master主機所要分發(fā)的數(shù)據(jù)文件，如果沒有則啟用數(shù)據(jù)流的Subscriber服務(wù)，Subscriber服務(wù)打開相應(yīng)的UDP端口，準(zhǔn)備接收數(shù)據(jù)；如果有則不啟用Subscriber服務(wù)，不打開相應(yīng)的UDP端口。Node主機的Check服務(wù)會將最后的檢查結(jié)果通過TCP連接告知Master主機，Master主機會檢測所有Node主機的返回結(jié)果，判斷集群中是否有節(jié)點需要接收當(dāng)前的數(shù)據(jù)文件，如果有則啟用本地的Publisher服務(wù)，Publisher服務(wù)會打開相應(yīng)的UDP端口通過多播分發(fā)數(shù)據(jù)文件；如果沒有則不啟用Publisher服務(wù)，不進行當(dāng)前數(shù)據(jù)文件的分發(fā)，也標(biāo)志著Master主機已經(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主機的數(shù)據(jù)傳輸速率能夠和Node主機的數(shù)據(jù)處理速率適配，從而提升多播傳輸?shù)囊淮纬晒β?。根?jù)集群網(wǎng)絡(luò)的帶寬情況和Master與Node主機的硬件情況，確定多播傳輸速率的上限和下限數(shù)值，在數(shù)據(jù)流傳輸過程中，傳輸速率始終保持在上限和下限區(qū)間內(nèi)，這個速率區(qū)間可以定義為集群的高效多播區(qū)間。超過上限可能會頻繁出現(xiàn)Node接收失敗的問題，導(dǎo)致同一個數(shù)據(jù)文件的多輪次分發(fā)，低于下限可能導(dǎo)致多播傳輸速率過低，文件分發(fā)時間過長。

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

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

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

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

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

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

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

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

表2 工程實踐的驗證結(jié)果

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

4 結(jié)束語

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