面向多應用的文件同步方法

曾　珊　周　薇　韓冀中

1(中國科學院信息工程研究所信息智能處理技術研究室　北京 100093)2(中國科學院大學　北京 100049)

?

面向多應用的文件同步方法

曾珊1,2周薇1,2韓冀中1

1(中國科學院信息工程研究所信息智能處理技術研究室北京 100093)2(中國科學院大學北京 100049)

容災系統保證了核心數據的可用性和關鍵業務的持續性，而文件同步是容災系統的基礎。但在同一系統下多個應用的文件需要同步時，現有的同步算法沒有考慮應用間文件的關聯關系、應用啟動依賴關系和優先級關系以及應用產生的中間型文件和臨時文件，導致同步了大量重復文件，緊急應用的文件無法優先同步，不必要的同步文件占用了珍貴的網絡資源。針對此問題，提出了面向多應用的文件同步方法，通過對應用間文件去重，減少重復文件同步；利用優先級同步隊列保證文件同步的優先級，提出自適應優先級策略保證對中間文件和臨時文件的過濾。實驗結果表明，該策略在電網基礎平臺系統應用和分布式Hadoop生態系統應用上分別減少了同步過程中的文件傳輸數量6%和30%，系統的平均響應時間分別減少了16%和55%，過濾了文件數量40%，減少同步文件大小44%。

同步算法多應用文件去重優先級隊列自適應優先級

0　引　言

現階段軟件發展日新月異，為了保證業務的持續性和穩定性，文件同步被廣泛地應用在數據級容災技術中[1]。現有的文件同步分為全量式文件同步和增量式文件同步。全量式文件同步每次同步過程中，同步所有發生過修改的文件；而增量式文件同步只傳輸文件中發生變化的數據塊，大幅減少了同步過程中傳輸的數據量。

然而隨著軟件的快速發展，在容災過程中需要同步的文件是以應用的形式組織的。這些應用是協同開發但又相互獨立的，因而應用間的文件存在廣泛的關聯關系。現有的文件同步方法，無論是增量同步還是全量同步都是基于對比單個文件，而沒有考慮分散在多應用中的文件間的關聯關系[2]，導致同步了大量重復的文件。

容災過程中的文件同步，沒有考慮文件的優先級關系。在容災中，文件同步的目的是為了盡快地遷移應用，因此緊急應用應該得到優先同步，被其他應用所依賴的應用應該優先同步[3]。現有的文件同步方式并未對此加以研究，對文件夾中的文件并不區分優先級，應用只能在所有文件同步完成后才能啟動。

容災過程中的文件同步沒有過濾非必需的文件。在容災中，文件同步的目的是同步必需的文件。應用在運行時會產生大量的中間型文件，這些中間型文件是應用產生的數據緩存文件或者修改的臨時文件，同步這些數據不但降低了同步的效率，也會影響最終同步的效果[4]。現有的同步算法，無論是全量同步還是增量同步都沒有對這一類型的文件加以過濾。大量非必要的文件同步不但占用了網絡帶寬，同時降低了系統同步的效率。

基于以上問題，本文提出面向多應用的文件同步策略。結合多應用相互關聯的特點，通過尋找文件間的重復項，對多應用間文件去重，減少了文件的傳輸大小，節約了網絡帶寬。為了保證應用盡快啟動，通過建立多優先級隊列的數學模型，優先同步應用認為最重要的文件，保證應用的啟動順序，本文進一步討論了應用數量與隊列個數的關系。為了減少非必要的文件同步，在優先級隊列的基礎上加入自適應優先級策略，對中間型文件延遲同步，對臨時文件不同步。當中間型文件修改為最終文件時按原有優先級同步，這樣既減少了不必要的同步，又保證了同步的優先級順序。

綜上所述，本文的貢獻如下：

(1) 結合多應用之間文件關聯的特點提出了應用間文件去重策略。通過去除應用間的重復文件項，在同步完成后利用記錄的文件信息恢復原有目錄，大量減少同步過程中需要傳輸的文件量。

(2) 針對多應用啟動依賴和緊急應用需要優先啟動的特點，提出了優先級同步方法。通過建立優先級隊列模型，按優先級順序同步文件，保證應用的啟動順序。

