CN115408342A - 文件处理方法、装置及电子设备 - Google Patents

Abstract

本申请公开了一种文件处理方法、装置及电子设备。其中，该方法包括：接收文件处理请求，其中，文件处理请求中至少包含游标信息，游标信息用于标识数据库集群中的第一个待删除文件；按照预设的删除顺序，根据游标信息采用并行删除的方式对数据库集群中的至少一个待删除文件的部分文件数据进行删除；在每次删除操作完成之后，统计删除数据总量，并在删除数据总量大于预设阈值时，更新元数据信息，其中，元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。本申请解决了现有技术中垃圾文件删除效率低的技术问题。

Description

文件处理方法、装置及电子设备

技术领域

本申请涉及文件处理领域，具体而言，涉及一种文件处理方法、装置及电子设备。

背景技术

随着大数据时代的到来，为了对数据进行更加高效的处理，数据库集群被大量应用于分布式文件系统的实现中。

其中，现有的分布式文件系统在从数据库集群中删除多个垃圾文件时，采用依次逐个文件删除的方式，并且每次都是从垃圾文件的头部开始从前往后对每个垃圾文件的数据进行删除。这种方式一方面无法同时处理多个垃圾文件，文件删除的效率较低；另一方面，在从头部开始从前往后删除数据的过程中，如果遇到分布式文件系统重新启动，需要重新开始检测每个垃圾文件，从而一些已经被删除的文件也需要被重新检索，加剧了文件删除效率低的问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种文件处理方法、装置及电子设备，以至少解决现有技术中垃圾文件删除效率低的技术问题。

根据本申请实施例的一个方面，提供了一种文件处理方法，包括：接收文件处理请求，其中，文件处理请求中至少包含游标信息，游标信息用于标识数据库集群中的第一个待删除文件；按照预设的删除顺序，根据游标信息采用并行删除的方式对数据库集群中的至少一个待删除文件的部分文件数据进行删除，其中，部分文件数据的数据量小于或等于预设数据量，在删除每个待删除文件时，从每个待删除文件的尾部开始从后往前删除文件数据；在每次删除操作完成之后，统计删除数据总量，并在删除数据总量大于或等于预设阈值时，更新元数据信息，其中，元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。

进一步地，文件处理方法还包括：按照预设的删除顺序，从数据库集群中确定预设数量的待删除文件；采用并行删除的方式对预设数量的待删除文件进行删除，其中，在删除过程中包括至少一次删除操作，每次删除操作所删除的最大文件数据量为预设数据量。

进一步地，文件处理方法还包括：在每次对待删除文件进行删除操作时，检测待删除文件在删除过程中是否存在异常；在待删除文件在删除过程中存在异常时，确定待删除文件为异常文件；将异常文件对应的垃圾文件记录移动至第一文件队列中。

进一步地，文件处理方法还包括：在每次对待删除文件进行删除操作时，检测待删除文件的文件数据是否已经被全部删除；在待删除文件的文件数据未被全部删除的情况下，将待删除文件对应的垃圾文件记录移动至第二文件队列中；在待删除文件的文件数据已经被全部删除的情况下，将待删除文件对应的垃圾文件记录移动至第三文件队列中。

进一步地，文件处理方法还包括：在每次对待删除文件进行删除时，确定待删除文件还未被删除的文件数据的数据量为待删除数据量；在待删除数据量大于或等于固定数据量时，从待删除文件的尾部开始从后往前删除固定数据量的文件数据，其中，固定数据量为每次删除操作时对一个待删除文件能够进行删除的最大数据量；在待删除数据量小于固定数据量时，将待删除文件全部删除。

进一步地，文件处理方法还包括：根据第二文件队列中的垃圾文件记录确定目标文件，其中，目标文件为第二文件队列所对应的所有待删除文件中文件序号最小的文件，文件序号用于表征待删除文件的删除顺序；根据目标文件更新游标信息，得到目标游标信息，其中，目标游标信息表征在执行下一次删除操作时，目标文件为第一个待删除文件；更新第二文件队列中的每个垃圾文件记录所对应的文件的数据量，得到目标数据量；将第三文件队列中的每个垃圾文件记录所对应的文件的数据量更新为0；根据目标数据量以及目标游标信息更新元数据信息。

进一步地，文件处理方法还包括：在根据目标文件更新游标信息，得到目标游标信息时，根据目标游标信息以及游标信息确定待删除的垃圾文件记录；删除待删除的垃圾文件记录。

进一步地，文件处理方法还包括：在更新元数据信息之后，清零删除数据总量，并在下一次删除操作完成之后重新计算删除数据总量；清空第一文件队列中的垃圾文件记录和第三文件队列中的垃圾文件记录。

进一步地，文件处理方法还包括：在更新元数据信息之后，检测用于管理数据库集群的分布式文件系统是否出现异常并且进行了重启；在分布式文件系统重启成功之后，根据目标游标信息对数据库集群中剩余的待删除文件进行删除。

进一步地，文件处理方法还包括：接收文件处理终止请求，其中，文件处理终止请求用于请求在预设时长内终止正在执行的文件处理请求；根据预设时长确定最大等待时长，其中，最大等待时长小于预设时长；检测在最大等待时长内已经完成删除操作的第一待删除文件；获取第一待删除文件的最新数据量；根据最新数据量更新元数据信息；禁止执行新的文件处理请求。

进一步地，文件处理方法还包括：在根据预设时长确定最大等待时长之后，检测在最大等待时长内是否完成了对元数据信息的更新操作；若在最大等待时长内完成了对元数据信息的更新操作，生成第一回复信息，其中，第一回复信息表征文件处理请求已经完成。

