基于增量式同步的文件分發(fā)系統(tǒng)

蘭善瑞，王曉懿

（北京工業(yè)大學(xué)，北京 100020）

1 概述

隨著地鐵的智能化，產(chǎn)生了大量的計算機應(yīng)用，地鐵相關(guān)系統(tǒng)在使用過程中也需要對多個程序文件進行分發(fā)與維護[1]。如圖 1所示，因為要保證數(shù)據(jù)安全，不能使用傳統(tǒng)的商業(yè)化工具進行分發(fā)，需要操作人員攜帶程序文件進入真實的環(huán)境進行文件分發(fā)。如何保證文件分發(fā)安全，是地鐵相關(guān)企業(yè)面臨的主要問題。除此之外，高鐵與地鐵程序需要跨地區(qū)分布，進而導(dǎo)致文件分發(fā)需要面臨低帶寬、高延遲的網(wǎng)絡(luò)環(huán)境。如何解決程序的安全快速更新以及低帶寬環(huán)境下的文件分發(fā)效率低，是目前地鐵企業(yè)比較關(guān)注的問題。

圖1 文件分發(fā)場景Fig.1 File distribution scenario

2 文件分發(fā)問題概述

考慮到安全問題，目前地鐵程序文件部署時，需要人員手動攜帶U盤進行拷貝。考慮到地鐵運營的特殊性，這種方式很難滿足需要，所以需要文件分發(fā)系統(tǒng)在局域網(wǎng)內(nèi)快速進行分發(fā)。

國內(nèi)外已經(jīng)存在很多的文件分發(fā)系統(tǒng)或者文件分發(fā)工具，例如FileZilla、rsync以及多用于跨機備份的NetBackup、BackupPC等，這些文件分發(fā)系統(tǒng)都存在一些不足。首先，很多工具只能支持Unix系統(tǒng)或者Windows，兼容性不高；其次，大部分的文件傳輸系統(tǒng)都是全量式傳輸，對于大文件傳輸支持比較差，尤其在低帶寬、高延遲情況下，容易傳輸失敗[2]；最后，系統(tǒng)大都只用于文件傳輸，難以支持程序這種特殊文件的維護。

3 文件分發(fā)系統(tǒng)設(shè)計與實現(xiàn)

針對上述存在的問題，以提高傳輸性能和傳輸安全性為目標(biāo)，設(shè)計實現(xiàn)一個基于增量式同步的文件分發(fā)系統(tǒng)。首先，完成基本架構(gòu)設(shè)計；其次，針對全量式傳輸效率低下以及低帶寬、高延遲網(wǎng)絡(luò)環(huán)境下的文件傳輸效率慢、容易傳輸失敗的問題，設(shè)計了適應(yīng)不同網(wǎng)絡(luò)的增量式傳輸算法；最后，設(shè)計版本校驗、文件備份與恢復(fù)、遠(yuǎn)程維護功能，來保證文件傳輸?shù)陌踩耘c可靠性。

3.1 系統(tǒng)架構(gòu)

基于增量式同步的文件分發(fā)系統(tǒng)（簡稱系統(tǒng)）采用B/S[3]的架構(gòu)，前端使用QT作為客戶端，主要用于數(shù)據(jù)的顯示與獲取，同時向操作人員提供數(shù)據(jù)的增、刪、改、查操作以及文件分發(fā)、遠(yuǎn)程維護等功能；后端使用python作為服務(wù)端，負(fù)責(zé)向前端提供接口，完成相關(guān)業(yè)務(wù)邏輯，調(diào)用底層傳輸模塊完成數(shù)據(jù)分發(fā)，并維護數(shù)據(jù)層的數(shù)據(jù)；系統(tǒng)使用SSH的方式保證機器節(jié)點之間的安全連接，使用增量式傳輸與SCP結(jié)合的方式進行文件分發(fā)；系統(tǒng)采用關(guān)系型數(shù)據(jù)庫MySQL存儲相關(guān)數(shù)據(jù)，如圖2所示。

圖2 系統(tǒng)架構(gòu)Fig.2 System architecture

3.2 適應(yīng)不同網(wǎng)絡(luò)的增量式傳輸算法

隨著計算機技術(shù)的不斷更新，高鐵、地鐵系統(tǒng)在使用過程中需要對多個程序文件進行更新與維護。目前高鐵、地鐵程序的更新，大部分?jǐn)?shù)據(jù)都已經(jīng)存在，修改的部分可能只是整個程序文件的一部分，如果傳輸整個文件，整個傳輸效率非常低下。傳統(tǒng)的U盤拷貝或者全量式傳輸，尤其面向大文件傳輸時，文件傳輸耗時很長。

