CN110704389B

CN110704389B - 一种基于驱动和状态的双向文件同步方法

Info

Publication number: CN110704389B
Application number: CN201910902395.7A
Authority: CN
Inventors: 袁来双; 张志光; 张娟
Original assignee: Wuhan Yichang Zhiyun Technology Co ltd
Current assignee: Wuhan Yichang Zhiyun Technology Co ltd
Priority date: 2019-09-24
Filing date: 2019-09-24
Publication date: 2022-02-01
Anticipated expiration: 2039-09-24
Also published as: CN110704389A

Abstract

本发明属于通信技术领域，提供了一种基于驱动和状态的双向文件同步方法，包括上行同步方法和下行同步方法，上行同步方法基于驱动行为实现，通过动作管理器对驱动的动作进行捕捉，并进行动作序列的合并和优化后，将本地的动作变化提交至服务器，由服务器的动作处理器单元执行同步动作，可以使得这种场景的性能得到显著优化；下行同步方法基于状态实现，其采用递归的方式，对文件夹进行对比和排查，定位需要增加、删除或改动的文件，并进行相应的增加、删除或改动的操作，可以大幅度减少递归请求次数，可以快速得到服务端变更项。本发明可以广泛应用于文件同步领域。

Description

一种基于驱动和状态的双向文件同步方法

技术领域

本发明属于通信技术领域，具体涉及一种基于驱动和状态的双向文件同步方法。

背景技术

随着互联网技术的发展，越来越多的用户喜欢使用文件同步来管理终端上的文件，这可以使得用户在不同地方和不同终端上及时将文件的更新同步到服务器，同时方便用户从服务器上获取最新的文件信息。

现有的文件同步技术中，用户对终端同步目录下的文件进行更新操作后，终端对本地同步目录进行一次全扫描，将扫描到的每个文件信息发送到服务器验证，以确定该文件的更新状态，比如增加或删除等，如果该文件是更新的，则将文件同步到服务器。这种同步的缺陷表现在不能实现终端和服务器的双向同步，即将终端的更新同步到服务器，同时将服务器的更新同步到终端。

现有技术中，也有人提供了一种文件同步方法和装置，其基于文件列表快照实现，通过文件的标识和操作实现，但其仅仅只能实现文件的更新，对于文件的移动和文件夹的同步无法实现。

发明内容

本发明克服现有技术存在的不足，提供了一种基于驱动和状态的双向同步方法，以优化文件同步过程，减少递归请求次数，快速得到服务端变更项。

为了解决上述技术问题，本发明采用的技术方案为：一种基于驱动和状态的双向文件同步方法，包括上行同步方法和下行同步方法，其特征在于，上行同步方法基于驱动行为实现，通过动作管理器对驱动的动作进行捕捉，并进行动作序列的合并和优化后，将本地的动作变化提交至服务器，由服务器的动作处理器单元执行同步动作；下行同步方法基于状态实现，其采用递归的方式，对文件夹进行对比和排查，定位需要增加、删除或改动的文件，并进行相应的增加、删除或改动的操作。

所述上行同步方法中，动作处理器单元包括新建文件夹处理单元、新建文件处理单元、删除文件/文件夹处理单元、移动文件/文件夹处理单元及文件修改处理单元；

所述新建文件夹处理单元用于执行以下步骤：

S101本地创建文件夹后，判断远端是否创建成功，若是，则将服务端的标志ID和时间写到本地ltr数据中；若否，则进入步骤S102；

S102、通过递归方法在远端创建父目录，然后返回步骤S101；

所述新建文件处理单元用于执行以下步骤：

S201、本地创建文件后，判断远端是否创建成功，若是，则将服务端的标志ID和时间写到本地ltr数据中，并通过异步上传队列进行文件数据上传，上传成功后，更新blocks和时间；若否，则进入步骤S202；