(3) 針對多應用產生的中間型文件，提出了自適應優先級策略。通過自適應調整優先級，延遲同步中間型文件，過濾臨時文件，既減少文件傳輸量，又保證了應用傳輸的優先級順序。

本文實現了面向多應用的文件同步系統，在國家電網基礎平臺系統環境[5]和Hadoop生態系統[6]下完成了實驗。實驗結果表明，本文文件去重策略在電網基礎平臺系統數據集上減少了約6%的文件傳輸量，在Hadoop數據集上減少了約30%的文件傳輸量，應用平均啟動時間在兩種數據集上分別縮短了16%和55%。根據文件修改的密集程度，中間文件實驗選擇電網基礎平臺系統數據集完成，同步文件總數量減少了約40%，同步文件大小約44%。

1　相關工作

現有的同步方法分為全量同步和增量同步[7]。全量同步會同步所有修改的文件。同步操作簡單，但缺點是同步量大。增量同步算法則通過對比需要同步的文件中數據塊的差異，只傳輸差異數據塊，從而大幅減少網絡傳輸量。

全量同步算法以SCP使用最為廣泛。王福陽等人將SCP與M+N結構融合，并將其巧妙地運用到容災系統中，取得了較好的穩定性。增量同步以Rsync使用最為廣泛[9,10]。何倩等人將快照和Rsync相結合，具有較好的快速恢復能力[9]。何騫等人通過改進Rsync算法，減少了網絡的同步量。張海峰等人利用Rsync對接多種異構環境，保障了容災的可用性。

除了上述兩種同步算法外，為了減少傳輸過程中的文件比較，充分利用網絡帶寬，先壓縮再同步的方法[10]也被應用在系統中，李貞改進Rsync算法，引入壓縮同步，最大限度地利用了網絡帶寬，同步時間非常短。缺點是如果文件數量很大，壓縮的預處理時間和同步后的恢復時間會占非常大的比例。

其他數據集文件容災方式，多以對特定情況改進傳輸協議，滿足容災系統的支持。Imak等人通過改進單輪通信協議為系統的數據級同步提供容災支撐[11]。

但上述的同步算法，都是針對單文件的同步方式，然而在同一系統的多應用中，應用相互協同工作，卻又相互獨立，會出現大量的重復文件[12]。比如應用A中包含了第三方的Java包，應用B為了實現相似的功能也同樣包含相同的第三方的Java包。兩種應用獨立開發，所以需要分別包含依賴的Java包。但同時傳輸兩份重復的Java包是非必需的。

同時在多應用的場景下，應用啟動時是有優先級順序的，取決于應用間的依賴關系和應用的緊急程度。為了盡快地使應用提供服務，應該優先同步優先級高的應用[13]。無論是增量同步還是全量同步都沒有考慮文件同步的優先級問題。

此外，多應用在運行時會產生大量的中間文件[14]，這些文件用來緩存數據或本身是臨時文件。增量同步和全量同步都沒有考慮過這個問題。

2　面向多應用的文件同步策略

文件同步已經廣泛應用到容災系統中。在面臨多應用的同步時，本文提出了一種面向多應用的文件同步方法。通過對應用間的文件去重，減少重復數據的傳輸；建立優先級同步隊列保證高優先級應用優先同步，利用自適應優先級策略保證對中間型文件的過濾。

2.1應用間文件去重

現有的增量同步算法在同步時，會利用滑動窗口方法來檢測文件的重復塊，極大地提高了數據同步的效率。但在多應用系統的環境下，應用間關聯度大，仍然同步了較多重復的文件。如在常見的Hadoop生態應用中[6]，以Hadoop-1.2.1和HBase-0.94.17為例，雖然是兩套完全不同的程序，但常配套使用為外界提供分布式存儲服務，屬于本文所說同一系統下的多應用。共包含50～60個Java依賴包，其中23個依賴包相同。現有的全量同步或增量同步會同步上述所有文件，實際上，在本例中就有20%的數據是無需同步的。這樣在應用間存在的重復數據需要去重。這些數據不能合并，因為系統應用獨立性很強，需要在依賴庫中獨立包含上述依賴庫文件。

為此，本文挖掘多應用間文件的關聯關系，對應用間的文件進行快速去重。在同步過程中，只需要同步去重后剩余的文件。待同步完成后，再利用文件原有信息恢復原有的目錄結構。