系統(tǒng)能夠支持文件的增量式傳輸，通過對舊文件與新文件的比較，在傳輸過程中，只面向增量部分進行傳輸，從而減少傳輸內(nèi)容，提高傳輸效率。

3.2.1 增量式傳輸算法的研究與優(yōu)化

為解決兼容性問題，增量式傳輸算法基于rsync思想使用python進行實現(xiàn)。增量式傳輸算法分為4個模塊，依次為分塊模塊、傳輸模塊、查找模塊、比對模塊，分別用于增量部分的計算、傳輸、查找和比對[4]。具體流程如圖 3所示。

圖3 增量式比對算法流程Fig.3 Incremental alignment algorithm process

經(jīng)過測試發(fā)現(xiàn)，實現(xiàn)的增量式傳輸算法性能太差，很難支持文件的快速分發(fā)。增量式算法中，主要占用時間比較多的為比對算法?？紤]到python性能太差，這里使用C++對該模塊進行重寫，并通過pybind的方式將函數(shù)封裝起來，用于分塊和比對模塊調(diào)用。為驗證修改后性能的提高，分別對優(yōu)化前后進行對比。對比結(jié)果如表 1所示。

表 1 增量式傳輸優(yōu)化比較結(jié)果Tab.1 Incremental transmission optimization comparison results

為更直觀地比較兩者花費的時間，使用柱形圖將兩者花費的時間展示出來。 如圖 4所示，增量式計算的總時間由原來的827.08 s縮減到20.74 s，縮減了將近40倍。

圖4 增量式優(yōu)化比較結(jié)果Fig.4 Incremental optimization comparison results

3.2.2 適應(yīng)網(wǎng)絡(luò)的自動分塊算法

在真實場景進行文件分發(fā)時，往往會因為網(wǎng)絡(luò)情況的不同導(dǎo)致分發(fā)速度不同。低帶寬、高延遲的網(wǎng)絡(luò)環(huán)境，往往會出現(xiàn)傳輸失敗的情況。對于小文件傳輸來說，失敗后再次傳輸，重傳的代價比較小；對于大文件來說，失敗后再次傳輸，代價會很大，導(dǎo)致文件分發(fā)花費的時間持續(xù)增加。本文使用適應(yīng)不同網(wǎng)絡(luò)條件的動態(tài)分塊方法來解決大文件傳輸失敗的問題。

1）網(wǎng)絡(luò)條件的判斷

網(wǎng)絡(luò)判斷方法很多，追其根源都是發(fā)送一個包并計算往返所花費的時間。經(jīng)過調(diào)研與實驗，ping命令即可滿足當(dāng)前需求，ping不僅可以判斷網(wǎng)絡(luò)是否通暢，還可以判斷網(wǎng)絡(luò)連接速度的快慢。ping底層使用ICMP協(xié)議，作為IP補充協(xié)議的ICMP，可以向主機或者路由器報告差錯與異常情況。

2）網(wǎng)絡(luò)條件的融合

在實際場景中服務(wù)器可能會向多個遠(yuǎn)程機器節(jié)點進行文件分發(fā)，設(shè)備距離服務(wù)器的位置有遠(yuǎn)有近，服務(wù)器與設(shè)備之間的網(wǎng)絡(luò)情況自然不同。如果在分塊時根據(jù)每一臺設(shè)備的網(wǎng)絡(luò)情況進行分塊，隨著設(shè)備的增加，分塊的次數(shù)將會提高很多。但是在實際情況中，會發(fā)現(xiàn)很多設(shè)備的延遲大都相同，在相同的網(wǎng)絡(luò)條件下進行分發(fā)，整體的傳輸時間不會相差太大。此時如果將網(wǎng)絡(luò)條件相差不大的設(shè)備融合起來，即將網(wǎng)絡(luò)條件相似的設(shè)備看成一個設(shè)備。這樣在發(fā)送同一個文件時，分塊的次數(shù)會得到大量的減少，從而減少分塊花費的時間。

融合實際上就是聚類[5]，簡單說就是將相似的東西聚集在一起。對于聚類問題，計算機領(lǐng)域常使用聚類分析方法解決?？紤]到網(wǎng)絡(luò)花費時長數(shù)值比較小、比較連續(xù)，且對聚合后分成的類別和數(shù)量比較明確，本文使用K-means聚類算法[6]即可解決類似問題。

