曾　珊　周　薇　韓冀中

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

?

面向多應(yīng)用的文件同步方法

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

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

容災(zāi)系統(tǒng)保證了核心數(shù)據(jù)的可用性和關(guān)鍵業(yè)務(wù)的持續(xù)性，而文件同步是容災(zāi)系統(tǒng)的基礎(chǔ)。但在同一系統(tǒng)下多個(gè)應(yīng)用的文件需要同步時(shí)，現(xiàn)有的同步算法沒(méi)有考慮應(yīng)用間文件的關(guān)聯(lián)關(guān)系、應(yīng)用啟動(dòng)依賴關(guān)系和優(yōu)先級(jí)關(guān)系以及應(yīng)用產(chǎn)生的中間型文件和臨時(shí)文件，導(dǎo)致同步了大量重復(fù)文件，緊急應(yīng)用的文件無(wú)法優(yōu)先同步，不必要的同步文件占用了珍貴的網(wǎng)絡(luò)資源。針對(duì)此問(wèn)題，提出了面向多應(yīng)用的文件同步方法，通過(guò)對(duì)應(yīng)用間文件去重，減少重復(fù)文件同步；利用優(yōu)先級(jí)同步隊(duì)列保證文件同步的優(yōu)先級(jí)，提出自適應(yīng)優(yōu)先級(jí)策略保證對(duì)中間文件和臨時(shí)文件的過(guò)濾。實(shí)驗(yàn)結(jié)果表明，該策略在電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)應(yīng)用和分布式Hadoop生態(tài)系統(tǒng)應(yīng)用上分別減少了同步過(guò)程中的文件傳輸數(shù)量6%和30%，系統(tǒng)的平均響應(yīng)時(shí)間分別減少了16%和55%，過(guò)濾了文件數(shù)量40%，減少同步文件大小44%。

同步算法多應(yīng)用文件去重優(yōu)先級(jí)隊(duì)列自適應(yīng)優(yōu)先級(jí)

0　引　言

現(xiàn)階段軟件發(fā)展日新月異，為了保證業(yè)務(wù)的持續(xù)性和穩(wěn)定性，文件同步被廣泛地應(yīng)用在數(shù)據(jù)級(jí)容災(zāi)技術(shù)中[1]。現(xiàn)有的文件同步分為全量式文件同步和增量式文件同步。全量式文件同步每次同步過(guò)程中，同步所有發(fā)生過(guò)修改的文件；而增量式文件同步只傳輸文件中發(fā)生變化的數(shù)據(jù)塊，大幅減少了同步過(guò)程中傳輸?shù)臄?shù)據(jù)量。

然而隨著軟件的快速發(fā)展，在容災(zāi)過(guò)程中需要同步的文件是以應(yīng)用的形式組織的。這些應(yīng)用是協(xié)同開發(fā)但又相互獨(dú)立的，因而應(yīng)用間的文件存在廣泛的關(guān)聯(lián)關(guān)系?，F(xiàn)有的文件同步方法，無(wú)論是增量同步還是全量同步都是基于對(duì)比單個(gè)文件，而沒(méi)有考慮分散在多應(yīng)用中的文件間的關(guān)聯(lián)關(guān)系[2]，導(dǎo)致同步了大量重復(fù)的文件。

容災(zāi)過(guò)程中的文件同步，沒(méi)有考慮文件的優(yōu)先級(jí)關(guān)系。在容災(zāi)中，文件同步的目的是為了盡快地遷移應(yīng)用，因此緊急應(yīng)用應(yīng)該得到優(yōu)先同步，被其他應(yīng)用所依賴的應(yīng)用應(yīng)該優(yōu)先同步[3]。現(xiàn)有的文件同步方式并未對(duì)此加以研究，對(duì)文件夾中的文件并不區(qū)分優(yōu)先級(jí)，應(yīng)用只能在所有文件同步完成后才能啟動(dòng)。

容災(zāi)過(guò)程中的文件同步?jīng)]有過(guò)濾非必需的文件。在容災(zāi)中，文件同步的目的是同步必需的文件。應(yīng)用在運(yùn)行時(shí)會(huì)產(chǎn)生大量的中間型文件，這些中間型文件是應(yīng)用產(chǎn)生的數(shù)據(jù)緩存文件或者修改的臨時(shí)文件，同步這些數(shù)據(jù)不但降低了同步的效率，也會(huì)影響最終同步的效果[4]?，F(xiàn)有的同步算法，無(wú)論是全量同步還是增量同步都沒(méi)有對(duì)這一類型的文件加以過(guò)濾。大量非必要的文件同步不但占用了網(wǎng)絡(luò)帶寬，同時(shí)降低了系統(tǒng)同步的效率。