(1) 去重

去重的目的是為了最大限度地減少同步過程中的傳輸量，但又不能過多地占用同步的時間，應該盡可能快地完成去重功能。通過快速檢測文件內容、文件大小以及文件的元數據信息來檢測相同的文件，刪除重復數據[15]。同時，這些過濾得到的文件信息可以在后續恢復過程中加以使用。

一種較為可靠的方法是在同步目錄上建立虛擬目錄。其過程是在原目錄的基礎上，去掉重復項后生成帶有內部指向的虛擬目錄結構。建立過程如圖1所示，通過讀取不同應用的文件夾，分析文件大小、內容以及相關的元數據信息，將這些值加入到映射表中用來對文件作重復比對，實現快速的文件重復過濾。可以利用哈希映射的方法或者布隆過濾的方法加快去重的過程[16]。

圖1　虛擬目錄建立

(2) 恢復

完成同步以后，重復文件還處于被刪除的狀態，需要根據同步的文件信息對文件進行恢復。可通過同步過程中攜帶的元數據信息，在每個文件同步完成后，直接恢復原有的文件狀態。也可以在整個同步過程完成后，根據目錄的組織形式，批量恢復原有的文件。恢復過程如圖2所示，完成原始目錄的重建。本地復制的速度遠遠高于網絡傳輸，所以整體傳輸時間會優于原有的文件同步方式。

圖2　目錄復原

2.2優先級同步

在現有的文件同步過程中，所有文件同步的優先級是相同的。但是在多應用的系統中，應用在啟動上存在優先級順序，或存在啟動的相互依賴關系。以最常見的Hadoop生態系統應用為例，HBase需要HDFS和Zookeeper啟動后方能啟動，存在強烈的依賴關系，這是系統中多應用協同運行不可避免的情況[17]。為了使同步后應用平均啟動時間最短，應該按照優先級高低順序同步文件。而現有的同步方式，無論是增量同步或全量同步在同步時不區分優先級，對文件夾內的所有文件同等優先級同步，使得優先級高的應用反而可能在優先級低的應用之后才同步，造成系統的平均響應時間增加[18]。為此，本節描述基于多優先級隊列的同步模型。

(1) 文件類型檢測

各種應用的優先級順序是不同的，應用內文件的優先級也不一致。應用A可能對依賴文件的優先級高，應用B可能對可執行文件的優先級要求高。所以在加入優先級隊列之前，需要對文件進行分類，并根據相應的需求確定應用和文件的優先級順序。應用程序正常啟動過程包括尋找依賴文件、讀取啟動必需依賴數據(包括配置文件及其他依賴數據)兩個過程[19]。因此從啟動過程來看，可以將文件細分成四種類別，即依賴庫文件、可執行文件、數據依賴文件、其他文件，如圖3所示。

圖3　文件類型檢測

(2) 優先級同步

根據用戶定義的優先層次和優先次序，將文件加入優先列表。

同步過程中，優先級高的隊列先同步，待高優先級隊列完成了一輪傳輸后，優先級低的隊列開始傳輸。如果在傳輸過程中，高優先級隊列有新修改的文件加入，需要等待低優先級隊列的當前文件傳輸完成后再傳輸。原因是為了保證應用的啟動時間最短，必須要使依賴程度高的應用優先占用帶寬，最大限度地減少該應用在同步過程中消耗的時間。優先級同步隊列的過程如圖4所示。

圖4　優先級同步隊列

(3) 優先級隊列拓展

為了最大限度地利用帶寬拓展優先級隊列，根據文件分類數可將優先級隊列拓展為4級優先級隊列。在4級優先級隊列中，以高優先級隊列為例，將其分為A1隊列和A2隊列。在隊列內部優先加入A1隊列，如果A1隊列中存在了相同應用的文件，應加入A2優先級隊列。在傳輸時， A1和A2隊列依次交替同步。拓展的優點是能夠將同一應用的同步文件盡可能地提前，保證同一應用的修改盡可能先后同步。圖5顯示了如何由兩級隊列變為四級隊列。

圖5　優先級隊列拓展

為了分析優先級隊列拓展后對優先級同步性能的影響，選用隊列模型來計算兩種優先級隊列中單應用的等待時間，比較優先級拓展對應用等待時間的影響。