根据本申请实施例的另一方面，还提供了一种文件处理装置，包括：接收模块，用于接收文件处理请求，其中，文件处理请求中至少包含游标信息，游标信息用于标识数据库集群中的第一个待删除文件；删除模块，用于按照预设的删除顺序，根据游标信息采用并行删除的方式对数据库集群中的至少一个待删除文件的部分文件数据进行删除，其中，部分文件数据的数据量小于或等于预设数据量，在删除每个待删除文件时，从每个待删除文件的尾部开始从后往前删除文件数据；更新模块，用于在每次删除操作完成之后，统计删除数据总量，并在删除数据总量大于或等于预设阈值时，更新元数据信息，其中，元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。

根据本申请实施例的另一方面，还提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述的文件处理方法。

根据本申请实施例的另一方面，还提供了一种电子设备，包括一个或多个处理器和存储器，存储器用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现上述的文件处理方法。

在本申请中，采用对数据库集群中的待删除文件进行并行删除的方式，首先接收文件处理请求，其中，文件处理请求中至少包含游标信息，游标信息用于标识数据库集群中的第一个待删除文件。然后按照预设的删除顺序，根据游标信息采用并行删除的方式对数据库集群中的至少一个待删除文件的部分文件数据进行删除，在每次删除操作完成之后，统计删除数据总量，并在删除数据总量大于或等于预设阈值时，更新元数据信息。其中，部分文件数据的数据量小于或等于预设数据量，在删除每个待删除文件时，从每个待删除文件的尾部开始从后往前删除文件数据；元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。

由上述内容可知，本申请一方面将依次逐个文件删除的方式改变为了并行删除的方式，在每次删除操作时，同时删除至少一个待删除文件，从而解决了现有技术中由于无法同时删除多个文件，导致文件删除效率较低的问题。另一方面，本申请还改变了针对每个文件的数据删除方式，从每个待删除文件的尾部开始从后往前删除文件数据，并且在删除数据总量大于或等于预设阈值时，更新游标信息以及每个待删除文件剩余的数据量，换言之，本申请及时记录了当前待删除的文件是哪一个文件，即便分布式文件系统重新启动之后，分布式文件系统也可以基于最新的目标游标信息继续删除剩余的待删除文件，而不会再对已经删除的文件进行重新检索，从而进一步提高了文件删除的效率。

由此可见，本申请的技术方案达到了避免对已删除的文件进行重新检索的目的，从而实现了提高文件删除效率的效果，进而解决了现有技术中垃圾文件删除效率低的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种可选的文件处理方法的流程图；

图2是根据本申请实施例的一种垃圾文件删除示意图；

图3是根据本申请实施例的一种可选的垃圾文件删除流程图；

图4是根据本申请实施例的一种可选的文件处理装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本申请实施例，提供了一种文件处理方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

为了更清楚的介绍本申请实施例中的技术方案，以下针对本申请实施例中使用到的一些名词进行解释：

分布式文件系统：一种对外提供文件接口语义的存储系统，用于将数据分散存储到多个存储服务器上，并将这些分散的存储资源构成一个虚拟的存储设备；

mds：meta data system，元数据系统，一种用于管理、存储、分发分布式文件系统中的元数据信息的守护进程；

垃圾文件：被分布式文件系统删除了元数据，但是文件数据还存储在数据库集群中的文件，垃圾文件是一种不可以恢复的文件；

垃圾回收空间：用于持久化垃圾文件记录的存储空间，其中，一条垃圾文件记录记录有一个垃圾文件的文件信息；

垃圾回收：垃圾文件被删除时元数据空间已经被释放，但是数据空间还未释放。垃圾回收就是一种释放数据占用的空间，同时删除垃圾回收空间中相应的垃圾文件记录的删除操作；

图1是根据本申请实施例的一种可选的文件处理方法的流程图，如图1所示，该方法包括如下步骤：

步骤S101，接收文件处理请求。

在步骤S101中，文件处理请求中至少包含游标信息，游标信息用于标识数据库集群中的第一个待删除文件。

具体的，分布式文件系统所管理的数据库集群中可能存在多个垃圾文件，其中，垃圾文件的元数据已经被分布式文件系统删除，但是垃圾文件的文件数据仍然留存在数据库集群中。

需要说明的是，在分布式文件系统中的文件包括元数据以及数据两部分组成，数据可以理解为是一个文件的文件数据，元数据则是用于描述文件数据的数据，例如，描述文件数据的修改时间，文件数据量大小以及文件数据的权限所属信息等等。为了提高删除效率，在用户通过分布式文件系统删除一个文件时，分布式文件系统会先将该文件的元数据删除，以便在用户从用户视角看来，该文件已经被删除了，而由于文件数据可能较大，因此，分布式文件系统后续会将该文件的文件数据从数据库集群中删除。为了记录这些已经被删除了元数据的垃圾文件，分布式文件系统中设置有垃圾回收空间，用于存储垃圾文件记录，其中，垃圾文件记录中记录了每个垃圾文件的文件信息，例如，垃圾文件在数据库集群中的所在位置，垃圾文件的文件数据大小等等。

另外，分布式文件系统在删除垃圾文件之前，首先接收文件处理请求，该文件处理请求可以是分布式文件系统的定时任务，即每间隔预设时间周期自动生成一个文件处理请求，也可以是用户自行在分布式文件系统中手动创建的文件处理请求，例如，通过命令行的方式创建文件处理请求。文件处理请求中至少包含有游标信息，用于标识本次删除垃圾文件过程中第一个待删除文件，例如，数据库集群中包含有000-999共1000个垃圾文件，游标信息指向了000这一个垃圾文件，则说明在本次删除过程中，000这一个垃圾文件为第一个待删除文件。