基于以上問(wèn)題，本文提出面向多應(yīng)用的文件同步策略。結(jié)合多應(yīng)用相互關(guān)聯(lián)的特點(diǎn)，通過(guò)尋找文件間的重復(fù)項(xiàng)，對(duì)多應(yīng)用間文件去重，減少了文件的傳輸大小，節(jié)約了網(wǎng)絡(luò)帶寬。為了保證應(yīng)用盡快啟動(dòng)，通過(guò)建立多優(yōu)先級(jí)隊(duì)列的數(shù)學(xué)模型，優(yōu)先同步應(yīng)用認(rèn)為最重要的文件，保證應(yīng)用的啟動(dòng)順序，本文進(jìn)一步討論了應(yīng)用數(shù)量與隊(duì)列個(gè)數(shù)的關(guān)系。為了減少非必要的文件同步，在優(yōu)先級(jí)隊(duì)列的基礎(chǔ)上加入自適應(yīng)優(yōu)先級(jí)策略，對(duì)中間型文件延遲同步，對(duì)臨時(shí)文件不同步。當(dāng)中間型文件修改為最終文件時(shí)按原有優(yōu)先級(jí)同步，這樣既減少了不必要的同步，又保證了同步的優(yōu)先級(jí)順序。

綜上所述，本文的貢獻(xiàn)如下：

(1) 結(jié)合多應(yīng)用之間文件關(guān)聯(lián)的特點(diǎn)提出了應(yīng)用間文件去重策略。通過(guò)去除應(yīng)用間的重復(fù)文件項(xiàng)，在同步完成后利用記錄的文件信息恢復(fù)原有目錄，大量減少同步過(guò)程中需要傳輸?shù)奈募俊?/p>

(2) 針對(duì)多應(yīng)用啟動(dòng)依賴和緊急應(yīng)用需要優(yōu)先啟動(dòng)的特點(diǎn)，提出了優(yōu)先級(jí)同步方法。通過(guò)建立優(yōu)先級(jí)隊(duì)列模型，按優(yōu)先級(jí)順序同步文件，保證應(yīng)用的啟動(dòng)順序。

(3) 針對(duì)多應(yīng)用產(chǎn)生的中間型文件，提出了自適應(yīng)優(yōu)先級(jí)策略。通過(guò)自適應(yīng)調(diào)整優(yōu)先級(jí)，延遲同步中間型文件，過(guò)濾臨時(shí)文件，既減少文件傳輸量，又保證了應(yīng)用傳輸?shù)膬?yōu)先級(jí)順序。

本文實(shí)現(xiàn)了面向多應(yīng)用的文件同步系統(tǒng)，在國(guó)家電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)環(huán)境[5]和Hadoop生態(tài)系統(tǒng)[6]下完成了實(shí)驗(yàn)。實(shí)驗(yàn)結(jié)果表明，本文文件去重策略在電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)數(shù)據(jù)集上減少了約6%的文件傳輸量，在Hadoop數(shù)據(jù)集上減少了約30%的文件傳輸量，應(yīng)用平均啟動(dòng)時(shí)間在兩種數(shù)據(jù)集上分別縮短了16%和55%。根據(jù)文件修改的密集程度，中間文件實(shí)驗(yàn)選擇電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)數(shù)據(jù)集完成，同步文件總數(shù)量減少了約40%，同步文件大小約44%。

1　相關(guān)工作

現(xiàn)有的同步方法分為全量同步和增量同步[7]。全量同步會(huì)同步所有修改的文件。同步操作簡(jiǎn)單，但缺點(diǎn)是同步量大。增量同步算法則通過(guò)對(duì)比需要同步的文件中數(shù)據(jù)塊的差異，只傳輸差異數(shù)據(jù)塊，從而大幅減少網(wǎng)絡(luò)傳輸量。

全量同步算法以SCP使用最為廣泛。王福陽(yáng)等人將SCP與M+N結(jié)構(gòu)融合，并將其巧妙地運(yùn)用到容災(zāi)系統(tǒng)中，取得了較好的穩(wěn)定性。增量同步以Rsync使用最為廣泛[9,10]。何倩等人將快照和Rsync相結(jié)合，具有較好的快速恢復(fù)能力[9]。何騫等人通過(guò)改進(jìn)Rsync算法，減少了網(wǎng)絡(luò)的同步量。張海峰等人利用Rsync對(duì)接多種異構(gòu)環(huán)境，保障了容災(zāi)的可用性。

除了上述兩種同步算法外，為了減少傳輸過(guò)程中的文件比較，充分利用網(wǎng)絡(luò)帶寬，先壓縮再同步的方法[10]也被應(yīng)用在系統(tǒng)中，李貞改進(jìn)Rsync算法，引入壓縮同步，最大限度地利用了網(wǎng)絡(luò)帶寬，同步時(shí)間非常短。缺點(diǎn)是如果文件數(shù)量很大，壓縮的預(yù)處理時(shí)間和同步后的恢復(fù)時(shí)間會(huì)占非常大的比例。

其他數(shù)據(jù)集文件容災(zāi)方式，多以對(duì)特定情況改進(jìn)傳輸協(xié)議，滿足容災(zāi)系統(tǒng)的支持。Imak等人通過(guò)改進(jìn)單輪通信協(xié)議為系統(tǒng)的數(shù)據(jù)級(jí)同步提供容災(zāi)支撐[11]。

但上述的同步算法，都是針對(duì)單文件的同步方式，然而在同一系統(tǒng)的多應(yīng)用中，應(yīng)用相互協(xié)同工作，卻又相互獨(dú)立，會(huì)出現(xiàn)大量的重復(fù)文件[12]。比如應(yīng)用A中包含了第三方的Java包，應(yīng)用B為了實(shí)現(xiàn)相似的功能也同樣包含相同的第三方的Java包。兩種應(yīng)用獨(dú)立開發(fā)，所以需要分別包含依賴的Java包。但同時(shí)傳輸兩份重復(fù)的Java包是非必需的。