前提需要同步的文件到達時相互獨立，服從泊松分布；網絡帶寬是穩定的；緊急應用的文件需要獨占帶寬，才能保證優先達到。

假設文件同步到達速率為r；應用總個數為M；兩級優先級隊列中，高優先級文件到達速率為r1，低優先級為r2；高優先級和低優先級需要同步的文件比例是a，網絡傳輸速率為s。

結論1四級優先隊列中，到達速率與兩級相同，那么高優先級隊列中A1和A2的速率是r1/2，低優先級隊列中B1和B2的速率是r2/2，所以每個優先級隊列的傳輸速率是1/(2s) 。

結論2本文的隊列模型符合M/D/1排隊模型[20]。

根據結論2，利用排隊模型的公式，計算得到對于高優先級文件在隊列中的平均等候時間是正在等候的高優先級的等待時間，以及接受傳輸的剩余時間：

(1)

由式(1)求解的結果可得平均等待時間：

(2)

根據Little公式[20]，平均等待長度：

L=r×W

(3)

由于高級優先隊列的速度是：

L=a×r

(4)

用式(4)替換式(2)中的r，得到平均等待長度是：

(5)

在四級等待隊列中，單個隊列A1傳輸速率是高優先級隊列整體傳輸速率的一半，即s4 = s/2；r4 = r/2，隊列的速率也是原有隊列的一半。代入式(5)得到 ：

(6)

應用個數是M，應用修改的事件相互獨立，那么應用文件屬于同一類別的概率是C=1/M，則雙優先級隊列應用的到達時間是：

T=M/L×W

(7)

四優先級隊列的等待時間是：

T4=2/L4×W

(8)

結論3根據式(6)可知，在持續同步的環境下，兩種隊列的等待長度相同。

結論4根據式(2)可知，四級優先隊列單個隊列速率慢一半，所以四級優先級隊列單個隊列平均等待時間長一倍。

結論5根據式(7)和式(8)，如果M=2時，兩種隊列單應用等待時間相同。如果M>2，那么四級優先級隊列單應用等待時間少。

2.3自適應優先級調整

定義1可用版本是指應用某一時刻內所有文件能夠協同配合，正常滿足服務的需求。如某文件能在該應用中正常使用，本文稱該文件為應用的可用版本，反之稱該文件為應用的不可用版本。

在多應用的文件同步過程中，應用還存在大量中間型文件，中間型文件分為兩類：一種是文件A被修改為B狀態，但B狀態實質上是中間狀態，接著文件被修改保存為C狀態，C狀態是可用的版本。如果在處于B狀態時發生了異常，那么該應用即使完成了實時同步，應用在同步的另一側也是無法使用的[21]。第二種中間型文件是傳統意義上的臨時文件，是應用運行時產生的帶有明顯標示如.swap、～A的臨時文件。這些文件只用來緩存中間數據，沒有必要同步，同步中需要加以過濾[22]。在現有的同步算法中，對第一種臨時文件并未加以過濾，而仍然同步，很容易造成應用無法啟動，只能通過人工干預處理應用的錯誤。對第二種臨時文件，所有的增量同步同樣會傳輸，即使這樣的傳輸完全是沒有必要的，甚至反過來還需要一些人工干預來刪除這些臨時的中間文件[23]。

為了解決臨時文件的問題，本文在優先級隊列的基礎上加入了自適應優先級的策略，中間文件延遲同步，臨時文件不同步。當中間文件修改為最終文件后，仍然按照原有的優先級順序同步。既減少了不必要的同步，又保證了同步的優先級順序。如圖6所示，當檢測到文件變為中間文件時(通過檢測到臨時文件的產生)，需要動態調整優先級的順序，高優先級的文件應該延緩傳輸，將文件加入到低優先級隊列中。如果文件檢測到合并，那么需要根據原有文件的優先級調整到對應的優先級列表中。這樣，臨時文件沒有傳輸，同時中間文件也能有效地保存在傳輸隊列中。

圖6　自適應優先級調整

這樣既保證了文件傳輸的優先級順序，又能有效地過濾中間文件，減少傳輸。相比于傳統的同步方法，大量的臨時文件被過濾掉，減少了網絡中非必需的傳輸量，有利于提高同步系統的性能，同時又能保證文件原有的優先級順序。