基于K-means的網(wǎng)絡(luò)條件融合流程如圖5所示，流程主要分為5步。1）輸入通過上面網(wǎng)絡(luò)條件判斷后結(jié)果的集合；2）根據(jù)上述設(shè)定的K值，選擇K個中心點；3）使用歐式距離計算數(shù)據(jù)點與中心點的距離并根據(jù)距離進行劃分；4）根據(jù)距離，更新聚類中心；5）進行均值誤差的判斷，當(dāng)連續(xù)兩次聚類差距小于0.000 1時停止聚類，并將最后一次聚類的結(jié)果作為最后的聚類結(jié)果。

圖5 基于K-means算法的網(wǎng)絡(luò)條件融合流程Fig.5 Network condition fusion process based on K-means algorithm

3）文件分塊標(biāo)準(zhǔn)

動態(tài)分塊需要一個標(biāo)準(zhǔn)進行分塊，分塊標(biāo)準(zhǔn)主要依據(jù)文件大小和網(wǎng)絡(luò)條件。

對于文件大小來說，以50 MB的文件作為基準(zhǔn)，小于50 MB的文件不進行分塊，其他的按照文件大小進行翻倍即可。大部分機器的網(wǎng)絡(luò)延遲主要集中在0～1 000 ms之間，主要分布范圍：0～10 ms、10～100 ms、100～300 ms、300～1000 ms、1 000 ms以上。根據(jù)不同的網(wǎng)絡(luò)條件對文件分別進行分塊，分別為1、2、3、5、10。

4）文件分塊算法設(shè)計

分塊算法實際上就是分類算法，文件大小以及網(wǎng)絡(luò)條件是分類規(guī)則，塊的個數(shù)或者大小是分類結(jié)果。在計算機領(lǐng)域，有很多分類算法，例如決策樹[7]、貝葉斯、人工神經(jīng)網(wǎng)絡(luò)、K-近鄰等。考慮到文件分塊的標(biāo)準(zhǔn)數(shù)據(jù)量比較大以及決策樹構(gòu)造時不依賴任何較多的條件，所以選擇決策樹來進行文件分塊。

隨著計算機的不斷發(fā)展，在機器學(xué)習(xí)[8]領(lǐng)域也產(chǎn)生了很多的機器學(xué)習(xí)庫scikit-learn[9]作為一個高效可靠的機器學(xué)習(xí)框架，可支持分類、回歸、聚類、降維。本文選擇使用scikit-learn框架以及決策樹分類方式，對文件進行動態(tài)分塊。具體分塊流程如下。

a. 數(shù)據(jù)集的準(zhǔn)備

根據(jù)上述分塊標(biāo)準(zhǔn)使用python腳本動態(tài)生成數(shù)據(jù)集。

b. 數(shù)據(jù)集的訓(xùn)練

讀取數(shù)據(jù)集，將關(guān)鍵信息提取出來，并將數(shù)據(jù)存儲到list中。設(shè)定決策樹的深度為160， min_samples_split為2，將數(shù)據(jù)集進行訓(xùn)練，生成對應(yīng)的決策樹。

c. 數(shù)據(jù)的驗證

首先驗證訓(xùn)練數(shù)據(jù)。將訓(xùn)練數(shù)據(jù)作為輸入進行預(yù)測，并將正確結(jié)果與錯誤結(jié)果統(tǒng)計出來;其次，抽取真實數(shù)據(jù)進行驗證。

d. 模型的存儲

sklearn框架提供存儲模型接口，指定文件路徑即可將模型存儲下來。

3.3 文件分發(fā)針對實際問題的設(shè)計

在實際應(yīng)用場景中，常常因為低帶寬、高延遲的情況導(dǎo)致文件傳輸失敗。文件因為傳輸失敗導(dǎo)致不能使用，原文件在傳輸過程中也會被刪除，從而導(dǎo)致文件丟失。尤其對于程序文件，可能會面臨著緊急使用的情況，如果這時文件丟失，則會嚴(yán)重影響用戶的正常使用。除此之外，對于文件分發(fā)系統(tǒng)來說，在文件傳輸過程中，可能會出現(xiàn)數(shù)據(jù)被惡意修改的情況，進而引發(fā)數(shù)據(jù)安全的問題。針對以上實際場景出現(xiàn)的問題，本文研究文件分發(fā)系統(tǒng)針對實際問題的設(shè)計是否可以進一步提高文件傳輸安全性與可靠性。

3.3.1 版本校驗的設(shè)計

對版本校驗進行研究與設(shè)計，為防止文件傳輸過程中被惡意修改或者文件分塊導(dǎo)致文件部分?jǐn)?shù)據(jù)丟失，版本校驗使用MD5強驗證的方式來判斷傳輸內(nèi)容是否被修改，從而提高文件傳輸?shù)陌踩浴?/p>