同時(shí)在多應(yīng)用的場(chǎng)景下，應(yīng)用啟動(dòng)時(shí)是有優(yōu)先級(jí)順序的，取決于應(yīng)用間的依賴關(guān)系和應(yīng)用的緊急程度。為了盡快地使應(yīng)用提供服務(wù)，應(yīng)該優(yōu)先同步優(yōu)先級(jí)高的應(yīng)用[13]。無(wú)論是增量同步還是全量同步都沒(méi)有考慮文件同步的優(yōu)先級(jí)問(wèn)題。

此外，多應(yīng)用在運(yùn)行時(shí)會(huì)產(chǎn)生大量的中間文件[14]，這些文件用來(lái)緩存數(shù)據(jù)或本身是臨時(shí)文件。增量同步和全量同步都沒(méi)有考慮過(guò)這個(gè)問(wèn)題。

2　面向多應(yīng)用的文件同步策略

文件同步已經(jīng)廣泛應(yīng)用到容災(zāi)系統(tǒng)中。在面臨多應(yīng)用的同步時(shí)，本文提出了一種面向多應(yīng)用的文件同步方法。通過(guò)對(duì)應(yīng)用間的文件去重，減少重復(fù)數(shù)據(jù)的傳輸；建立優(yōu)先級(jí)同步隊(duì)列保證高優(yōu)先級(jí)應(yīng)用優(yōu)先同步，利用自適應(yīng)優(yōu)先級(jí)策略保證對(duì)中間型文件的過(guò)濾。

2.1應(yīng)用間文件去重

現(xiàn)有的增量同步算法在同步時(shí)，會(huì)利用滑動(dòng)窗口方法來(lái)檢測(cè)文件的重復(fù)塊，極大地提高了數(shù)據(jù)同步的效率。但在多應(yīng)用系統(tǒng)的環(huán)境下，應(yīng)用間關(guān)聯(lián)度大，仍然同步了較多重復(fù)的文件。如在常見(jiàn)的Hadoop生態(tài)應(yīng)用中[6]，以Hadoop-1.2.1和HBase-0.94.17為例，雖然是兩套完全不同的程序，但常配套使用為外界提供分布式存儲(chǔ)服務(wù)，屬于本文所說(shuō)同一系統(tǒng)下的多應(yīng)用。共包含50～60個(gè)Java依賴包，其中23個(gè)依賴包相同?，F(xiàn)有的全量同步或增量同步會(huì)同步上述所有文件，實(shí)際上，在本例中就有20%的數(shù)據(jù)是無(wú)需同步的。這樣在應(yīng)用間存在的重復(fù)數(shù)據(jù)需要去重。這些數(shù)據(jù)不能合并，因?yàn)橄到y(tǒng)應(yīng)用獨(dú)立性很強(qiáng)，需要在依賴庫(kù)中獨(dú)立包含上述依賴庫(kù)文件。

為此，本文挖掘多應(yīng)用間文件的關(guān)聯(lián)關(guān)系，對(duì)應(yīng)用間的文件進(jìn)行快速去重。在同步過(guò)程中，只需要同步去重后剩余的文件。待同步完成后，再利用文件原有信息恢復(fù)原有的目錄結(jié)構(gòu)。

(1) 去重

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

一種較為可靠的方法是在同步目錄上建立虛擬目錄。其過(guò)程是在原目錄的基礎(chǔ)上，去掉重復(fù)項(xiàng)后生成帶有內(nèi)部指向的虛擬目錄結(jié)構(gòu)。建立過(guò)程如圖1所示，通過(guò)讀取不同應(yīng)用的文件夾，分析文件大小、內(nèi)容以及相關(guān)的元數(shù)據(jù)信息，將這些值加入到映射表中用來(lái)對(duì)文件作重復(fù)比對(duì)，實(shí)現(xiàn)快速的文件重復(fù)過(guò)濾?？梢岳霉Ｓ成涞姆椒ɑ蛘卟悸∵^(guò)濾的方法加快去重的過(guò)程[16]。

圖1　虛擬目錄建立

(2) 恢復(fù)

完成同步以后，重復(fù)文件還處于被刪除的狀態(tài)，需要根據(jù)同步的文件信息對(duì)文件進(jìn)行恢復(fù)?？赏ㄟ^(guò)同步過(guò)程中攜帶的元數(shù)據(jù)信息，在每個(gè)文件同步完成后，直接恢復(fù)原有的文件狀態(tài)。也可以在整個(gè)同步過(guò)程完成后，根據(jù)目錄的組織形式，批量恢復(fù)原有的文件。恢復(fù)過(guò)程如圖2所示，完成原始目錄的重建。本地復(fù)制的速度遠(yuǎn)遠(yuǎn)高于網(wǎng)絡(luò)傳輸，所以整體傳輸時(shí)間會(huì)優(yōu)于原有的文件同步方式。

圖2　目錄復(fù)原