步骤S102，按照预设的删除顺序，根据游标信息采用并行删除的方式对数据库集群中的至少一个待删除文件的部分文件数据进行删除。

在步骤S102中，部分文件数据的数据量小于或等于预设数据量，在删除每个待删除文件时，从每个待删除文件的尾部开始从后往前删除文件数据。其中，预设数据量为预设数量以及固定数据量的乘积，预设数量为每次删除操作所能够删除的最大文件数量，固定数据量为每次删除操作时对一个待删除文件能够进行删除的最大数据量。

具体的，预设的删除顺序是从前往后的删除顺序，该删除顺序可以理解为是文件的删除顺序，例如，根据垃圾文件的序号排序，在第一个待删除文件为序号000的垃圾文件时，接下来要选择的待删除文件则是001、002、003等依次排序的垃圾文件。另外，在本申请中，分布式文件系统采用的是并行删除的方式删除垃圾文件，换言之，每次删除操作可以同时删除多个待删除文件，例如，每次同时选择10个待删除文件执行删除操作。

此外，需要说明的是，为了提高删除效率，在本申请中，单一垃圾文件的最大删除数据量要小于或等于固定数据量，并且，与现有技术从垃圾文件的头部开始从前往后删除文件数据不同，本申请采用的是从垃圾文件的尾部开始从后往前进行删除的方式删除每个垃圾文件的文件数据。

可选的，在每次对待删除文件进行删除时，分布式文件系统首先确定待删除文件还未被删除的文件数据的数据量为待删除数据量，并且在待删除数据量大于或等于固定数据量时，从待删除文件的尾部开始从后往前删除固定数据量的文件数据，其中，固定数据量为每次删除操作时对一个待删除文件能够进行删除的最大数据量；在待删除数据量小于固定数据量时，将待删除文件全部删除。

其中，图2示出了根据本申请实施例的一种垃圾文件删除示意图，如图2所示，假设一次垃圾回收(对应一个文件处理请求)从垃圾回收空间读取了100条垃圾文件记录，按照设定，最大并发处理垃圾文件的数量为4，即每次最多可以选择4个垃圾文件进行删除，同时，按照设定，单一文件的最大删除数据量(即固定数据量)为16MiB，从每个文件的尾部开始从后往前进行删除。在图2中，同时选择了file_01、file_02、file_03、file_04四个垃圾文件进行并行删除，其中，file_1的总文件数据量为32GiB，file_02的总文件数据量为4KiB，file_03的总文件数据量为32GiB、file_04的总文件数据量为4MiB，斜线部分表示本次删除的数据量，具体的，由于file_01和file_03的总文件数量大于16MiB，因此，这两个垃圾文件本次删除的数据量为固定数据量16MiB；由于file_02和file_04的总文件数据量小于16MiB，因此，本次删除过程中可以将这两个垃圾文件的文件数据全部删除。需要注意到的是，由于设定了预设数量以及固定数据量，因此，预设数据量可以是预设数量以及固定数据量的乘积。

另外，还需要注意到的是，现有技术中依次逐个对垃圾文件进行删除处理是基于数据库集群的数据组织方式，即同一个垃圾文件的所有数据块可能属于一个归置组，如果采用依次逐个处理的方式，可能导致大量的删除操作落到同一个归置组，同一个归置组内的操作可能是串行的，或者存在资源竞争关系，从而影响删除文件数据的效率。本申请采用并发处理的方式对多个垃圾文件同时进行数据删除，各个垃圾文件之间的数据块属于哪个归置组是完全随机的，从而可以充分发挥数据库集群的处理能力，避免某个或某些归置组成为瓶颈，进而提高了文件数据的删除效率。

步骤S103，在每次删除操作完成之后，统计删除数据总量，并在删除数据总量大于或等于预设阈值时，更新元数据信息。

在步骤S103中，元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。具体的，在现有技术中，分布式文件系统在出现异常并且重新启动之后，由于游标信息不会更新，因此需要重新检测每个文件，从而导致一些已经被删除的文件会被重新检索，造成文件删除效率较低的问题。为了解决该问题，本申请在删除数据总量大于或等于预设阈值之后，会触发元数据信息更新机制，其中，元数据信息为垃圾回收空间的元数据信息，该元数据信息具体包括：最新的目标游标信息，即下次从哪一个垃圾文件开始进行删除；各个垃圾文件的最新的数据量信息；将删除失败的异常文件的垃圾文件记录重新插入垃圾回收空间中。

可选的，上述的预设阈值可以自定义设置，本申请实施例中对此不作特殊限定。需要注意到的是，在现有技术中，尤其是在针对文件数据量较大的文件进行垃圾回收时，如果分布式文件系统读取了100条垃圾文件记录，并依次对这100个垃圾文件进行垃圾回收，但是操作过程中分布式文件系统的主mds进程由于软件异常或者其他原因意外退出，此时的主mds会发生切换，新的主mds依然会从上次垃圾文件游标处读取100条记录，此时会有大量已经被删除的文件数据(数据库kv键值对)被重新尝试搜索并进行二次删除，从而不仅会增加不必要的垃圾回收耗时，还会导致严重的搜索效率下降的问题。