S202、判断创建不成功原因，若为父目录不存在，则通过递归方法在远端创建父目录后，返回步骤S201；若为文件已存在，则本地文件重命名后，返回步骤S201；

所述文件修改处理单元用于执行以下步骤：

S301、本地提交文件修改后，判断远端是否存在文件，若不存在，则进入创建文件同步流程，若存在，则进入步骤S302；

S302、则判断文件是否冲突，若冲突，则进行冲突处理后，返回步骤S301；若不冲突，则将服务端的标志ID和时间写到本地ltr数据中，并通过异步上传队列进行文件数据上传，上传成功后，更新blocks和时间；

所述移动文件/文件夹处理单元用于执行以下步骤：

S401、本地移动文件或文件夹后，判断远端是否移动成功，若是，则将服务端的标志ID和时间写到本地ltr数据中，并通过异步上传队列进行文件数据上传，上传成功后，更新blocks和时间；若否，则进入步骤S402；

S402、判断移动不成功原因，若为父目录不存在，则通过递归方法在远端创建父目录后，返回步骤S401；若为文件已存在且不覆盖，则本地文件或文件夹重命名后，返回步骤S401；

所述删除文件/文件夹处理单元用于执行以下步骤：

S501、本地删除文件或文件夹后，判断远端是否删除成功，若是，则结束，若否，则进入步骤S502；

S502、判断是否存在删除冲突，若无，则重新删除远端，若有，则对远端文件重命名。

所述上行同步方法中，所述动作管理器内置了6个动作，包括创建文件/文件夹、删除文件/文件夹、移动文件/文件夹、文件数据变化和文件/文件夹原信息变化；

动作管理器对驱动的动作进行捕捉和合并的方法具体为：当驱动发生动作时，触发动作注册机，动作注册机驱动不同的动作在动作管理器中进行注册，动作注册机制为：

所述上行同步方法中，对捕捉到的驱动的动作进行合并和优化的具体方法为：

所述下行同步方法包括以下步骤：

S601、在服务端引入关键时间值标识，所述关键时间值标识包括：文件或文件夹最后修改时间标识SMTime，文件夹内最大文件或文件夹的最后修改时间标识XSMtime和以当前文件夹为根的树中的文件或文件夹最大的一个最后修改时间标识RSMTime；

S602、以某个文件夹为起点进行递归比较的向下同步，判断远端的当前文件夹为根的树中的文件或文件夹最大的一个最后修改时间标识RSMTime是否增大，若无增大，则同步完成，对下一个文件夹进行同步，若增大，则进入步骤S603；

S603、判断远端文件夹内最大文件或文件夹的最后修改时间标识XSMtime是否增大，若增大，则同步一级目录文件和文件夹；若无增大，则同步完成。

所述下行同步方法还包括标记文件状态的步骤，所述文件状态包括：

NEW：表示本地新创建的文件或文件夹；

MODIFIED：表示本地修改过并且已经至少同步过一次的文件；

SYNCHRONIZED：表示同步完成状态的文件；

SYNCHRONIZING：表示正在同步的文件；

UPLOADING：表示上传中的文件；

DOWNLOADING：表示下载中的文件。

所述标记文件状态的具体方法为：

对于新创建的文件或者文件夹，文件状态标记为NEW；

当本地文件内容被用户修改，且文件的状态为SYNCHRONIZED时，文件状态标记为MODIFIED；

本地上行同步成功后的文件状态标记为SYNCHRONIZED，下行同步中，对服务端的文件进行遍历，遍历的同时，将本地文件状态从SYNCHRONIZED标记为SYNCHRONIZING，下行同步时在本地添置的文件，初始状态也标记为SYNCHRONIZING，遍历完成后，将状态为SYNCHRONIZING的文件还原成SYNCHRONIZED；

在上传或者下载即将开始的时候，将文件的状态会标记为UPLOADING或DOWNLOADING，；当上传下载完成时，将文件状态标记为SYNCHRONIZED；