2.2優(yōu)先級(jí)同步

在現(xiàn)有的文件同步過(guò)程中，所有文件同步的優(yōu)先級(jí)是相同的。但是在多應(yīng)用的系統(tǒng)中，應(yīng)用在啟動(dòng)上存在優(yōu)先級(jí)順序，或存在啟動(dòng)的相互依賴關(guān)系。以最常見(jiàn)的Hadoop生態(tài)系統(tǒng)應(yīng)用為例，HBase需要HDFS和Zookeeper啟動(dòng)后方能啟動(dòng)，存在強(qiáng)烈的依賴關(guān)系，這是系統(tǒng)中多應(yīng)用協(xié)同運(yùn)行不可避免的情況[17]。為了使同步后應(yīng)用平均啟動(dòng)時(shí)間最短，應(yīng)該按照優(yōu)先級(jí)高低順序同步文件。而現(xiàn)有的同步方式，無(wú)論是增量同步或全量同步在同步時(shí)不區(qū)分優(yōu)先級(jí)，對(duì)文件夾內(nèi)的所有文件同等優(yōu)先級(jí)同步，使得優(yōu)先級(jí)高的應(yīng)用反而可能在優(yōu)先級(jí)低的應(yīng)用之后才同步，造成系統(tǒng)的平均響應(yīng)時(shí)間增加[18]。為此，本節(jié)描述基于多優(yōu)先級(jí)隊(duì)列的同步模型。

(1) 文件類型檢測(cè)

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

圖3　文件類型檢測(cè)

(2) 優(yōu)先級(jí)同步

根據(jù)用戶定義的優(yōu)先層次和優(yōu)先次序，將文件加入優(yōu)先列表。

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

圖4　優(yōu)先級(jí)同步隊(duì)列

(3) 優(yōu)先級(jí)隊(duì)列拓展

為了最大限度地利用帶寬拓展優(yōu)先級(jí)隊(duì)列，根據(jù)文件分類數(shù)可將優(yōu)先級(jí)隊(duì)列拓展為4級(jí)優(yōu)先級(jí)隊(duì)列。在4級(jí)優(yōu)先級(jí)隊(duì)列中，以高優(yōu)先級(jí)隊(duì)列為例，將其分為A1隊(duì)列和A2隊(duì)列。在隊(duì)列內(nèi)部?jī)?yōu)先加入A1隊(duì)列，如果A1隊(duì)列中存在了相同應(yīng)用的文件，應(yīng)加入A2優(yōu)先級(jí)隊(duì)列。在傳輸時(shí)， A1和A2隊(duì)列依次交替同步。拓展的優(yōu)點(diǎn)是能夠?qū)⑼粦?yīng)用的同步文件盡可能地提前，保證同一應(yīng)用的修改盡可能先后同步。圖5顯示了如何由兩級(jí)隊(duì)列變?yōu)樗募?jí)隊(duì)列。

圖5　優(yōu)先級(jí)隊(duì)列拓展

為了分析優(yōu)先級(jí)隊(duì)列拓展后對(duì)優(yōu)先級(jí)同步性能的影響，選用隊(duì)列模型來(lái)計(jì)算兩種優(yōu)先級(jí)隊(duì)列中單應(yīng)用的等待時(shí)間，比較優(yōu)先級(jí)拓展對(duì)應(yīng)用等待時(shí)間的影響。

前提需要同步的文件到達(dá)時(shí)相互獨(dú)立，服從泊松分布；網(wǎng)絡(luò)帶寬是穩(wěn)定的；緊急應(yīng)用的文件需要獨(dú)占帶寬，才能保證優(yōu)先達(dá)到。

假設(shè)文件同步到達(dá)速率為r；應(yīng)用總個(gè)數(shù)為M；兩級(jí)優(yōu)先級(jí)隊(duì)列中，高優(yōu)先級(jí)文件到達(dá)速率為r1，低優(yōu)先級(jí)為r2；高優(yōu)先級(jí)和低優(yōu)先級(jí)需要同步的文件比例是a，網(wǎng)絡(luò)傳輸速率為s。

結(jié)論1四級(jí)優(yōu)先隊(duì)列中，到達(dá)速率與兩級(jí)相同，那么高優(yōu)先級(jí)隊(duì)列中A1和A2的速率是r1/2，低優(yōu)先級(jí)隊(duì)列中B1和B2的速率是r2/2，所以每個(gè)優(yōu)先級(jí)隊(duì)列的傳輸速率是1/(2s) 。

結(jié)論2本文的隊(duì)列模型符合M/D/1排隊(duì)模型[20]。

根據(jù)結(jié)論2，利用排隊(duì)模型的公式，計(jì)算得到對(duì)于高優(yōu)先級(jí)文件在隊(duì)列中的平均等候時(shí)間是正在等候的高優(yōu)先級(jí)的等待時(shí)間，以及接受傳輸?shù)氖Ｓ鄷r(shí)間：

(1)

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

(2)

根據(jù)Little公式[20]，平均等待長(zhǎng)度：

L=r×W

(3)

由于高級(jí)優(yōu)先隊(duì)列的速度是：

L=a×r

(4)

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

(5)

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

(6)