为了解决上述现有技术的问题，本申请通过改变每个文件的数据删除方式，从每个待删除文件的尾部开始从后往前删除文件数据，并且在删除数据总量大于或等于预设阈值时，更新游标信息以及每个待删除文件剩余的数据量，从而确保了分布式文件系统最大可能地及时记录下次待删除的文件是哪一个文件，即便分布式文件系统重新启动之后，分布式文件系统也可以基于最新的目标游标信息继续删除剩余的待删除文件以及继续删除剩余的文件数据，而不会再对已经删除的文件和数据进行重新检索，进而实现了进一步地提高文件删除效率的效果。

基于上述步骤S101至步骤S103的内容可知，在本申请中，采用对数据库集群中的待删除文件进行并行删除的方式，首先接收文件处理请求，其中，文件处理请求中至少包含游标信息，游标信息用于标识数据库集群中的第一个待删除文件。然后按照预设的删除顺序，根据游标信息采用并行删除的方式对数据库集群中的至少一个待删除文件的部分文件数据进行删除，在每次删除操作完成之后，统计删除数据总量，并在删除数据总量大于或等于预设阈值时，更新元数据信息。其中，部分文件数据的数据量小于或等于预设数据量，在删除每个待删除文件时，从每个待删除文件的尾部开始从后往前删除文件数据；元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。

由上述内容可知，本申请一方面将依次逐个文件删除的方式改变为了并行删除的方式，在每次删除操作时，同时删除至少一个待删除文件，从而解决了现有技术中由于无法同时删除多个文件，导致文件删除效率较低的问题，另一方面，本申请还改变了针对每个文件的数据删除方式，从每个待删除文件的尾部开始从后往前删除文件数据，并且在删除数据总量大于或等于预设阈值时，更新游标信息以及每个待删除文件剩余的数据量，换言之，本申请及时记录了当前待删除的文件是哪一个文件，即便分布式文件系统重新启动之后，分布式文件系统也可以基于最新的目标游标信息继续删除剩余的待删除文件，而不会再对已经删除的文件进行重新检索，从而实现了进一步地提高文件删除效率的效果。

由此可见，本申请的技术方案达到了避免对已删除的文件进行重新检索的目的，从而实现了提高文件删除效率的效果，进而解决了现有技术中垃圾文件删除效率低的技术问题。

在一种可选的实施例中，分布式文件系统按照预设的删除顺序，从数据库集群中确定预设数量的待删除文件，然后采用并行删除的方式对预设数量的待删除文件进行删除，其中，在删除过程中包括至少一次删除操作，每次删除操作所删除的最大文件数据量为预设数据量。

可选的，假设一次垃圾回收从垃圾回收空间读取了000-999共1000条垃圾文件记录，预设数量为10，每个垃圾文件在一次删除操作时最多删除的固定数据量为16MiB,则按照预设的删除顺序，分布式文件系统每次都选择10个垃圾文件同时进行文件数据的删除，并且，每次删除操作时，最多删除的文件数据量(即预设数据量)为16MiB*10＝160MiB。

在一种可选的实施例中，在每次对待删除文件进行删除操作时，分布式文件系统会检测待删除文件在删除过程中是否存在异常，在待删除文件在删除过程中存在异常时，分布式文件系统确定待删除文件为异常文件，并将异常文件对应的垃圾文件记录移动至第一文件队列中。

其中，第一文件队列中的垃圾文件记录所对应的文件全部为删除失败的文件。

可选的，图3示出了根据本申请实施例的一种可选的垃圾文件删除流程图，如图3所示，首先分布式文件系统从垃圾回收空间遍历垃圾文件记录，并按照设定的最大的并发文件处理数量(即预设数量，假设为4)以及预设的删除顺序选择垃圾文件进行处理，其中，被选择的垃圾文件所对应的垃圾文件记录首先进入了“活跃文件的index队列”中，index为文件序号。如图3所示，假设被选择的垃圾文件为文件1、文件2、文件3以及文件4。

可选的，在将文件1、文件2、文件3以及文件4所对应的4个垃圾文件记录加入至“活跃文件的index队列”中之后，分布式文件系统向数据库集群发送数据删除处理请求，数据库集群在接收到数据删除处理请求之后，同时对四个垃圾文件的文件数据进行删除，如果某一个垃圾文件删除失败，则分布式文件系统会确定该垃圾文件为异常文件，并将该垃圾文件的垃圾文件记录移动至第一文件队列中。其中，如图3所示，文件2在删除过程中出现异常，因此，分布式文件系统将文件2移动至“失败文件的index队列”中，“失败文件的index队列”即为第一文件队列。

在一种可选的实施例中，在每次对待删除文件进行删除操作时，分布式文件系统还会检测待删除文件的文件数据是否已经被全部删除，在待删除文件的文件数据未被全部删除的情况下，将待删除文件对应的垃圾文件记录移动至第二文件队列中；在待删除文件的文件数据已经被全部删除的情况下，将待删除文件对应的垃圾文件记录移动至第三文件队列中。其中，第二文件队列中的垃圾文件记录所对应的文件为在下一次删除操作时所要删除的文件。

如图3所示，文件4在本次删除操作中已经将所有的文件数据删除，即文件4最新的文件数据大小为0，在此基础上，分布式文件系统将文件4对应的垃圾文件记录移动至“size＝0文件的index队列”中，其中，“size＝0文件的index队列”为上述的第三文件队列。

另外。有一些垃圾文件的文件数据量很大，在本次删除操作中文件数据无法被完全删除(即文件数据的数据量大于固定数据量)，例如，图3中的文件1与文件3即为在本次删除操作中文件数据未完全删除的垃圾文件，因此，文件1的垃圾文件记录与文件3的垃圾文件记录仍然继续保留在“活跃文件的index队列”中，同时，分布式文件系统还会按照预设的删除顺序继续选择新的垃圾文件记录进入至“活跃文件的index队列”中，例如图3中的文件5的垃圾文件记录与文件6的垃圾文件记录。其中，“活跃文件的index队列”为第二文件队列。