当要上传的文件在本地未关闭时，将文件标记为MODIFIED。

下行同步遍历文件夹后，将SYNCHRONIZED状态的本地文件删除，然后再将状态为SYNCHRONIZING的文件还原成SYNCHRONIZED。

标记文件状态时，还包括判断下行同步IsChecking状态位的步骤，下行同步状态中，IsChecking状态为Ture，当有文件下载完成后，IsChecking仍然为True的话，将文件状态标记为SYNCHRONIZING。

所述步骤S603中，同步文件夹或文件时，仅对服务端和本地保存文件或文件夹的最后修改时间标识SMTime不同的文件进行对比。

本发明与现有技术相比具有以下有益效果：本发明提供了一种基于驱动和状态的双向文件同步方法，其基于驱动行为的上行同步方式可以使得这种场景的性能得到显著优化，对本地行为进行优化；同时，下行同步时采用服务端提供的3个关键时间字段和ltr中记录的时间进行对比，大幅度减少递归请求次数，可以快速得到服务端变更项。从而提高下行同步的速度和减少服务器的同步压力。

附图说明

图1为本发明实施例中新建文件夹处理单元的工作流程图；

图2为本发明实施例中新建文件处理单元的工作流程图；

图3为本发明实施例中文件修改处理单元的工作流程图；

图4为本发明实施例中移动文件/文件夹处理单元的工作流程图；

图5为本发明实施例中删除文件/文件夹处理单元的工作流程图；

图6为本发明实施例中下行同步时的工作流程图。

具体实施方式

为使本发明的技术方案和优点更加清楚，下面将结合具体实施例和附图，对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例；基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供了一种基于驱动和状态的双向文件同步方法，包括上行同步方法和下行同步方法，上行同步方法基于驱动行为实现，通过动作管理器对驱动的动作进行捕捉，并进行动作序列的合并和优化后，将本地的动作变化提交至服务器，由服务器的动作处理器单元执行同步动作；下行同步方法基于状态实现，其采用递归的方式，对文件夹进行对比和排查，定位需要增加、删除或改动的文件，并进行相应的增加、删除或改动的操作。

下面介绍上行同步的具体方法。

本实施例中，上行同步基于驱动行为实现，由动作管理器(LocalActionManager)对驱动的动作进行捕捉和合并，然后根据用户执行的动作序列，将本地变化提交至服务器。

由于用户大部分编辑操作产生在PC端，因而用户在同步时上行提交的数据往往远远小于下行同步的数据。而基于驱动行为的上行同步方式可以使得这种场景的性能得到显著优化。

LocalActionManager，即本地动作管理器，动作管理器可以用于对本地数据操作的动作序列进行捕捉，并按照一定规则进行合并和优化。所述动作管理器内置了6个动作，包括创建文件/文件夹、删除文件/文件夹、移动文件/文件夹、文件数据变化和文件/文件夹原信息变化；具体如下：

ACT_Create:创建文件或文件夹；

ACT_Delete:删除文件或文件夹；

ACT_Move:移动文件或文件夹(至其他目录)；

ACT_Modify:文件数据有变化(此时文件原信息也一定会变化)；

ACT_ModifyMeta:文件或文件夹的原信息发生变化(重命名算作原信息变化而非移动)。

本实施例中，动作管理器内置在缓存服务器CachedSvr中，当驱动发生动作触发缓存服务器CachedSvr中的动作后，缓存服务器CachedSvr会将驱动不同的动作在动作管理器LocalActionManager中进行注册。

在驱动动作注册机制如表1，以下都是针对缓存目录的情况：

表1动作管理器的动作注册机制

此外，所述上行同步方法中，对捕捉到的驱动的动作进行合并和优化的具体策略如表2所示，其中，本地文件指本地创建的文件，该文件未进行过同步，文件内内置本地fid；同步文件指至少与服务端同步过一次的文件，fid与服务端一致。

表2动作管理器的合并优化策略