3　實驗結果

為了驗證本文方法的性能，本文選取了Rsync作為增量同步算法代表，SCP作為全量同步算法代表，和壓縮以后同步的策略作為比較。并在電網場景下使用非常廣泛的基礎平臺系統和常用的基于Hadoop生態系統應用中進行了相應的同步實驗來說明本方法在性能上的優勢。實驗在4臺物理主機上進行。

為了保證真實性，本文選取了電網基礎平臺系統的啟動應用軟件和基于Hadoop生態系統軟件及其配套的應用程序[6]，來說明本算法的性能。兩種應用詳細情況如表1和表2所示。

表1　電網基礎平臺系統實驗環境

表2　Hadoop實驗環境

電網基礎平臺系統應用總文件大小33 GB，文件總數1 029 492，是電網環境下的基礎應用平臺，包含了4種主要應用：國產數據庫、電網數據交互程序、電網狀態分析程序、對外核心服務程序。基礎平臺系統應用的詳細信息如表3所示。

表3　電網基礎平臺系統實驗數據集

Hadoop生態系統軟件是基于Linux的分布式應用。Hadoop內部是分布式的，可在多物理機上執行，一般不存在遷移需求。當其需要遷移時，其應用需要跨集群間遷移。為了模擬遠程集群間遷移的網絡帶寬，本文將Hadoop實驗的網速限制在十兆以內。實驗環境如表2所示。

Hadoop生態系統應用軟件總大小1.4 GB，文件總數20 890，是常見的分布式生態環境，用來提供分布式服務。應用包括基礎系統Hadoop、全局數據配置Zookeeper、分布式數據庫HBase以及上層的其他應用Storm、Spark及定制的第三方程序。Hadoop生態系統應用的具體信息如表4所示。

表4　Hadoop系統實驗數據集

3.1應用間文件去重同步實驗

本文利用電網基礎平臺系統數據集和Hadoop應用數據集完成文件去重實驗。

圖7是電網基礎平臺系統數據集下的同步時間圖。橫坐標是算法，縱坐標是同步時間。各算法內部分為三部分：預處理時間、傳輸時間、恢復時間。縱坐標均以秒為單位。

圖7　電網基礎平臺系統應用數據集下各算法同步時間

圖8是各個算法在Hadoop數據集下的同步時間圖。橫坐標是算法，縱坐標是同步時間。各算法內部分為三部分：預處理時間、傳輸時間、恢復時間。縱坐標均以秒為單位。

圖8　Hadoop同步時間圖

本文算法通過快速發現多應用間的重復項，能大量減少應用傳輸過程中的文件總量。如果多應用間重復數據不大，那么本文策略與Rsync算法相差不大，可見于圖7的結果只減少了6%的時間，甚至極端情況下出現時間與Rsync無差別的情況。如果多應用間存在較多的重復項，那么本文算法能有效地提高傳輸效率，大大降低同步的時間，可見于圖8的結果減少了30%的總時間。

3.2優先級同步實驗

電網基礎平臺系統應用包括國產數據庫(后文簡稱DM數據庫)，提供關系型數據庫服務；數據交互應用CM(Commutating Program)，收集電網中的監控數據和告警數據存入國產數據庫中；電網數據分析應用CP(Collecting and Analyzing Program)，分析數據庫中的監控數據和告警數據，并對電網下一刻狀態進行估計；系統核心對外服務程序SP(Service Program)是向外部提供數據通信接口的應用。應用間相互獨立，但又需要協同工作，存在明顯的啟動先后順序。國產數據庫需要優先啟動提供服務，然后數據交互和數據分析才能啟動；待上述應用全部啟動完成，最后再啟動對外的核心服務程序。應用的平均啟動時間為3秒。

因其他算法無優先級，都需要全部同步完成后啟動應用，下表列出所需同步文件大小及完成同步時間。

圖9是電網基礎平臺系統應用優先級同步時間圖。橫坐標是對應的基礎平臺的四種應用，縱坐標是同步時間。縱坐標均以秒為單位。

圖9　電網基礎平臺系統數據集優先同步