應(yīng)用個(gè)數(shù)是M，應(yīng)用修改的事件相互獨(dú)立，那么應(yīng)用文件屬于同一類別的概率是C=1/M，則雙優(yōu)先級(jí)隊(duì)列應(yīng)用的到達(dá)時(shí)間是：

T=M/L×W

(7)

四優(yōu)先級(jí)隊(duì)列的等待時(shí)間是：

T4=2/L4×W

(8)

結(jié)論3根據(jù)式(6)可知，在持續(xù)同步的環(huán)境下，兩種隊(duì)列的等待長(zhǎng)度相同。

結(jié)論4根據(jù)式(2)可知，四級(jí)優(yōu)先隊(duì)列單個(gè)隊(duì)列速率慢一半，所以四級(jí)優(yōu)先級(jí)隊(duì)列單個(gè)隊(duì)列平均等待時(shí)間長(zhǎng)一倍。

結(jié)論5根據(jù)式(7)和式(8)，如果M=2時(shí)，兩種隊(duì)列單應(yīng)用等待時(shí)間相同。如果M>2，那么四級(jí)優(yōu)先級(jí)隊(duì)列單應(yīng)用等待時(shí)間少。

2.3自適應(yīng)優(yōu)先級(jí)調(diào)整

定義1可用版本是指應(yīng)用某一時(shí)刻內(nèi)所有文件能夠協(xié)同配合，正常滿足服務(wù)的需求。如某文件能在該應(yīng)用中正常使用，本文稱該文件為應(yīng)用的可用版本，反之稱該文件為應(yīng)用的不可用版本。

在多應(yīng)用的文件同步過(guò)程中，應(yīng)用還存在大量中間型文件，中間型文件分為兩類：一種是文件A被修改為B狀態(tài)，但B狀態(tài)實(shí)質(zhì)上是中間狀態(tài)，接著文件被修改保存為C狀態(tài)，C狀態(tài)是可用的版本。如果在處于B狀態(tài)時(shí)發(fā)生了異常，那么該應(yīng)用即使完成了實(shí)時(shí)同步，應(yīng)用在同步的另一側(cè)也是無(wú)法使用的[21]。第二種中間型文件是傳統(tǒng)意義上的臨時(shí)文件，是應(yīng)用運(yùn)行時(shí)產(chǎn)生的帶有明顯標(biāo)示如.swap、～A的臨時(shí)文件。這些文件只用來(lái)緩存中間數(shù)據(jù)，沒(méi)有必要同步，同步中需要加以過(guò)濾[22]。在現(xiàn)有的同步算法中，對(duì)第一種臨時(shí)文件并未加以過(guò)濾，而仍然同步，很容易造成應(yīng)用無(wú)法啟動(dòng)，只能通過(guò)人工干預(yù)處理應(yīng)用的錯(cuò)誤。對(duì)第二種臨時(shí)文件，所有的增量同步同樣會(huì)傳輸，即使這樣的傳輸完全是沒(méi)有必要的，甚至反過(guò)來(lái)還需要一些人工干預(yù)來(lái)刪除這些臨時(shí)的中間文件[23]。

為了解決臨時(shí)文件的問(wèn)題，本文在優(yōu)先級(jí)隊(duì)列的基礎(chǔ)上加入了自適應(yīng)優(yōu)先級(jí)的策略，中間文件延遲同步，臨時(shí)文件不同步。當(dāng)中間文件修改為最終文件后，仍然按照原有的優(yōu)先級(jí)順序同步。既減少了不必要的同步，又保證了同步的優(yōu)先級(jí)順序。如圖6所示，當(dāng)檢測(cè)到文件變?yōu)橹虚g文件時(shí)(通過(guò)檢測(cè)到臨時(shí)文件的產(chǎn)生)，需要?jiǎng)討B(tài)調(diào)整優(yōu)先級(jí)的順序，高優(yōu)先級(jí)的文件應(yīng)該延緩傳輸，將文件加入到低優(yōu)先級(jí)隊(duì)列中。如果文件檢測(cè)到合并，那么需要根據(jù)原有文件的優(yōu)先級(jí)調(diào)整到對(duì)應(yīng)的優(yōu)先級(jí)列表中。這樣，臨時(shí)文件沒(méi)有傳輸，同時(shí)中間文件也能有效地保存在傳輸隊(duì)列中。

圖6　自適應(yīng)優(yōu)先級(jí)調(diào)整

這樣既保證了文件傳輸?shù)膬?yōu)先級(jí)順序，又能有效地過(guò)濾中間文件，減少傳輸。相比于傳統(tǒng)的同步方法，大量的臨時(shí)文件被過(guò)濾掉，減少了網(wǎng)絡(luò)中非必需的傳輸量，有利于提高同步系統(tǒng)的性能，同時(shí)又能保證文件原有的優(yōu)先級(jí)順序。

3　實(shí)驗(yàn)結(jié)果

為了驗(yàn)證本文方法的性能，本文選取了Rsync作為增量同步算法代表，SCP作為全量同步算法代表，和壓縮以后同步的策略作為比較。并在電網(wǎng)場(chǎng)景下使用非常廣泛的基礎(chǔ)平臺(tái)系統(tǒng)和常用的基于Hadoop生態(tài)系統(tǒng)應(yīng)用中進(jìn)行了相應(yīng)的同步實(shí)驗(yàn)來(lái)說(shuō)明本方法在性能上的優(yōu)勢(shì)。實(shí)驗(yàn)在4臺(tái)物理主機(jī)上進(jìn)行。