在一种可选的实施例中，分布式文件系统还会根据第二文件队列中的垃圾文件记录确定目标文件，其中，目标文件为第二文件队列所对应的所有待删除文件中文件序号最小的文件，文件序号用于表征待删除文件的删除顺序。然后，分布式文件系统根据目标文件更新游标信息，得到目标游标信息，其中，目标游标信息表征在执行下一次删除操作时，目标文件为第一个待删除文件。同时，分布式文件系统还会更新第二文件队列中的每个垃圾文件记录所对应的文件的数据量，得到目标数据量，并且将第三文件队列中的每个垃圾文件记录所对应的文件的数据量更新为0。最后，分布式文件系统根据目标数据量以及目标游标信息更新元数据信息。

可选的，如图3所示，如果已经删除的文件数据的数据量达到了预设阈值，则分布式文件系统将更新垃圾回收空间的元数据信息，更新内容至少包括：更新“活跃文件的index队列”中的每个垃圾文件记录所对应的文件的数据量，得到每个文件最新的剩余的目标数据量；将“size＝0文件的index队列”中每个垃圾文件记录对应的垃圾文件的数据量更新为0；将“失败文件的index队列”中的异常文件对应的垃圾文件记录重新写入垃圾回收空间中。其中，将异常文件对应的垃圾文件记录重新写入垃圾回收空间中，是为了将删除失败的文件在延迟一段时间之后重新进行删除处理。

另外，在删除数据总量大于或等于预设阈值时，分布式文件系统还会检测第二文件队列所对应的目标文件，其中，目标文件为第二文件队列所对应的所有文件中文件序号最小的文件。然后分布式文件系统根据目标文件更新游标信息，得到目标游标信息。例如，在图3中，第一次删除数据总量达到预设阈值时，“活跃文件的index队列”所对应的目标文件为文件1，由于旧的游标信息中表征第一个待删除文件也是文件1，因此，此时分布式文件系统不会对游标信息进行更新。但是，在第二次删除数据总量达到预设阈值时，“活跃文件的index队列”所对应的目标文件为文件5，则此时分布式文件系统将对游标信息进行更新，最新的目标游标信息表征文件5为下一次删除操作中的第一个待删除文件。

在一种可选的实施例中，在更新元数据信息之后，分布式文件系统还会清零删除数据总量，并在下一次删除操作完成之后重新计算删除数据总量。同时，分布式文件系统还会清空第一文件队列中的垃圾文件记录和第三文件队列中的垃圾文件记录。

可选的，如图3所示，每次对垃圾回收空间的元数据信息进行更新之后，分布式文件系统都会清空“size＝0文件的index队列”以及“失败文件的index队列”。然后，分布式文件系统将删除数据总量清零，并继续向数据库集群发送数据删除处理请求，在删除数据总量再次达到预设阈值之后，分布式文件系统对垃圾回收空间的元数据信息进行第二次更新。在图3中，在删除数据总量再次达到预设阈值时，“size＝0文件的index队列”中的垃圾文件记录分别对应的垃圾文件是文件1与文件3，“活跃文件的index队列”对应的垃圾文件分别为文件5、文件6、文件7以及文件8。需要注意到的是，删除失败的异常文件也可以视为已经被处理完成，因此，此时的文件1、文件2、文件3以及文件4已经被全部处理完成，在此基础上，本次元数据更新时，除了更新文件数据量之外，还需要更新游标信息，最新的目标游标信息中表征文件5为下一次删除操作中的第一个待删除文件。

另外，在根据目标文件更新游标信息，得到目标游标信息时，分布式文件系统会根据目标游标信息以及游标信息确定待删除的垃圾文件记录；删除待删除的垃圾文件记录。

可选的，在一个垃圾文件的文件数据全部被删除之后，该垃圾文件对应的垃圾文件记录也可以被删除，具体的，为了保证垃圾文件记录的连续性，分布式文件系统会根据旧的游标信息以及新的游标信息(即目标游标信息)确定待删除的垃圾文件记录，例如，如图3所示，旧的游标信息指向的垃圾文件为文件1，新的游标信息指向的垃圾文件为文件4，则分布式文件系统可确定文件1的垃圾文件记录、文件2的垃圾文件记录以及文件3的垃圾文件记录为待删除的垃圾文件记录，分布式文件系统将在垃圾回收空间中删除这3条垃圾文件记录。

最后，如图3所示，在完成第二次的元数据信息更新之后，分布式文件系统还将继续处理“活跃文件的index队列”中的垃圾文件记录所对应的垃圾文件，直至本次的100个垃圾文件全部被处理完成，最后在100个垃圾文件全部被处理完成之后，还需要更新一次元数据信息。其中，最后一次更新只需要更新删除失败的垃圾文件以及游标信息即可。

在一种可选的实施例中，本申请中的分布式文件系统还可以引入熔断机制，具体的，如果异步更新完成较慢，则需要在达到熔断标准后，将最新提交的异步更新变更为同步更新，避免实际删除的数据量与垃圾回收空间的元数据记录的差距过大，从而最终避免垃圾回收被中断恢复后引入大量尝试搜索、二次删除已经被删除的数据块(数据库kv键值对)的请求，导致回收操作性能下降。