Hadoop應用程序取自電網基礎云平臺，包括了Java開發環境，用來為整套系統提供HDFS分布式文件服務。HBase分為兩套，HBase使用0.90-17提供分布式數據存儲，定制HBase使用0.94.17為電網系統提供穩定存儲服務。Spark和Storm提供數據分析，Zookeeper管理全局文件和數據。第三方程序利用HBase中的數據，使用Spark加以分析，并存儲到HDFS中。應用啟動的優先級是首先啟動Hadoop和Zookeeper，然后啟動兩套HBase，接著啟動Storm和Spark，最后啟動第三方應用程序。應用的平均啟動時間為5秒。

圖10是Hadoop應用優先級同步時間圖。橫坐標是對應的Hadoop的八種應用，縱坐標是同步時間。縱坐標均以秒為單位。

圖10　Hadoop數據集優先級同步

本文算法通過利用優先級隊列，將重要文件集優先同步，發現均優于Rsync算法和SCP算法。本文算法平均啟動時間在電網基礎平臺系統數據集下優于Rsync算法約16%，優于SCP算法約56%；在Hadoop數據集下本算法比Rsync算法大約提高了55%的時間，比SCP提高了約58%的時間，大幅減少了應用的等待。一方面是因為虛擬目錄過濾帶來的時間優化，另一方面是基礎程序在其他程序傳輸過程中已經啟動。如電網基礎平臺系統中國產數據庫啟動就需要30秒的時間，而這30秒Rsync和SCP只能并行。在本文算法中，這部分時間同時在傳輸文件。本文算法針對多應用啟動的同步性能較好。

3.3中間文件過濾

中間文件主要是在實時同步過程中，程序發生的實時修改，如對本地文件的修改和對數據文件的修改。在Hadoop應用中這樣的修改較少，在電網基礎平臺系統中，因為分析程序需要修改數據文件，緩存中間文件，導致這樣的修改過程非常多。取10分鐘時間段，發現基礎平臺系統應用的修改主要集中在配置文件和數據文件。批量在配置文件中修改224個文件，總大小3.2 MB，產生中間臨時文件224個，臨時文件平均大小17 KB，添加166個數據文件，總大小2.8 MB。

圖11是各個算法的對中間文件過濾同步圖。橫坐標是對應的三種算法，左側縱坐標對應文件大小，單位是MB。右側縱坐標對應同步的文件數量，單位是個。

圖11　中間文件過濾同步時間圖

本文通過對中間文件的過濾，大幅減少了中間文件的傳輸。文件數量只有Rsync和SCP算法的60%，文件大小約只有Rsync的56%和SCP的45%。在實時同步的過程中，大量的臨時文件不但占用了帶寬，也影響了同步的效率。本文算法通過動態調整優先級大量減少了同步的文件數量和文件大小。

4　結　語

本文針對多應用的場景，結合多應用的特點，發掘應用間的文件關聯關系，對應用間的文件去重后同步，大幅減少了同步過程中的文件大小和同步時間。結合應用啟動的目的，本文通過建立優先級隊列，討論優先級隊列模型保證了應用的平均啟動時間最短。結合應用修改的特點，本文提出了自適應優先級策略，動態調整同步文件的優先級，延遲中間型文件的同步，過濾臨時文件的同步，大幅減少了同步的文件總量。本文成功設計和實現了面向多應用的文件同步系統，并在電網基礎平臺系統應用和Hadoop應用中實驗。實驗結果表明，本文提出的方法優于常規的全量同步和增量同步方法，具有很高的實用價值。

[1] 李焱.備份與容災在企業信息化建設中的應用[J].信息系統工程,2014(12):116-118,137.

[2] Andrew Tridgell.Effieient Algotithms for Sorting and Synchronization[D].Canberra:The Australian National University,1999.

[3] 蘇冠群,陶宏才.基于Linux平臺的遠程數據容災系統的設計與實現[J].計算機應用,2012,32(7):2056-2058.

[4] Susalar S,Carter J.Flexible Consistency for wide area peer Replication[C]//Proceedings of 25th IEEE International Conference on Distributed Computing Systems,Columbus,USA,2005:199-208.

[5] 佟強,肖翔.D5000系統在浙江電網的應用分析[C]//2013年中國電機工程學會年會論文集.北京:中國電機工程學會,2013.

[6] 懷特.Hadoop權威指南[M].曾大聃,等譯.北京:清華大學出版社,2010.