為了保證真實(shí)性，本文選取了電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)的啟動(dòng)應(yīng)用軟件和基于Hadoop生態(tài)系統(tǒng)軟件及其配套的應(yīng)用程序[6]，來(lái)說(shuō)明本算法的性能。兩種應(yīng)用詳細(xì)情況如表1和表2所示。

表1　電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)實(shí)驗(yàn)環(huán)境

表2　Hadoop實(shí)驗(yàn)環(huán)境

電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)應(yīng)用總文件大小33 GB，文件總數(shù)1 029 492，是電網(wǎng)環(huán)境下的基礎(chǔ)應(yīng)用平臺(tái)，包含了4種主要應(yīng)用：國(guó)產(chǎn)數(shù)據(jù)庫(kù)、電網(wǎng)數(shù)據(jù)交互程序、電網(wǎng)狀態(tài)分析程序、對(duì)外核心服務(wù)程序?；A(chǔ)平臺(tái)系統(tǒng)應(yīng)用的詳細(xì)信息如表3所示。

表3　電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)實(shí)驗(yàn)數(shù)據(jù)集

Hadoop生態(tài)系統(tǒng)軟件是基于Linux的分布式應(yīng)用。Hadoop內(nèi)部是分布式的，可在多物理機(jī)上執(zhí)行，一般不存在遷移需求。當(dāng)其需要遷移時(shí)，其應(yīng)用需要跨集群間遷移。為了模擬遠(yuǎn)程集群間遷移的網(wǎng)絡(luò)帶寬，本文將Hadoop實(shí)驗(yàn)的網(wǎng)速限制在十兆以內(nèi)。實(shí)驗(yàn)環(huán)境如表2所示。

Hadoop生態(tài)系統(tǒng)應(yīng)用軟件總大小1.4 GB，文件總數(shù)20 890，是常見(jiàn)的分布式生態(tài)環(huán)境，用來(lái)提供分布式服務(wù)。應(yīng)用包括基礎(chǔ)系統(tǒng)Hadoop、全局?jǐn)?shù)據(jù)配置Zookeeper、分布式數(shù)據(jù)庫(kù)HBase以及上層的其他應(yīng)用Storm、Spark及定制的第三方程序。Hadoop生態(tài)系統(tǒng)應(yīng)用的具體信息如表4所示。

表4　Hadoop系統(tǒng)實(shí)驗(yàn)數(shù)據(jù)集

3.1應(yīng)用間文件去重同步實(shí)驗(yàn)

本文利用電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)數(shù)據(jù)集和Hadoop應(yīng)用數(shù)據(jù)集完成文件去重實(shí)驗(yàn)。

圖7是電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)數(shù)據(jù)集下的同步時(shí)間圖。橫坐標(biāo)是算法，縱坐標(biāo)是同步時(shí)間。各算法內(nèi)部分為三部分：預(yù)處理時(shí)間、傳輸時(shí)間、恢復(fù)時(shí)間?？v坐標(biāo)均以秒為單位。

圖7　電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)應(yīng)用數(shù)據(jù)集下各算法同步時(shí)間

圖8是各個(gè)算法在Hadoop數(shù)據(jù)集下的同步時(shí)間圖。橫坐標(biāo)是算法，縱坐標(biāo)是同步時(shí)間。各算法內(nèi)部分為三部分：預(yù)處理時(shí)間、傳輸時(shí)間、恢復(fù)時(shí)間?？v坐標(biāo)均以秒為單位。

圖8　Hadoop同步時(shí)間圖

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

3.2優(yōu)先級(jí)同步實(shí)驗(yàn)

電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)應(yīng)用包括國(guó)產(chǎn)數(shù)據(jù)庫(kù)(后文簡(jiǎn)稱DM數(shù)據(jù)庫(kù))，提供關(guān)系型數(shù)據(jù)庫(kù)服務(wù)；數(shù)據(jù)交互應(yīng)用CM(Commutating Program)，收集電網(wǎng)中的監(jiān)控?cái)?shù)據(jù)和告警數(shù)據(jù)存入國(guó)產(chǎn)數(shù)據(jù)庫(kù)中；電網(wǎng)數(shù)據(jù)分析應(yīng)用CP(Collecting and Analyzing Program)，分析數(shù)據(jù)庫(kù)中的監(jiān)控?cái)?shù)據(jù)和告警數(shù)據(jù)，并對(duì)電網(wǎng)下一刻狀態(tài)進(jìn)行估計(jì)；系統(tǒng)核心對(duì)外服務(wù)程序SP(Service Program)是向外部提供數(shù)據(jù)通信接口的應(yīng)用。應(yīng)用間相互獨(dú)立，但又需要協(xié)同工作，存在明顯的啟動(dòng)先后順序。國(guó)產(chǎn)數(shù)據(jù)庫(kù)需要優(yōu)先啟動(dòng)提供服務(wù)，然后數(shù)據(jù)交互和數(shù)據(jù)分析才能啟動(dòng)；待上述應(yīng)用全部啟動(dòng)完成，最后再啟動(dòng)對(duì)外的核心服務(wù)程序。應(yīng)用的平均啟動(dòng)時(shí)間為3秒。