例如，上述的熔断机制可以定义为，如果异步更新队列中同时存在大于或等于3个元数据信息更新请求(包括最新即将待提交的元数据信息更新请求)，其中，每个元数据信息更新请求都是异步的，即说明此时有2个异步更新请求尚未完成。在此基础上，假设熔断机制的触发标准就是3个异步更新请求，则第三个元数据信息更新请求将变更为同步请求，即元数据信息更新完成后，分布式文件系统才能再继续向数据库集群发送数据删除处理请求。

在一种可选的实施例中，分布式文件系统还设置有自检插件，其中，自检插件用于检测分布式文件系统是否出现异常并且进行了重启，在分布式文件系统重启成功之后，分布式文件系统将根据目标游标信息对数据库集群中剩余的待删除文件进行删除。

可选的，与现有技术中在每次分布式文件系统出现异常重启之后都需要重新搜索已经删除过的垃圾文件和文件数据不同，本申请的分布式文件系统在异常重启之后，会根据最新的元数据信息确定剩余的待删除文件以及待删除的文件数据，从而避免了重复搜索的过程，进而提升了垃圾文件的删除效率。

在一种可选的实施例中，分布式文件系统还可以接收文件处理终止请求，其中，文件处理终止请求用于请求在预设时长内终止正在执行的文件处理请求。分布式文件系统首先根据预设时长确定最大等待时长，然后检测在最大等待时长内已经完成删除操作的第一待删除文件，并获取第一待删除文件的最新数据量，从而根据最新数据量更新元数据信息，同时禁止执行新的文件处理请求。其中，最大等待时长小于预设时长。

可选的，mds组成的数据库集群在检测到拓扑结构发生变化时，需要立刻进行mds间元数据信息的对比和同步的工作，因此要求外部和内部的请求在可控的时间范围内完成或被放弃。垃圾回收作为内部请求，也需要满足上述要求。

本申请为了保证在预设时长内终止正在执行的文件处理请求，在接收到文件处理终止请求之后，首先会禁止分布式文件系统执行新的文件处理请求(包括禁止接收自动生成的新的文件处理请求以及禁止处理用户手动创建的新的文件处理请求)，然后对于已经正在处理中的文件处理请求(即垃圾回收请求)，分布式文件系统会根据预设时长确定最大等待时长，例如，最大等待时长可以是预设时长的一半。其中，在最大等待时长内，如果文件处理请求已经全部返回，即文件处理请求对应的所有待删除文件都已经完成了删除操作，则分布式文件系统使用每个待删除文件的最新数据量更新垃圾回收空间的元数据信息，同时，分布式文件系统还需要根据“活跃文件的index队列”中所对应的目标文件确定是否需要更新游标信息。如果文件处理请求没有全部返回，对于未返回的待删除文件将直接使用本次删除操作之前的最新数据量对元数据信息进行更新，同时，分布式文件系统还需要根据“活跃文件的index队列”中所对应的目标文件确定是否需要更新游标信息。最后，对于超过最大等待时长之后返回的文件处理请求，将不再触发垃圾回收空间的元数据信息更新，但是，分布式文件系统会保留返回记录，并将返回记录作为后续元数据信息更新的依据。

在一种可选的实施例中，元数据信息更新是在mds集群之间进行更新的操作，也可能出现由于网络、磁盘故障或者软件问题导致的更新操作延迟，因此这里也需要根据最大等待时长确定元数据更新操作的终止时间。具体的，在根据预设时长确定最大等待时长之后，分布式文件系统检测在最大等待时长内是否完成了对元数据信息的更新操作，若在最大等待时长内完成了对元数据信息的更新操作，分布式文件系统生成第一回复信息，其中，第一回复信息表征文件处理请求已经完成。可选的，如果在最大等待时长内，元数据信息更新完成，则分布式文件系统将立刻生成第一回复信息，并上报主mds本次垃圾回收操作完成。如果在最大等待时长内元数据信息更新没有完成，则分布式文件系统将释放元数据更新队列中的请求资源，此后如果元数据信息更新在各个mds上都完成，也由于元数据更新队列中不存在相应请求记录，不会触发向数据库集群发送数据删除处理请求(异步请求不会触发，只有异步退化为同步请求时才会触发)。最后，分布式文件系统直接上报主mds本次垃圾回收操作完成。

由上述内容可知，某些场景下，主mds需要主动终止垃圾回收流程，比如mds的拓扑结构发生变更时，各个mds需要将自身所有外部(客户端)和内部(如垃圾回收、回收站后台自动删除过期文件等)请求全部终止后，进行mds间的信息同步，这就要求垃圾回收流程需要做到快速可被终止。本申请通过根据预设时长确定最大等待时长，并在最大等待时长内及时终止正在执行的文件处理请求，为用户提供了主动终止垃圾回收的功能，有利于提高用户使用体验。

实施例2

根据本申请实施例的另一方面，还提供了一种文件处理装置，其中，图4是根据本申请实施例的一种可选的文件处理装置的示意图。如图4所示，该装置包括：接收模块401、删除模块402以及更新模块403。

其中，接收模块401，用于接收文件处理请求，其中，文件处理请求中至少包含游标信息，游标信息用于标识数据库集群中的第一个待删除文件；删除模块402，用于按照预设的删除顺序，根据游标信息采用并行删除的方式对数据库集群中的至少一个待删除文件的部分文件数据进行删除，其中，部分文件数据的数据量小于或等于预设数据量，在删除每个待删除文件时，从每个待删除文件的尾部开始从后往前删除文件数据；更新模块403，用于在每次删除操作完成之后，统计删除数据总量，并在删除数据总量大于或等于预设阈值时，更新元数据信息，其中，元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。