所述上行同步过程中，动作处理器单元RopMerger负责元数据的上行同步与下行同步的算法实现，其包括新建文件夹处理单元、新建文件处理单元、删除文件/文件夹处理单元、移动文件/文件夹处理单元及文件修改处理单元；当上行同步启动时，动作处理器单元将会从动作管理器中取出当前动作池中的全部动作，并且依次分发给动作处理单元进行执行，从而完成文件的上行同步。

6个内置动作处理单元如下：

文件修改处理单元；

CommitCreateFolder:新建文件夹处理单元；

CommitCreateFile:新建文件处理单元；

CommitDelete:删除文件/文件夹处理单元；

CommitMove:移动文件/文件夹处理单元；

其中，文件修改处理单元包括两个单元，

CommitModifaction:提交文件修改处理单元(包含数据和元数据)；

CommitModifactionMetaOnly:提交文件/文件夹元信息修改处理单元。

如图1所示，所述新建文件夹处理单元用于执行以下步骤：

S102、通过递归方法在远端创建父目录，然后返回步骤S101。

如图2所示，所述新建文件处理单元用于执行以下步骤：

S202、判断创建不成功原因，若为父目录不存在，则通过递归方法在远端创建父目录后，返回步骤S201；若为文件已存在，则本地文件重命名后，返回步骤S201。

如图3所示，所述提交文件修改处理单元和提交文件/文件夹元信息修改处理单元的处理步骤相同，具体为：

S302、则判断文件是否冲突，若冲突，则进行冲突处理后，返回步骤S301；若不冲突，则将服务端的标志ID和时间写到本地ltr数据中，并通过异步上传队列进行文件数据上传，上传成功后，更新blocks和时间。

本实施例中，由于前面的创建只是创建了文件的条目，并没有上传文件的具体的直接信息。因此，需要把这个上传过程放到另一个线程中进行执行，即异步上传队列，其中，异步上传队列用于异步处理数据流的上传和下载，它是是一个多线程的数据传输工具。本实施例中，异步传输队列使用任务队列和简单的线程池实现，需要执行的任务，丢入任务队列后，线程池内的计算线程会依次从队列中拾取任务进行上传或下载操作。

如图4所示，所述移动文件/文件夹处理单元用于执行以下步骤：

如图5所示，所述删除文件/文件夹处理单元用于执行以下步骤：

图1～图5中，回填FID及各种时间是指把服务端的标志ID和ctime、mtime、atime、smtime、rsmtime、xsmtime、s_ctime、s_mtime、s_atime写到本地的ltr数据中。更行blocks就是把文件字节上传成功后把状态写回到ltr中。

具体地，本实施例中，下行同步基于状态，采用递归的方式，进行文件夹和文件的对比和排查，定位需要增、删、改的文件，并进行对应的操作。

为了查找文件变化，服务端引入了3个关键时间值标识了文件的时间形态：

·SMTime：针对文件或文件夹有效。表示文件或文件夹的最后修改时间。对于文件，元信息和文件内容发生变化时，都会触发SMTime增大；而对于文件夹，元信息修改会触发SMTime增大,其中文件夹的原信息包括name,c_atime,c_ctime,c_mtime，rights等。

·XSMTime：只针对文件夹有效。表示该文件夹内最大的文件或文件夹的SMTime。

·RSMTime：只针对文件夹有效。表示以当前文件夹为根的树中的文件或文件夹最大的一个SMTime。

需要注意的是，本地的SMTime、XSMTime和RSMTIme不会随着本地操作的修改而增大，只会在下行同步的时候才会产生数值增大。而远端的三个时间值，随着修改时刻在变化。也就是在递归服务端的文件目录和本地的保存的SMTIME时间进行对比，只对SMTIME时间不一致的文件目录进行进一步对比。这样就可以减少递归对比的量，避免全目录扫描。