因其他算法無(wú)優(yōu)先級(jí)，都需要全部同步完成后啟動(dòng)應(yīng)用，下表列出所需同步文件大小及完成同步時(shí)間。

圖9是電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)應(yīng)用優(yōu)先級(jí)同步時(shí)間圖。橫坐標(biāo)是對(duì)應(yīng)的基礎(chǔ)平臺(tái)的四種應(yīng)用，縱坐標(biāo)是同步時(shí)間。縱坐標(biāo)均以秒為單位。

圖9　電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)數(shù)據(jù)集優(yōu)先同步

Hadoop應(yīng)用程序取自電網(wǎng)基礎(chǔ)云平臺(tái)，包括了Java開發(fā)環(huán)境，用來(lái)為整套系統(tǒng)提供HDFS分布式文件服務(wù)。HBase分為兩套，HBase使用0.90-17提供分布式數(shù)據(jù)存儲(chǔ)，定制HBase使用0.94.17為電網(wǎng)系統(tǒng)提供穩(wěn)定存儲(chǔ)服務(wù)。Spark和Storm提供數(shù)據(jù)分析，Zookeeper管理全局文件和數(shù)據(jù)。第三方程序利用HBase中的數(shù)據(jù)，使用Spark加以分析，并存儲(chǔ)到HDFS中。應(yīng)用啟動(dòng)的優(yōu)先級(jí)是首先啟動(dòng)Hadoop和Zookeeper，然后啟動(dòng)兩套HBase，接著啟動(dòng)Storm和Spark，最后啟動(dòng)第三方應(yīng)用程序。應(yīng)用的平均啟動(dòng)時(shí)間為5秒。

圖10是Hadoop應(yīng)用優(yōu)先級(jí)同步時(shí)間圖。橫坐標(biāo)是對(duì)應(yīng)的Hadoop的八種應(yīng)用，縱坐標(biāo)是同步時(shí)間。縱坐標(biāo)均以秒為單位。

圖10　Hadoop數(shù)據(jù)集優(yōu)先級(jí)同步

本文算法通過(guò)利用優(yōu)先級(jí)隊(duì)列，將重要文件集優(yōu)先同步，發(fā)現(xiàn)均優(yōu)于Rsync算法和SCP算法。本文算法平均啟動(dòng)時(shí)間在電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)數(shù)據(jù)集下優(yōu)于Rsync算法約16%，優(yōu)于SCP算法約56%；在Hadoop數(shù)據(jù)集下本算法比Rsync算法大約提高了55%的時(shí)間，比SCP提高了約58%的時(shí)間，大幅減少了應(yīng)用的等待。一方面是因?yàn)樘摂M目錄過(guò)濾帶來(lái)的時(shí)間優(yōu)化，另一方面是基礎(chǔ)程序在其他程序傳輸過(guò)程中已經(jīng)啟動(dòng)。如電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)中國(guó)產(chǎn)數(shù)據(jù)庫(kù)啟動(dòng)就需要30秒的時(shí)間，而這30秒Rsync和SCP只能并行。在本文算法中，這部分時(shí)間同時(shí)在傳輸文件。本文算法針對(duì)多應(yīng)用啟動(dòng)的同步性能較好。

3.3中間文件過(guò)濾

中間文件主要是在實(shí)時(shí)同步過(guò)程中，程序發(fā)生的實(shí)時(shí)修改，如對(duì)本地文件的修改和對(duì)數(shù)據(jù)文件的修改。在Hadoop應(yīng)用中這樣的修改較少，在電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)中，因?yàn)榉治龀绦蛐枰薷臄?shù)據(jù)文件，緩存中間文件，導(dǎo)致這樣的修改過(guò)程非常多。取10分鐘時(shí)間段，發(fā)現(xiàn)基礎(chǔ)平臺(tái)系統(tǒng)應(yīng)用的修改主要集中在配置文件和數(shù)據(jù)文件。批量在配置文件中修改224個(gè)文件，總大小3.2 MB，產(chǎn)生中間臨時(shí)文件224個(gè)，臨時(shí)文件平均大小17 KB，添加166個(gè)數(shù)據(jù)文件，總大小2.8 MB。

圖11是各個(gè)算法的對(duì)中間文件過(guò)濾同步圖。橫坐標(biāo)是對(duì)應(yīng)的三種算法，左側(cè)縱坐標(biāo)對(duì)應(yīng)文件大小，單位是MB。右側(cè)縱坐標(biāo)對(duì)應(yīng)同步的文件數(shù)量，單位是個(gè)。

圖11　中間文件過(guò)濾同步時(shí)間圖

本文通過(guò)對(duì)中間文件的過(guò)濾，大幅減少了中間文件的傳輸。文件數(shù)量只有Rsync和SCP算法的60%，文件大小約只有Rsync的56%和SCP的45%。在實(shí)時(shí)同步的過(guò)程中，大量的臨時(shí)文件不但占用了帶寬，也影響了同步的效率。本文算法通過(guò)動(dòng)態(tài)調(diào)整優(yōu)先級(jí)大量減少了同步的文件數(shù)量和文件大小。