需要说明的是，上述接收模块401、删除模块402以及更新模块403对应于上述实施例中的步骤S101至步骤S103，三个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。

可选的，删除模块还包括：第一确定单元以及第一删除单元。其中，第一确定单元，用于按照预设的删除顺序，从数据库集群中确定预设数量的待删除文件；第一删除单元，用于采用并行删除的方式对预设数量的待删除文件进行删除，其中，在删除过程中包括至少一次删除操作，每次删除操作所删除的最大文件数据量为预设数据量。

可选的，第一删除单元还包括：第一删除子模块、第一确定子模块以及第一移动子模块。其中，第一删除子模块，用于在每次对待删除文件进行删除操作时，检测待删除文件在删除过程中是否存在异常；第一确定子模块，用于在待删除文件在删除过程中存在异常时，确定待删除文件为异常文件；第一移动子模块，用于将异常文件对应的垃圾文件记录移动至第一文件队列中。

可选的，第一删除单元还包括：第一检测子模块、第二移动子模块以及第三移动子模块。其中，第一检测子模块，用于在每次对待删除文件进行删除操作时，检测待删除文件的文件数据是否已经被全部删除；第二移动子模块，用于在待删除文件的文件数据未被全部删除的情况下，将待删除文件对应的垃圾文件记录移动至第二文件队列中；第三移动子模块，用于在待删除文件的文件数据已经被全部删除的情况下，将待删除文件对应的垃圾文件记录移动至第三文件队列中。

可选的，第一删除单元还包括：第二确定子模块、第二删除子模块以及第三删除子模块。其中，第二确定子模块，用于在每次对待删除文件进行删除时，确定待删除文件还未被删除的文件数据的数据量为待删除数据量；第二删除子模块，用于在待删除数据量大于或等于固定数据量时，从待删除文件的尾部开始从后往前删除固定数据量的文件数据，其中，固定数据量为每次删除操作时对一个待删除文件能够进行删除的最大数据量；第三删除子模块，用于在待删除数据量小于固定数据量时，将待删除文件全部删除。

可选的，上述更新模块还包括：第二确定单元、第一更新单元、第二更新单元、第三更新单元以及第四更新单元。其中，第二确定单元，用于根据第二文件队列中的垃圾文件记录确定目标文件，其中，目标文件为第二文件队列所对应的所有待删除文件中文件序号最小的文件，文件序号用于表征待删除文件的删除顺序；第一更新单元，用于根据目标文件更新游标信息，得到目标游标信息，其中，目标游标信息表征在执行下一次删除操作时，目标文件为第一个待删除文件；第二更新单元，用于更新第二文件队列中的每个垃圾文件记录所对应的文件的数据量，得到目标数据量；第三更新单元，用于将第三文件队列中的每个垃圾文件记录所对应的文件的数据量更新为0；第四更新单元，用于根据目标数据量以及目标游标信息更新元数据信息。

可选的，文件处理装置还包括：确定模块以及第一删除模块。其中，确定模块，用于在根据目标文件更新游标信息，得到目标游标信息时，根据目标游标信息以及游标信息确定待删除的垃圾文件记录；第一删除模块，用于删除待删除的垃圾文件记录。

可选的，文件处理装置还包括：清零模块以及清空模块，其中，清零模块，用于清零删除数据总量，并在下一次删除操作完成之后重新计算删除数据总量；清空模块，用于清空第一文件队列中的垃圾文件记录和第三文件队列中的垃圾文件记录。

可选的，文件处理装置还包括：第一检测模块以及第二删除模块。其中，第一检测模块，用于检测用于管理数据库集群的分布式文件系统是否出现异常并且进行了重启；第二删除模块，用于在分布式文件系统重启成功之后，根据目标游标信息对数据库集群中剩余的待删除文件进行删除。

可选的，文件处理装置还包括：第一接收模块、第一确定模块、第二检测模块、获取模块、第一更新模块以及禁止执行模块。其中，第一接收模块，用于接收文件处理终止请求，其中，文件处理终止请求用于请求在预设时长内终止正在执行的文件处理请求；第一确定模块，用于根据预设时长确定最大等待时长，其中，最大等待时长小于预设时长；第二检测模块，用于检测在最大等待时长内已经完成删除操作的第一待删除文件；获取模块，用于获取第一待删除文件的最新数据量；第一更新模块，用于根据最新数据量更新元数据信息；禁止接收模块，用于禁止执行新的文件处理请求。

可选的，文件处理装置还包括：第三检测模块以及生成模块。其中，第三检测模块，用于检测在最大等待时长内是否完成了对元数据信息的更新操作；生成模块，用于若在最大等待时长内完成了对元数据信息的更新操作，生成第一回复信息，其中，第一回复信息表征文件处理请求已经完成。

实施例3

根据本申请实施例的另一方面，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述实施例1中的文件处理方法。

实施例4

根据本申请实施例的另一方面，还提供了一种电子设备，该电子设备包括一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现用于运行程序，其中，程序被设置为运行时执行上述实施例1中的文件处理方法。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (14)

1.一种文件处理方法，其特征在于，包括：

接收文件处理请求，其中，所述文件处理请求中至少包含游标信息，所述游标信息用于标识数据库集群中的第一个待删除文件；

按照预设的删除顺序，根据游标信息采用并行删除的方式对所述数据库集群中的至少一个待删除文件的部分文件数据进行删除，其中，所述部分文件数据的数据量小于或等于预设数据量，在删除每个待删除文件时，从所述每个待删除文件的尾部开始从后往前删除文件数据；