[7] 王福陽,李小堅,俞前.基于M+N結構的SCP容災系統設計[J].計算機工程,2008,34(11):252-254,282.[8] 何倩,趙幫,王勇,等.基于本地快照和Rsync算法的Web文件保護[J].計算機工程,2013,39(6):190-193,199.

[9] 何騫,卓碧華.一種遠程文件同步方法[J].計算機應用,2012,32(2):566-568.

[10] 李貞.基于Rsync算法的遠程文件同步系統的設計與實現[D].北京:北京郵電大學,2010.

[11] Irmak U,Mihaylov S,Suel T.Improved single-round protocols for remote file synchronization[C]//Proceedings of 24th Annual Joint Conference of the IEEE Computer and Communications Societies,USA,2005,3:1665-1676.

[12] 李征,張棟良.一種基于rsync的改進文件同步算法[J].通信市場,2009(3):78-82.

[13] 張海峰,張耀南,張寶山.異構環境下數據文件Rsync同步機制研究[J].計算機與現代化,2009(10):78-81,85.

[14] 張海峰.基于Rsync的異構環境數據同步機制研究[D].成都:電子科技大學,2009.

[15] 陸游游,敖莉,舒繼武.一種基于重復數據刪除的備份系統[J].計算機研究與發展,2012,49(S1):206-210.

[16] 袁志堅,陳穎文,繆嘉嘉,等.典型Bloom過濾器的研究及其數據流應用[J].計算機工程,2009,35(7):5-7.

[17] 段中興,趙煌.反饋控制的優先級隊列公平調度算法[J].西安建筑科技大學學報:自然科學版,2003,35(4):390-393.

[18] 李周志,王曉東,王真之,等.基于多優先級緩存隊列的遠程數據傳輸技術[J].計算機工程,2010,36(18):105-108.

[19] 毛翠.遠程文件同步算法研究和應用[D].成都:電子科技大學,2011.

[20] 王宏久.系統容量有限的一類排隊論模型的計算機模擬研究[D].哈爾濱:哈爾濱工業大學,2007.

[21] 劉西崗.基于rsync算法的云平臺文件同步系統設計與實現[D].四川:電子科技大學,2013.

[22] 任燕博,劉釗遠.基于RSYNC遠程同步系統的優化[J].計算機與數字工程,2014,42(6):1007-1010.

[23] 蘇冠群,陶宏才.基于Linux平臺的遠程數據容災系統的設計與實現[J].計算機應用,2012,32(7):2056-2058.

FILE SYNCHRONISATION STRATEGY FOR MULTI-APPLICATIONS

Zeng Shan1,2Zhou Wei1,2Han Jizhong1

1(LaboratoryofIntelligentInformationProcessingTechnology,InstituteofInformationEngineering,ChineseAcademyofSciences,Beijing100093,China)2(UniversityofChineseAcademyofSciences,Beijing100049,China)

The disaster recovery system guarantees the usability of core data and the durative of key services, and the file synchronisation is the basis of the disaster recovery system. However, while the files of multi-application in same system need to be synchronised, existing synchronisation algorithm does not take into account the association relationship of files between applications, the application start-up dependencies relationship and priority relation, as well as the intermediate files and temporary files generated by the applications, this results in synchronisation of a large amount of duplicate files, the files of emergent application cannot be synchronised with priority, the unnecessary synchronisation files take up valuable network resources. Aiming at this problem, the paper puts forward a multiple applications-oriented file synchronisation strategy. It reduces the synchronisation of duplicate files by applying deduplication on files between applications, guarantees the priority of file synchronisation by using priority synchronous queue, and proposes an adaptive priority strategy to ensure the filtration of intermediate files and temporary files. Experimental results show that the strategy reduces the number of files transfer by 6% and 30% in synchronisation processes of the application of basic monitoring platform system of state grid and the application of distributed Hadoop ecosystem system respectively, decreases the system average response time by 16% and 51% respectively, filters the unnecessary files quantity by 40%, and reduces the synchronous file size by 44%.

Synchronisation algorithmMulti-applicationFile deduplicationPriority queueAdaptive priority

2015-05-01。國家高技術研究發展計劃基金項目(20 12AA01A401)。曾珊，碩士生，主研領域：大數據處理。周薇，博士生。韓冀中，教授。

TP3

A

10.3969/j.issn.1000-386x.2016.10.066