4　結(jié)　語(yǔ)

本文針對(duì)多應(yīng)用的場(chǎng)景，結(jié)合多應(yīng)用的特點(diǎn)，發(fā)掘應(yīng)用間的文件關(guān)聯(lián)關(guān)系，對(duì)應(yīng)用間的文件去重后同步，大幅減少了同步過(guò)程中的文件大小和同步時(shí)間。結(jié)合應(yīng)用啟動(dòng)的目的，本文通過(guò)建立優(yōu)先級(jí)隊(duì)列，討論優(yōu)先級(jí)隊(duì)列模型保證了應(yīng)用的平均啟動(dòng)時(shí)間最短。結(jié)合應(yīng)用修改的特點(diǎn)，本文提出了自適應(yīng)優(yōu)先級(jí)策略，動(dòng)態(tài)調(diào)整同步文件的優(yōu)先級(jí)，延遲中間型文件的同步，過(guò)濾臨時(shí)文件的同步，大幅減少了同步的文件總量。本文成功設(shè)計(jì)和實(shí)現(xiàn)了面向多應(yīng)用的文件同步系統(tǒng)，并在電網(wǎng)基礎(chǔ)平臺(tái)系統(tǒng)應(yīng)用和Hadoop應(yīng)用中實(shí)驗(yàn)。實(shí)驗(yàn)結(jié)果表明，本文提出的方法優(yōu)于常規(guī)的全量同步和增量同步方法，具有很高的實(shí)用價(jià)值。

[1] 李焱.備份與容災(zāi)在企業(yè)信息化建設(shè)中的應(yīng)用[J].信息系統(tǒng)工程,2014(12):116-118,137.

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

[3] 蘇冠群,陶宏才.基于Linux平臺(tái)的遠(yuǎn)程數(shù)據(jù)容災(zāi)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用,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] 佟強(qiáng),肖翔.D5000系統(tǒng)在浙江電網(wǎng)的應(yīng)用分析[C]//2013年中國(guó)電機(jī)工程學(xué)會(huì)年會(huì)論文集.北京:中國(guó)電機(jī)工程學(xué)會(huì),2013.

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

[7] 王福陽(yáng),李小堅(jiān),俞前.基于M+N結(jié)構(gòu)的SCP容災(zāi)系統(tǒng)設(shè)計(jì)[J].計(jì)算機(jī)工程,2008,34(11):252-254,282.[8] 何倩,趙幫,王勇,等.基于本地快照和Rsync算法的Web文件保護(hù)[J].計(jì)算機(jī)工程,2013,39(6):190-193,199.

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

[10] 李貞.基于Rsync算法的遠(yuǎn)程文件同步系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京:北京郵電大學(xué),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ìn)文件同步算法[J].通信市場(chǎng),2009(3):78-82.

[13] 張海峰,張耀南,張寶山.異構(gòu)環(huán)境下數(shù)據(jù)文件Rsync同步機(jī)制研究[J].計(jì)算機(jī)與現(xiàn)代化,2009(10):78-81,85.

[14] 張海峰.基于Rsync的異構(gòu)環(huán)境數(shù)據(jù)同步機(jī)制研究[D].成都:電子科技大學(xué),2009.

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

[16] 袁志堅(jiān),陳穎文,繆嘉嘉,等.典型Bloom過(guò)濾器的研究及其數(shù)據(jù)流應(yīng)用[J].計(jì)算機(jī)工程,2009,35(7):5-7.

[17] 段中興,趙煌.反饋控制的優(yōu)先級(jí)隊(duì)列公平調(diào)度算法[J].西安建筑科技大學(xué)學(xué)報(bào):自然科學(xué)版,2003,35(4):390-393.

[18] 李周志,王曉東,王真之,等.基于多優(yōu)先級(jí)緩存隊(duì)列的遠(yuǎn)程數(shù)據(jù)傳輸技術(shù)[J].計(jì)算機(jī)工程,2010,36(18):105-108.

[19] 毛翠.遠(yuǎn)程文件同步算法研究和應(yīng)用[D].成都:電子科技大學(xué),2011.

[20] 王宏久.系統(tǒng)容量有限的一類排隊(duì)論模型的計(jì)算機(jī)模擬研究[D].哈爾濱:哈爾濱工業(yè)大學(xué),2007.

[21] 劉西崗.基于rsync算法的云平臺(tái)文件同步系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].四川:電子科技大學(xué),2013.

[22] 任燕博,劉釗遠(yuǎn).基于RSYNC遠(yuǎn)程同步系統(tǒng)的優(yōu)化[J].計(jì)算機(jī)與數(shù)字工程,2014,42(6):1007-1010.

[23] 蘇冠群,陶宏才.基于Linux平臺(tái)的遠(yuǎn)程數(shù)據(jù)容災(zāi)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用,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。國(guó)家高技術(shù)研究發(fā)展計(jì)劃基金項(xiàng)目(20 12AA01A401)。曾珊，碩士生，主研領(lǐng)域：大數(shù)據(jù)處理。周薇，博士生。韓冀中，教授。

TP3

A

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