結(jié)合MD5的特點與版本校驗的需求，對版本校驗的流程進行設(shè)計，具體流程如圖 6所示。因為版本校驗需要驗證兩臺機器上文件是否相同，所以還涉及到遠(yuǎn)程傳輸。

圖6 版本校驗流程Fig.6 Version Verification Process

3.3.2 文件備份與恢復(fù)的設(shè)計

在文件傳輸過程中，往往因為網(wǎng)絡(luò)原因或者人為原因等導(dǎo)致文件傳輸失敗。傳輸文件時，一般系統(tǒng)會先將原有文件清除掉，再傳輸新的文件，如果這時文件傳輸失敗，已經(jīng)傳輸?shù)奈募赡苤皇钦麄€文件的一部分。因為是部分文件，無法再進行使用，但是原有的文件已經(jīng)被清除，從而出現(xiàn)文件丟失的問題。

針對上述文件傳輸失敗導(dǎo)致的文件丟失問題進行研究。在文件發(fā)送之前，可以將文件備份到指定目錄，如果文件傳輸失敗，則將之前備份的文件恢復(fù)回來，從而保證文件不會出現(xiàn)丟失。

對文件備份的流程進行設(shè)計，具體流程如圖 7所示。首先進行文件壓縮，如果失敗，返回備份失敗。其次對壓縮包拷貝，如果失敗，返回備份失敗。最后刪除壓縮包，如果失敗，返回備份失敗。

圖7 文件備份流程Fig.7 File backup process

對文件恢復(fù)流程進行設(shè)計，具體流程如圖 8所示。首先，根據(jù)文件路徑將傳輸失敗的文件刪除，如果刪除失敗，返回文件恢復(fù)失敗。其次，將之前文件備份的壓縮包拷貝到文件路徑中，如果拷貝失敗，返回文件恢復(fù)失敗。再次，將拷貝來的壓縮包解壓到當(dāng)前路徑，如果解壓失敗，返回文件恢復(fù)失敗。最后，將拷貝來的壓縮包刪除。

圖8 文件恢復(fù)流程Fig.8 File recovery process

3.3.3 遠(yuǎn)程維護的設(shè)計

SSH不僅可以建立連接，還可以支持執(zhí)行遠(yuǎn)程機器命令的功能，可以為遠(yuǎn)程維護提供很好的解決方案。遠(yuǎn)程維護可以在SSH執(zhí)行遠(yuǎn)程機器命令的基礎(chǔ)上，對其進行封裝，從而提高用戶的易用性。

對遠(yuǎn)程維護的流程進行設(shè)計，具體流程如圖 9所示。首先，從界面獲取待執(zhí)行的命令或者腳本文件。其次，使用SSH執(zhí)行遠(yuǎn)程命令，等待完成。最后，獲取執(zhí)行結(jié)果，回顯到界面。

圖9 遠(yuǎn)程維護流程Fig.9 Remote maintenance process

4 系統(tǒng)實驗與結(jié)果分析

針對低帶寬環(huán)境的文件分發(fā)進行測試，本文對7臺liunx機器使用Netem來配置低帶寬以及傳輸延遲的環(huán)境。選擇這7臺機器對489.1 MB的文件分別使用SCP工具以及系統(tǒng)進行分發(fā)測試，測試結(jié)果如表2所示。

表 2 低帶寬增量式傳輸實驗數(shù)據(jù)Tab.2 Low bandwidth incremental transmission experimental data

為了更直觀的對比上述兩者，將二者傳輸花費的時長以折線圖的形式展現(xiàn)，具體結(jié)果如圖10所示?？梢杂嬎愕贸?，在低帶寬環(huán)境下，系統(tǒng)比SCP在性能上提高了大約52%，由此可見適應(yīng)不同網(wǎng)絡(luò)的增量式傳輸算法對低帶寬環(huán)境的文件分發(fā)性能的提高起到了一定作用。

圖10 低帶寬增量式傳輸數(shù)據(jù)折線Fig.10 Low bandwidth incremental transmission data

5 結(jié)語

本文研究適應(yīng)不同網(wǎng)絡(luò)的增量式傳輸算法在低帶寬、高延遲的網(wǎng)絡(luò)條件下對傳輸性能的影響，通過實驗證明該方法可以較好地解決低帶寬的問題。通過研究文件分發(fā)系統(tǒng)針對實際問題的設(shè)計、對文件傳輸性能以及文件傳輸安全性的影響，經(jīng)過實際項目的測試，發(fā)現(xiàn)版本校驗、文件備份與恢復(fù)、遠(yuǎn)程維護的設(shè)計可以保證傳輸安全性與傳輸性能。