本实施例中，动作处理器单元不仅负责元数据的上行同步，还负责下行同步的算法实现，本实施例中，向下同步就是一个递归比较的过程。比较的起点是某个Folder(如果全部同步则为ROOT)。若远端RSMTime增大，则表示该目录树发生了变化，需要递归子树。若XSMTime也增大，则表示在一级目录内存在变化。对于SMTime增大的文件或文件夹，我们则进行元信息(文件夹、文件)和数据(文件)的下行同步。如图6所示，所述下行同步方法的包括以下步骤：

S603、判断远端文件夹内最大文件或文件夹的最后修改时间标识XSMtime是否增大，若增大，则同步一级目录文件和文件夹；若无增大，则同步一级文件夹。

具体地，本实施例中，所述下行同步方法还包括标记文件状态的步骤，所述文件状态包括5个状态，分别如下：

NEW：表示本地新创建的文件或文件夹；

MODIFIED：表示本地修改过并且已经至少同步过一次的文件；

SYNCHRONIZED：表示同步完成状态的文件；

SYNCHRONIZING：表示正在同步的文件；

UPLOADING：表示上传中的文件；

DOWNLOADING：表示下载中的文件。

所述标记文件状态，即文件状态切换的具体情况包括以下几种：

case 1:新文件

对于新创建的文件或者文件夹，文件状态标记为NEW。

case 2：修改文件

在CachedSvr中，当文件内容被用户修改(Extend，Truncate，LocalWrite)且文件的状态为SYNCHRONIZED时，文件被标记为MODIFIED。

该状态表示该文件被修改了，如果在上行同步后，下行同步前，进行了状态位的标记，就可以有效的避免下行同步时本地文件被覆盖或者被删的情况。

case 3：下行同步删除本地文件

这个情况主要靠SYNCHRONIZED与SYNCHRONIZING两个状态进行配合。

本地上行同步成功后的文件状态为SYNCHRONIZED，下行同步时，会对服务端的文件进行遍历，遍历的同时，对本地文件状态从SYNCHRONIZED标记为SYNCHRONIZING。遍历完成后，本地状态仍为SYNCHRONIZED的文件，即为没有被标记到的文件，说明这个文件远端已经删除。

当然，下行同步后，SYNCHRONIZING状态的文件，会被重新还原标记为SYNCHRONIZED。

需要额外说明的是，通过下行同步在本地添置的文件，初始状态标记为SYNCHRONIZING，以保证“检查哪些文件没有被标记时”不被误删。

case 4：上传和下载

在上传或者下载即将开始的时候，文件的状态会被标记为UPLOADING和DOWNLOADING，然后被丢入异步上传下载队列。当上传下载完成时，文件会重新被标识为SYNCHRONIZED表示文件同步完成。

case 5：上传一个本地未关闭的文件

如果这个文件已经关闭，毫无疑问，将会被标志为UPLOADING然后投递至任务队列。但是如果文件处于编辑状态，那么我们会把该文件重新标记为MODIFIED，然后下次上行同步的时候再尝试提交。

case 6：下行同步删除本地文件【多线程】

由case 3知道，下行同步遍历文件夹后，SYNCHRONIZED状态的本地文件会被删除。但是，有一种特殊情况请考虑：当一个文件被投递到下载任务队列后，由于文件极小，下载极快，有可能在下行同步还未结束就下载完了。此时，callback之后，该文件的状态被标记为了SYNCHRONIZED，然后下行同步进一步检查的时候，认为“该文件没有被标记”，实际上是不仅标记了，而且已经都下载完了更新状态完了。所以为了避免这个情况的发生，给文件增加了IsChecking状态位。下行同步状态中，IsChecking状态为为Ture。当有文件下载完成后，IsChecking仍然为True的话，将文件状态标记为SYNCHRONIZING从而防止文件被误删。也就是说，标记文件状态时，还包括判断下行同步IsChecking状态位的步骤，下行同步状态中，IsChecking状态为Ture，当有文件下载完成后，IsChecking仍然为True的话，将文件状态标记为SYNCHRONIZING。

