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

曾　珊　周　薇　韩冀中

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