在每次删除操作完成之后，统计删除数据总量，并在所述删除数据总量大于或等于预设阈值时，更新元数据信息，其中，所述元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，所述目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。

2.根据权利要求1所述的方法，其特征在于，按照预设的删除顺序，根据游标信息采用并行删除的方式对所述数据库集群中的至少一个待删除文件的部分文件数据进行删除，包括：

按照所述预设的删除顺序，从所述数据库集群中确定预设数量的待删除文件；

采用并行删除的方式对所述预设数量的待删除文件进行删除，其中，在删除过程中包括至少一次删除操作，每次删除操作所删除的最大文件数据量为所述预设数据量。

3.根据权利要求2所述的方法，其特征在于，采用并行删除的方式对所述预设数量的待删除文件进行删除，包括：

在每次对所述待删除文件进行删除操作时，检测所述待删除文件在删除过程中是否存在异常；

在所述待删除文件在删除过程中存在异常时，确定所述待删除文件为异常文件；

将所述异常文件对应的垃圾文件记录移动至第一文件队列中。

4.根据权利要求3所述的方法，其特征在于，采用并行删除的方式对所述预设数量的待删除文件进行删除，包括：

在每次对所述待删除文件进行删除操作时，检测所述待删除文件的文件数据是否已经被全部删除；

在所述待删除文件的文件数据未被全部删除的情况下，将所述待删除文件对应的垃圾文件记录移动至第二文件队列中；

在所述待删除文件的文件数据已经被全部删除的情况下，将所述待删除文件对应的垃圾文件记录移动至第三文件队列中。

5.根据权利要求2所述的方法，其特征在于，采用并行删除的方式对所述预设数量的待删除文件进行删除，包括：

在每次对所述待删除文件进行删除时，确定所述待删除文件还未被删除的文件数据的数据量为待删除数据量；

在所述待删除数据量大于或等于固定数据量时，从所述待删除文件的尾部开始从后往前删除所述固定数据量的文件数据，其中，所述固定数据量为每次删除操作时对一个待删除文件能够进行删除的最大数据量；

在所述待删除数据量小于所述固定数据量时，将所述待删除文件全部删除。

6.根据权利要求4所述的方法，其特征在于，在所述删除数据总量大于或等于预设阈值时，更新元数据信息，包括：

根据所述第二文件队列中的垃圾文件记录确定目标文件，其中，所述目标文件为所述第二文件队列所对应的所有待删除文件中文件序号最小的文件，所述文件序号用于表征所述待删除文件的删除顺序；

根据所述目标文件更新所述游标信息，得到所述目标游标信息，其中，所述目标游标信息表征在执行下一次删除操作时，所述目标文件为第一个待删除文件；

更新所述第二文件队列中的每个垃圾文件记录所对应的文件的数据量，得到所述目标数据量；

将所述第三文件队列中的每个垃圾文件记录所对应的文件的数据量更新为0；根据所述目标数据量以及所述目标游标信息更新所述元数据信息。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

在根据所述目标文件更新所述游标信息，得到所述目标游标信息时，根据所述目标游标信息以及所述游标信息确定待删除的垃圾文件记录；

删除所述待删除的垃圾文件记录。

8.根据权利要求7所述的方法，其特征在于，在更新元数据信息之后，所述方法还包括：

清零所述删除数据总量，并在下一次删除操作完成之后重新计算所述删除数据总量；

清空所述第一文件队列中的垃圾文件记录和所述第三文件队列中的垃圾文件记录。

9.根据权利要求1所述的方法，其特征在于，在更新元数据信息之后，所述方法还包括：

检测用于管理所述数据库集群的分布式文件系统是否出现异常并且进行了重启；

在所述分布式文件系统重启成功之后，根据所述目标游标信息对所述数据库集群中剩余的待删除文件进行删除。

10.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收文件处理终止请求，其中，所述文件处理终止请求用于请求在预设时长内终止正在执行的文件处理请求；

根据预设时长确定最大等待时长，其中，所述最大等待时长小于所述预设时长；

检测在所述最大等待时长内已经完成删除操作的第一待删除文件；

获取所述第一待删除文件的最新数据量；

根据所述最新数据量更新所述元数据信息；

禁止执行新的文件处理请求。

11.根据权利要求10所述的方法，其特征在于，在根据预设时长确定最大等待时长之后，所述方法还包括：

检测在所述最大等待时长内是否完成了对所述元数据信息的更新操作；

若在所述最大等待时长内完成了对所述元数据信息的更新操作，生成第一回复信息，其中，所述第一回复信息表征所述文件处理请求已经完成。

12.一种文件处理装置，其特征在于，包括：

接收模块，用于接收文件处理请求，其中，所述文件处理请求中至少包含游标信息，所述游标信息用于标识数据库集群中的第一个待删除文件；

删除模块，用于按照预设的删除顺序，根据游标信息采用并行删除的方式对所述数据库集群中的至少一个待删除文件的部分文件数据进行删除，其中，所述部分文件数据的数据量小于或等于预设数据量，在删除每个待删除文件时，从所述每个待删除文件的尾部开始从后往前删除文件数据；

更新模块，用于在每次删除操作完成之后，统计删除数据总量，并在所述删除数据总量大于或等于预设阈值时，更新元数据信息，其中，所述元数据信息至少包括最新的目标游标信息以及每个待删除文件剩余的目标数据量，所述目标游标信息用于表征在执行下一次删除操作时的第一个待删除文件。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至11任一项中所述的文件处理方法。

14.一种电子设备，其特征在于，包括一个或多个处理器和存储器，所述存储器用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至11中任意一项所述的文件处理方法。

Images