因此，本实施例中，下行同步遍历文件夹后，将SYNCHRONIZED状态的本地文件删除，然后再将状态为SYNCHRONIZING的文件还原成SYNCHRONIZED。

上面结合附图对本发明的实施例作了详细说明，但是本发明并不限于上述实施例，在本领域普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下作出各种变化。

Claims

1.一种基于驱动和状态的双向文件同步方法，包括上行同步方法和下行同步方法，其特征在于，上行同步方法基于驱动行为实现，通过动作管理器对驱动的动作进行捕捉，并进行动作序列的合并和优化后，将本地的动作变化提交至服务器，由服务器的动作处理器单元执行同步动作；下行同步方法基于状态实现，其采用递归的方式，对文件夹进行对比和排查，定位需要增加、删除或改动的文件，并进行相应的增加、删除或改动的操作；所述上行同步方法中，动作处理器单元包括新建文件夹处理单元、新建文件处理单元、删除文件/文件夹处理单元、移动文件/文件夹处理单元及文件修改处理单元；

所述新建文件夹处理单元用于执行以下步骤：

S102、通过递归方法在远端创建父目录，然后返回步骤S101；

所述新建文件处理单元用于执行以下步骤：

所述文件修改处理单元用于执行以下步骤：

所述移动文件/文件夹处理单元用于执行以下步骤：

所述删除文件/文件夹处理单元用于执行以下步骤：

2.根据权利要求1所述的一种基于驱动和状态的双向文件同步方法，其特征在于，所述上行同步方法中，所述动作管理器内置了6个动作，包括创建文件/文件夹、删除文件/文件夹、移动文件/文件夹、文件数据变化和文件/文件夹原信息变化；

3.根据权利要求2所述的一种基于驱动和状态的双向文件同步方法，其特征在于，所述上行同步方法中，对捕捉到的驱动的动作进行合并和优化的具体方法为：

4.根据权利要求1所述的一种基于驱动和状态的双向文件同步方法，其特征在于，所述下行同步方法包括以下步骤：

5.根据权利要求4所述的一种基于驱动和状态的双向文件同步方法，其特征在于，所述下行同步方法还包括标记文件状态的步骤，所述文件状态包括：

NEW：表示本地新创建的文件或文件夹；

MODIFIED：表示本地修改过并且已经至少同步过一次的文件；

SYNCHRONIZED：表示同步完成状态的文件；

SYNCHRONIZING：表示正在同步的文件；

UPLOADING：表示上传中的文件；

DOWNLOADING：表示下载中的文件。

6.根据权利要求5所述的一种基于驱动和状态的双向文件同步方法，其特征在于，所述标记文件状态的具体方法为：

对于新创建的文件或者文件夹，文件状态标记为NEW；

在上传或者下载即将开始的时候，将文件的状态会标记为UPLOADING或DOWNLOADING；当上传下载完成时，将文件状态标记为SYNCHRONIZED；

当要上传的文件在本地未关闭时，将文件标记为MODIFIED。

7.根据权利要求6所述的一种基于驱动和状态的双向文件同步方法，其特征在于，下行同步遍历文件夹后，将SYNCHRONIZED状态的本地文件删除，然后再将状态为SYNCHRONIZING的文件还原成SYNCHRONIZED。

8.根据权利要求7所述的一种基于驱动和状态的双向文件同步方法，其特征在于，标记文件状态时，还包括判断下行同步IsChecking状态位的步骤，下行同步状态中，IsChecking状态为Ture，当有文件下载完成后，IsChecking仍然为True的话，将文件状态标记为SYNCHRONIZING。

9.根据权利要求7所述的一种基于驱动和状态的双向文件同步方法，其特征在于，所述步骤S603中，同步文件夹或文件时，仅对服务端和本地保存文件或文件夹的最后修改时间标识SMTime不同的文件进行对比。