基于增量式同步的文件分發系統

蘭善瑞，王曉懿

（北京工業大學，北京 100020）

1 概述

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

圖1 文件分發場景Fig.1 File distribution scenario

2 文件分發問題概述

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

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

3 文件分發系統設計與實現

針對上述存在的問題，以提高傳輸性能和傳輸安全性為目標，設計實現一個基于增量式同步的文件分發系統。首先，完成基本架構設計；其次，針對全量式傳輸效率低下以及低帶寬、高延遲網絡環境下的文件傳輸效率慢、容易傳輸失敗的問題，設計了適應不同網絡的增量式傳輸算法；最后，設計版本校驗、文件備份與恢復、遠程維護功能，來保證文件傳輸的安全性與可靠性。

3.1 系統架構

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

圖2 系統架構Fig.2 System architecture

3.2 適應不同網絡的增量式傳輸算法

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

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

3.2.1 增量式傳輸算法的研究與優化

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

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

經過測試發現，實現的增量式傳輸算法性能太差，很難支持文件的快速分發。增量式算法中，主要占用時間比較多的為比對算法。考慮到python性能太差，這里使用C++對該模塊進行重寫，并通過pybind的方式將函數封裝起來，用于分塊和比對模塊調用。為驗證修改后性能的提高，分別對優化前后進行對比。對比結果如表 1所示。

表 1 增量式傳輸優化比較結果Tab.1 Incremental transmission optimization comparison results

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

圖4 增量式優化比較結果Fig.4 Incremental optimization comparison results

3.2.2 適應網絡的自動分塊算法

在真實場景進行文件分發時，往往會因為網絡情況的不同導致分發速度不同。低帶寬、高延遲的網絡環境，往往會出現傳輸失敗的情況。對于小文件傳輸來說，失敗后再次傳輸，重傳的代價比較小；對于大文件來說，失敗后再次傳輸，代價會很大，導致文件分發花費的時間持續增加。本文使用適應不同網絡條件的動態分塊方法來解決大文件傳輸失敗的問題。

1）網絡條件的判斷

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

2）網絡條件的融合

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

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

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

圖5 基于K-means算法的網絡條件融合流程Fig.5 Network condition fusion process based on K-means algorithm

3）文件分塊標準

動態分塊需要一個標準進行分塊，分塊標準主要依據文件大小和網絡條件。

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

4）文件分塊算法設計

分塊算法實際上就是分類算法，文件大小以及網絡條件是分類規則，塊的個數或者大小是分類結果。在計算機領域，有很多分類算法，例如決策樹[7]、貝葉斯、人工神經網絡、K-近鄰等。考慮到文件分塊的標準數據量比較大以及決策樹構造時不依賴任何較多的條件，所以選擇決策樹來進行文件分塊。

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

a. 數據集的準備

根據上述分塊標準使用python腳本動態生成數據集。

b. 數據集的訓練

讀取數據集，將關鍵信息提取出來，并將數據存儲到list中。設定決策樹的深度為160， min_samples_split為2，將數據集進行訓練，生成對應的決策樹。

c. 數據的驗證

首先驗證訓練數據。將訓練數據作為輸入進行預測，并將正確結果與錯誤結果統計出來;其次，抽取真實數據進行驗證。

d. 模型的存儲

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

3.3 文件分發針對實際問題的設計

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

3.3.1 版本校驗的設計

對版本校驗進行研究與設計，為防止文件傳輸過程中被惡意修改或者文件分塊導致文件部分數據丟失，版本校驗使用MD5強驗證的方式來判斷傳輸內容是否被修改，從而提高文件傳輸的安全性。

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

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

3.3.2 文件備份與恢復的設計

在文件傳輸過程中，往往因為網絡原因或者人為原因等導致文件傳輸失敗。傳輸文件時，一般系統會先將原有文件清除掉，再傳輸新的文件，如果這時文件傳輸失敗，已經傳輸的文件可能只是整個文件的一部分。因為是部分文件，無法再進行使用，但是原有的文件已經被清除，從而出現文件丟失的問題。

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

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

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

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

圖8 文件恢復流程Fig.8 File recovery process

3.3.3 遠程維護的設計

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

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

圖9 遠程維護流程Fig.9 Remote maintenance process

4 系統實驗與結果分析

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

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

為了更直觀的對比上述兩者，將二者傳輸花費的時長以折線圖的形式展現，具體結果如圖10所示。可以計算得出，在低帶寬環境下，系統比SCP在性能上提高了大約52%，由此可見適應不同網絡的增量式傳輸算法對低帶寬環境的文件分發性能的提高起到了一定作用。

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

5 結語

本文研究適應不同網絡的增量式傳輸算法在低帶寬、高延遲的網絡條件下對傳輸性能的影響，通過實驗證明該方法可以較好地解決低帶寬的問題。通過研究文件分發系統針對實際問題的設計、對文件傳輸性能以及文件傳輸安全性的影響，經過實際項目的測試，發現版本校驗、文件備份與恢復、遠程維護的設計可以保證傳輸安全性與傳輸性能。