一种文件处理方法和装置与流程

本发明涉及存储技术领域，特别是涉及一种文件处理方法和一种文件处理装置。

背景技术：

随着互联网技术的发展和大数据时代的到来，出现了各种各样的云计算服务，目前的云计算服务可以将海量的文件存储在分布式文件系统中，并向应用程序提供文件获取服务。对于需要实时处理的在线应用程序而言，分布式文件系统中文件的获取性能会直接影响到其对应请求的响应时间，因此对分布式文件系统中文件的获取性能提出了较高的要求。

HDFS(Hadoop分布式文件系统，Hadoop Distributed File System)具有高容错性的特点，它将数据以一个或多个副本的形式分散存储在多台计算设备上，可以存储海量数据，并且可靠性高，提供对数据快速的、可扩展的访问，适用于一次写入、多次读取的访问模式。

发明人在实施例本发明的过程中发现，现有的HDFS是通过文件列表枚举方式获取文件的。具体地，HDFS的名称节点需要维护文件目录与数据块之间的关系、以及数据块与数据节点之间的关系，这样，在接收来自客户端的文件访问请求后，需要依据文件目录与数据块之间的关系查询组成待访问文件的数据块列表，并依据该数据块与数据节点之间的关系查询该数据块列表被存储在哪几个数据节点上，然后从查询得到的数据节点上读取待访问文件的数据。可见，现有的HDFS获取文件的过程较为繁琐，因此影响了文件的获取效率，进而影响了在线应用程序的响应性能。

发明人在实施例本发明的过程中还发现，现有的HDFS仅仅适用于一次写入、多次查询的情况，而不支持并发写的情况，这样将影响在线应用程序的吞吐量。

技术实现要素：

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种文件处理方法和一种文件处理装置。

依据本发明的一个方面，提供了一种文件处理方法，包括：

接收文件处理请求；

对所述文件处理请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息包括：文件在第二分布式文件系统上的存储路径；

依据所述待处理文件的基本信息，对所述文件处理请求进行处理。

可选地，所述文件处理请求包括：文件下载请求，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，包括：

依据所述存储路径，从所述第二分布式文件系统上读取所述待处理文件的文件内容；

下载所述待处理文件的文件内容。

可选地，所述文件处理请求包括：文件删除请求，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，包括：

依据所述存储路径，在所述第二分布式文件系统上删除所述待处理文件的文件内容；

在所述第一分布式文件系统上删除所述待处理文件的基本信息。

可选地，所述文件处理请求包括：文件状态查询请求，所述基本信息还包括文件状态信息，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，包括：

从所述待处理文件的基本信息中获取文件状态信息，并将所述文件状态信息作为处理结果返回。

可选地，所述文件处理请求包括：文件上传请求，所述基本信息还包括：上传完成标识，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，包括：

依据所述基本信息中的上传完成标识，判断是否完成所述待处理文件的上传；

当确定完成所述待处理文件的上传时，返回完成上传的处理结果。

可选地，所述基本信息还包括：处理状态标识，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，还包括：

当确定未完成所述待处理文件的上传时，依据所述基本信息中的处理状态标识判断所述待处理文件是否存在处理异常；

当确定所述待处理文件存在处理异常时，在第二文件系统上进行所述待处理文件的异常处理；

在完成所述异常处理后，依据所述待处理文件在第二文件系统上的存储状态判断所述待处理文件是否被成功上传；

当确定所述待处理文件被成功上传时，返回成功上传的处理结果。

可选地，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，还包括：

当确定所述待处理文件不存在处理异常、或者确定所述待处理文件未被成功上传时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；

在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。

可选地，所述方法还包括：

当第一分布式文件系统上不存在所述待处理文件的基本信息时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；

在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。

可选地，所述方法还包括：

接收随机扫描请求；所述随机扫描请求中携带有需要随机扫描的主键；

从第一分布式文件系统上读取所述需要随机扫描的主键对应文件在第二分布式文件系统上的存储路径；

依据所述存储路径，从所述第二分布式文件系统上获取所述需要随机扫描的主键对应文件的文件内容；

利用扫描工具进行所获取文件内容的扫描。

根据本发明的另一方面，提供了一种文件处理装置，包括：

请求接收模块，用于接收文件处理请求；

目录加锁模块，用于对所述文件处理请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

信息获取模块，用于从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息包括：文件在第二分布式文件系统上的存储路径；

请求处理模块，用于依据所述待处理文件的基本信息，对所述文件处理请求进行处理。

根据本发明实施例的一种文件处理方法和装置，当存在对于文件的处理(如访问)需求时，可以从第一分布式文件系统上获取文件在第二分布式文件系统上的存储路径，相对于现有的HDFS是通过文件列表枚举方式获取文件，可以实现待处理文件的快速定位，因此可以提高文件的处理效率，进而可以提高在线应用程序的访问性能。

并且，本发明实施例可以对待处理文件所属的文件目录进行加锁，这样，在并发访问(也即多用户同时访问)的场景下，上述加锁处理可以使得同一时刻仅有一个用户访问分布式文件，故能够有效解决多用户访问带来的访问冲突问题，进而有效保证分布式文件的一致性，因此，本发明实施例可以支持并发访问，进而提高在线应用程序的吞吐量。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文可选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出可选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的一种文件处理方法的步骤流程示意图；

图2示出了根据本发明一个实施例的一种文件处理方法的步骤流程示意图；

图3示出了根据本发明一个实施例的一种文件处理方法的步骤流程示意图；

图4示出了根据本发明一个实施例的一种文件处理方法的步骤流程示意图；

图5示出了根据本发明一个实施例的一种文件处理方法的步骤流程示意图；

图6示出了根据本发明一个实施例的一种文件处理方法的步骤流程示意图；

图7示出了根据本发明一个实施例的一种文件处理方法的步骤流程示意图；

图8示出了根据本发明一个实施例的一种文件处理方法的步骤流程示意图；以及

图9示出了根据本发明一个实施例的一种文件处理装置的结构示意。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明实施例采用第一分布式文件系统和第二分布式文件系统进行文件的存储，其中，第一分布式文件系统可用于存储文件的基本信息，如文件主键(key)、文件在第二分布式文件系统上的存储路径、文件大小、文件名、文件状态信息等信息，第二分布式文件系统可用于存储文件内容，这样，这样，当存在对于文件的处理(如访问)需求时，可以从第一分布式文件系统上获取文件在第二分布式文件系统上的存储路径，相对于现有的HDFS是通过文件列表枚举方式获取文件，可以实现待处理文件的快速定位，因此可以提高文件的处理效率，进而可以提高在线应用程序的访问性能。

并且，本发明实施例可以对待处理文件所属的文件目录进行加锁，这样，在并发访问(也即多用户同时访问)的场景下，上述加锁处理可以使得同一时刻仅有一个用户访问分布式文件，故能够有效解决多用户访问带来的访问冲突问题，进而有效保证分布式文件的一致性，因此，本发明实施例可以支持并发访问，进而提高在线应用程序的吞吐量。

参照图1，示出了根据本发明一个实施例的一种文件处理方法的步骤流程图，具体可以包括如下步骤：

步骤101、接收文件处理请求；

本发明实施例可以应用于服务端的文件处理系统中，该文件处理系统可以基于所存储的分布式文件向客户端提供文件处理服务，也可以根据业务请求对所存储的分布式文件进行维护。

在实际应用中，可以接收客户端发送的文件处理请求。可选地，上述文件处理请求可以包括如下请求中的至少一种：

文件上传请求：将预置路径的文件上传至分布式文件系统；处理结果可以包括：完成上传、上传成功、或者上传失败等；

文件状态查询请求：查询某个文件的文件状态信息；处理结果可以为查询得到的文件状态信息；

文件下载请求：下载某个文件；处理结果可以为读取得到的文件；

文件删除请求：删除某个文件；处理结果可以为删除成功或者删除失败。

可以理解，上述文件处理请求只是作为可选实施例，实际上，本领域技术人员可以根据实际应用需求，采用各种各样的文件处理请求，本发明实施例对于具体的文件处理请求不加以限制。

在实际应用中，可以针对每种文件处理请求设置对应的API(应用程序编程接口，Application Programming Interface)，并将所有的API接口集成在SDK(软件开发工具包，Software Development Kit)中，以供客户端调用，进而产生对应的文件处理请求。可选地，上述API接口可以基于HTTP(超文本传输协议，HyperText Transfer Protocol)协议，以供客户端调用。

步骤102、对所述文件处理请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

上述加锁处理可以使得同一时刻仅有一个用户访问分布式文件，故能够有效解决多用户访问带来的访问冲突问题，进而有效保证分布式文件的一致性。

本发明实施例的锁可以为分布式锁，该分布式锁可以具有高性能、避免死锁、支持锁重入等优点，以使得该分布式锁不会成为系统的性能瓶颈，且在获得锁的节点挂掉时不会导致其他节点永远无法继续等。

在本发明的一种可选实施例中，可以通过ZooKeeper(动物管理员)对所述文件处理请求对应待处理文件所属的文件目录进行加锁。ZooKeeper是一个分布式的、开放源码的分布式应用程序协调服务，其可以为分布式应用提供一致性服务。ZooKeeper包含一个简单的原语集，提供Java和C的接口。ZooKeeper的代码版本中提供了分布式独享锁的接口。在本发明的一种应用示例中，假设节点A请求加锁，其经ZooKeeper注册得到ID1，并且，节点B请求加锁，其经ZooKeeper注册得到ID2，则节点A可以获取所有节点的ID，判断出自身的ID最小，于是可以获得锁，而节点B可以获取所有节点的ID，判断出自身的ID不是最小的，于是监听ID小于自身ID的最大节点的变更事件；进一步，假设节点A在拿到锁后，进行文件处理请求的处理，并在处理完成后释放锁，也即删除自身节点；而节点B在接收到节点A的变更事件后，若判断出自身的ID最小，则可以获得锁。其中，上述节点A、节点B可以为用于处理文件处理请求的节点。

在本发明的另一种可选实施例中，可以通过Redis对所述文件处理请求对应待处理文件所属的文件目录进行加锁。Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、key-Value(键值对)数据库。在本发明的一种应用示例中，可以使用setnx(key,时间戮超时)设置锁，如果设置成功，则直接拿到锁，如果设置不成功，则获取key的值v1(它的到期时间戮)，将v1与当前时间对比，看是否已经超时，如果超时(说明拿到锁的结点已经挂掉)，v2＝getset(key,时间戮超时1)，判断v2是否等于v1，如果相等，则加锁成功，否则加锁失败，等过段时间(200MS)再重试。

可以理解，上述通过ZooKeeper或者Redis对所述文件处理请求对应待处理文件所属的文件目录进行加锁的过程只是作为可选实施例，实际上，本领域技术人员可以根据实际应用需求，采用所需的其他加锁工具，如memcached等，memcached是分布式的高速缓存系统，其带有add函数，可利用add函数的特性即可实现分布式锁。

步骤103、从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息可以包括：文件在第二分布式文件系统上的存储路径；

本发明实施例中，第一分布式文件系统和第二分布式文件系统为不同的分布式文件系统，本领域技术人员可以根据实际应用需求，选择任意的两种分布式文件系统作为第一分布式文件系统和第二分布式文件系统。例如，可以从GFS(google File System)、HBase(Hadoop Database)、HDFS、Lustre(Linux和Cluster的混成词)、Ceph(Linux PB级分布式文件系统)、GridFS(GridFS)、mogileFS(高效的文件自动备份组件)、TFS(Taobao FileSystem)、FastDFS等。

可选地，第一分布式文件系统和第二分布式文件系统可以属于同一分布式系统基础架构，以提高分布式系统基础架构的性能，且还可以避免第一分布式文件系统和第二分布式文件系统与分布式系统基础架构之间出现兼容问题。例如，本发明实施例可以采用Hadoop的Hbase和HDFS作为第一分布式文件系统和第二分布式文件系统，具体地，可以将文件内容存储于HDFS内部，以支持大文件和海量文件的存储，同时，还可以将文件的基本信息存储于Hbase。在本发明的一种应用示例，假设需要存储的文件数目为1500万，假设每个文件的基本信息大小在1K以内，则Hbase需要占用的存储空间为15G左右；假设1500万个文件文件内容的大小为50T，则在默认2份备份的情况下，HDFS需要占用的存储空间为150T左右。

这样，本发明实施例可以对海量文件进行存储的同时，通过Hadoop的MapReduce(映射化简)进行文件的全量和随机回扫能力。现有方案的HDFS通过文件列表枚举方式获取文件的特性导致其并不能实现随机扫描，而现有的Hbase对数据访问的耗时较长导致其全量扫描的耗时要在一周以上一个迭代，而本发明实施例可以同时具备快速全量和随机回扫的能力。可以理解，第一分布式文件系统和第二分布式文件系统属于同一分布式系统基础架构只是作为可选实施例，实际上，不属于同一分布式系统基础架构的第一分布式文件系统和第二分布式文件系统也在本发明实施例的保护范围之内。

在实际应用中，待处理请求中可以携带待处理文件的信息，如文件主键(key)、文件名、文件的MD5(消息摘要算法第5版，Message Digest Algorithm 5)等，而第一分布式文件系统上存储的基本信息中可以包括：文件主键(key)和文件在第二分布式文件系统上的存储路径等信息，由于一个文件通常具有唯一的key，这样，可以依据待处理文件的文件主键从第一分布式文件系统上读取待处理文件的其他基本信息，如文件在第二分布式文件系统上的存储路径、文件大小、文件名、文件状态信息等信息等。需要说明的是，在待处理请求中携带待处理文件的文件名、文件的MD5等信息时，可以对这些信息进行例如哈希运算，以将这些信息转换为文件主键，本发明实施例对于具体的转换过程不加以限制。

步骤104、依据所述待处理文件的基本信息，对所述文件处理请求进行处理。

本发明实施例中，待处理文件的基本信息可以作为文件处理请求的处理依据。例如，在文件处理请求为文件下载请求时，可以依据基本信息中的存储路径，从第二分布式文件系统上读取所述待处理文件的文件内容，并下载所述待处理文件的文件内容。

可选地，在完成文件处理请求的处理后，可以对所述文件处理请求对应待处理文件所属的文件目录进行解锁，以使得其他文件处理请求具备待处理文件所属的文件目录的访问可能，可以理解，本发明实施例对于具体的解锁过程和解锁时机不加以限制。

综上，本发明实施例的文件处理方法，当存在对于文件的处理(如访问)需求时，可以从第一分布式文件系统上获取文件在第二分布式文件系统上的存储路径，相对于现有的HDFS是通过文件列表枚举方式获取文件，可以实现待处理文件的快速定位，因此可以提高文件的处理效率，进而可以提高在线应用程序的访问性能。

参照图2，示出了根据本发明一个实施例的一种文件处理方法的步骤流程图，具体可以包括如下步骤：

步骤201、接收文件下载请求；

步骤202、对所述文件下载请求对应待下载文件所属的文件目录进行加锁；所述待下载文件的基本信息存储于第一文件系统，所述待下载文件的文件内容存储于第二文件系统；

步骤203、从第一分布式文件系统上读取所述待下载文件的基本信息；所述基本信息可以包括：文件在第二分布式文件系统上的存储路径；

步骤204、依据所述存储路径，从所述第二分布式文件系统上读取所述待处理文件的文件内容；

步骤205、下载所述待处理文件的文件内容。

文件下载请求可用于下载某个key的文件，处理结果可以为读取得到的文件，并将读取得到的文件返回。可选地，客户端可以通过文件下载请求对应的API接口产生上述文件下载请求。

在本发明的一种可选实施例中，在执行步骤204之前，可以依据所述基本信息中的上传完成标识，判断是否完成所述待下载文件的上传，若是，则可以执行步骤204，否则可以直接返回例如下载失败、或者文件不存在的处理结果。例如，在接收到文件下载请求后，可以通过ZooKeeper对所述文件下载理请求对应待下载文件所属的文件目录进行加锁，并从Hbase上读取该待下载文件的文件在第二分布式文件系统上的存储路径、文件状态信息等基本信息；进一步，该文件状态信息包括：上传完成标识，则可以依据所述基本信息中的上传完成标识，判断是否完成所述待下载文件的上传，若是，则可以执行步骤204，否则可以返回例如下载失败或者文件不存在的处理结果。上述依据基本信息中的上传完成标识进行的判断处理，能够在待下载文件未上传完成时快速地得到对应的处理结果，因此能够提高待下载请求的处理效率。

参照图3，示出了根据本发明一个实施例的一种文件处理方法的步骤流程图，具体可以包括如下步骤：

步骤301、接收文件删除请求；

步骤302、对所述文件删除请求对应待删除文件所属的文件目录进行加锁；所述待删除文件的基本信息存储于第一文件系统，所述待删除文件的文件内容存储于第二文件系统；

步骤303、从第一分布式文件系统上读取所述待删除文件的基本信息；所述基本信息可以包括：文件在第二分布式文件系统上的存储路径；

步骤304、依据所述存储路径，在所述第二分布式文件系统上删除所述待删除文件的文件内容；

步骤305、在所述第一分布式文件系统上删除所述待删除文件的基本信息。

文件删除请求可用于删除某个某个key对应文件的存储内容(包括基本信息和文件内容)，处理结果可以为删除成功或者删除失败。可选地，客户端可以通过文件删除请求对应的API接口产生上述文件删除请求。

在本发明的一种可选实施例中，当无法从第一分布式文件系统上读取所述待删除文件的基本信息时，可以说明待删除文件不存在，故可以直接得到例如删除失败的处理结果。

本发明实施例对于步骤304和步骤305的执行顺序不加以限制，也即，可以并列、先后或者后先执行步骤304和步骤305。

参照图4，示出了根据本发明一个实施例的一种文件处理方法的步骤流程图，具体可以包括如下步骤：

步骤401、接收文件状态查询请求；

步骤402、对所述文件状态查询请求对应待查询文件所属的文件目录进行加锁；所述待查询文件的基本信息存储于第一文件系统，所述待查询文件的文件内容存储于第二文件系统；

步骤403、从第一分布式文件系统上读取所述待查询文件的基本信息；所述基本信息可以包括：文件状态信息；

步骤404、从所述待查询文件的基本信息中获取文件状态信息，并将所述文件状态信息作为处理结果返回。

文件状态查询请求可用于查询某个key的文件状态信息，处理结果可以为查询得到的文件状态信息。可选地，客户端可以通过文件状态请求对应的API接口产生上述文件状态查询请求。

在本发明的一种可选实施例中，上述文件状态信息包括：处理状态标识、文件长度、上传长度、上传完成标识和存储偏移中的至少一种。其中，上述上传完成标识可用于表示是否完成文件的上传，上述处理状态标识可用于表示文件的上传、下载等处理过程中是否存在异常处理，可选地，上述上传完成标识和上述处理状态标识可采用true和false、或者1和0来表示对应的状态。文件长度可用于表示文件所占用的字节大小，上传长度可用于表示上传的文件所占用的字节大小，通常，上传长度小于等于文件长度，存储偏移可用于表示文件所对应数据块的地址偏移量。可以理解，可用于表征文件状态的任意文件状态信息均在本发明实施例的保护范围之内。

参照图5，示出了根据本发明一个实施例的一种文件处理方法的步骤流程图，具体可以包括如下步骤：

步骤501、接收文件上传请求；

步骤502、对所述文件上传请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

步骤503、从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息可以包括：上传完成标识和文件在第二分布式文件系统上的存储路径；

步骤504、依据所述基本信息中的上传完成标识，判断是否完成所述待处理文件的上传；

步骤505、当确定完成所述待处理文件的上传时，返回完成上传的处理结果。

文件上传请求可用于将预置路径的文件上传至分布式文件系统中key的位置，处理结果可以包括：完成上传、上传成功、或者上传失败等。可选地，客户端可以通过文件上传请求对应的API接口产生上述文件上传请求。

本发明实施例可以依据基本信息中的上传完成标识，判断是否完成所述待处理文件的上传，若是，则说明待处理文件已经存在于分布式文件系统，故可以直接得到完成上传的处理结果；相对于传统方案将预置路径的待处理文件写入第二分布式文件系统，本发明实施例基于上传完成标识的处理能够提高文件上传请求的处理效率。

在本发明的一种可选实施例中，所述基本信息还可以包括：处理状态标识，上述方法还可以包括：当确定未完成所述待处理文件的上传时，依据所述基本信息中的处理状态标识判断所述待处理文件是否存在处理异常；当确定所述待处理文件存在处理异常时，在第二文件系统上进行所述待处理文件的异常处理；在完成所述异常处理后，依据所述待处理文件在第二文件系统上的存储状态判断所述待处理文件是否被成功上传；当确定所述待处理文件被成功上传时，返回成功上传的处理结果。本可选实施例可以进一步依据基本信息中的处理状态标识判断待处理文件是否存在处理异常，若是，则在第二文件系统上进行所述待处理文件的异常修复，并在完成异常修复后进一步判断待处理文件是否被成功上传，若是，则返回成功上传的处理结果。相对于传统方案将预置路径的待处理文件写入第二分布式文件系统，本发明实施例基于处理状态标识和异常修复的处理，能够在待处理文件的已有异常处理的基础上进行异常处理(例如断点续传、或者文件修复等)，因此能够提高文件上传请求的处理效率。

在本发明的另一种可选实施例中，上述方法还可以包括：当确定所述待处理文件不存在处理异常、或者确定所述待处理文件未被成功上传时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。上述处理不仅能够将待处理文件写入所述第二文件系统，而且能够及时地更新处理状态标识。

在本发明的再一种可选实施例中，上述方法还可以包括：当第一分布式文件系统上不存在所述待处理文件的基本信息时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。上述处理不仅能够将待处理文件写入所述第二文件系统，而且能够及时地更新处理状态标识。

参照图6，示出了根据本发明一个实施例的一种文件处理方法的步骤流程图，具体可以包括如下步骤：

步骤601、接收文件上传请求；

步骤602、对所述文件上传请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

步骤603、判断第一文件系统上是否存在所述待处理文件的基本信息，若是，则执行步骤604，否则执行步骤608；

步骤604、依据所述基本信息中的上传完成标识判断是否完成所述待上传文件的上传，若是，则执行步骤609，否则执行步骤605；

步骤605、当确定未完成所述待处理文件的上传时，依据所述基本信息中的处理状态标识判断所述待处理文件是否存在处理异常，若是，则执行步骤606，否则执行步骤608；

步骤606、当确定所述待处理文件存在处理异常时，在第二文件系统上进行所述待处理文件的异常处理；

步骤607、在完成所述异常处理后，依据所述待处理文件在第二文件系统上的存储状态判断所述待处理文件是否被成功上传，若是，则执行步骤609，否则执行步骤608；

步骤608、当第一分布式文件系统上不存在所述待处理文件的基本信息、或者确定所述待处理文件不存在处理异常、或者确定所述待处理文件未被成功上传时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果；

步骤609、返回完成上传的处理结果；

步骤610、对所述待处理文件所属的文件目录进行解锁。

参照图7，示出了根据本发明一个实施例的一种文件处理方法的步骤流程图，具体可以包括如下步骤：

步骤701、接收文件处理请求；

步骤702、对所述文件处理请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

步骤703、从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息包括：文件在第二分布式文件系统上的存储路径；

步骤704、依据所述待处理文件的基本信息，对所述文件处理请求进行处理；

相对于图1至图6中任一的实施例，本实施例的方法还可以包括：

步骤705、接收随机扫描请求；所述随机扫描请求中携带有需要随机扫描的主键；

步骤706、从第一分布式文件系统上读取所述需要随机扫描的主键对应文件在第二分布式文件系统上的存储路径；

步骤707、依据所述存储路径，从所述第二分布式文件系统上获取所述需要随机扫描的主键对应文件的文件内容；

步骤708、利用扫描工具进行所获取文件内容的扫描。

现有方案的HDFS通过文件列表枚举方式获取文件的特性导致其并不能实现随机扫描，而现有的Hbase对数据访问的耗时较长导致其全量扫描的耗时要在一周以上一个迭代。

而本发明实施例将文件的基本信息和文件内容分开存储，基本信息通过例如Hbase的第一分布式文件系统存储，随机扫描时快速根据key获取文件在例如HDFS的第二分布式文件系统上的存储路径，然后通过回扫框架包(JAR)中原生的API接口进行文件内容的获取，最后通过第三方扫描工具对文件内容的扫描。另外，本发明的回扫框架，可以将第三方扫描工具通过参数传递给框架，用户可以不修改框架的任何代码，即可通过第三方扫描工具实现对所存储文件的随机扫描。其中，该回扫框架包中可以包括定制化的参数。

可以理解，除了随机扫描外，本发明实施例还可以实现对于所存储文件的全量扫描。在本发明的一种应用示例中，假设所存储文件的数量1500万以上，所存储文件的总大小为50T，所存储文件的平均大小为3.5M，假设扫描需求如下：每日有训练算法的全量扫描，以找出特异结果样本；不定期有第三方扫描器的随机回扫，找出第三方扫描器和自身的差别；训练算法更改或优化时，可以快速全量扫描，以得到改进或优化结果，进行对比。应用本发明实施例，全量扫描所耗费的时间为4个小时左右，相对于现有方案中一周以上的耗时，能够大大提高全量扫描的效率。

参照图8，示出了根据本发明一个实施例的一种文件处理方法的步骤流程图，具体可以包括如下步骤：

步骤801、接收文件处理请求；

步骤802、对所述文件处理请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

步骤803、从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息包括：文件在第二分布式文件系统上的存储路径；

步骤804、依据所述待处理文件的基本信息，对所述文件处理请求进行处理；

相对于图1至图6中任一的实施例，本实施例的方法还可以包括：

步骤805、定期对新增存储的文件进行合并操作。

现有方案中HDFS的名称节点将所存储文件的元数据存放在内存中，导致存储的文件数目受限于名称节点的内存大小。假设HDFS中每个文件、目录、数据块占用150Bytes，则如果存放1million数目的文件至少消耗300MB内存，如果要存放1billion的数目的文件将会超出硬件能力，因此，HDFS不适合大量小文件的存储。

为了减少HDFS中小文件的数量，本发明实施例还可以将新增存储的文件合并到大文件中。具体地，对于新增存储的文件采取临时存放的策略，在每小时的合并阶段，将临时存放的文件合并到对应的大文件中。例如，新增存储目录放在xstore/bucket这一临时存储目录下，合并后的大文件放在xstore_merge/bucket这一合并存储目录下。

在实际应用中，可以针对一个bucket(桶)设置临时存储目录和合并存储目录；每个目录下面可根据参数配置划分成16^n个目录，n默认为3，此参数影响hadoop合并任务的最大worker(工人)数。在将新增存储的文件进行合并操作的过程中，可以对会对临时存储目录的文件进行枚举，逐个进行文件的移动，具体地，将新增存储的文件对应的key取哈希值，并将哈希结果作为合并存储目录的子目录最后一节。

假设新增存储的文件的key为154712366.sandbox和154717588.sandbox，经过上传接口存储到以下HDFS的临时存储目录：

xstore/bucket***/c69/154712366.sandbox

xstore/bucket***/c69/154717588.sandbox

则在进行合并操作的过程中，可以对会对临时存储目录的文件进行枚举，逐个将文件append(追加)到对应key的大文件里，同时对临时存储目录的文件key在Hbase存储的基本信息进行修改，例如，将上述两个文件合并后的HDFS存储目录可以：

xstore_merge/bucket***/c69/.sn

xstore_merge/bucket***/c69/000.mrg

xstore_merge/bucket***/c69/001.mrg

xstore_merge/bucket***/c69/002.mrg

xstore_merge/bucket***/c69/003.mrg

xstore_merge/bucket***/c69/004.mrg

上述合并存储目录的子目录，是按照序号.sn递增，每次合并将新增文件append到最大序号文件，如004.mrg。

综上，本发明实施例将文件内容存储于第二分布式文件系统，支持大文件和海量文件；同时将文件的基本信息存储于第一分布式文件系统；与现有的HDFS相比，本发明实施例具有如下优点：

首先，可以在对海量文件进行存储的同时，可以通过MapReduce进行文件的全量和随机扫描能力；

其次，可以提供一套通用的基于Streaming(流)方式的回扫框架，支持第三方的扫描工具的嵌入；

再者，可以提供一套基于HTTP协议的服务端接口，内部使用分布式锁解决高并发的访问冲突问题，供客户端的调用；

此外，对于第二分布式文件系统存储的文件，可以通过合并使文件数目符合收缩文件数目，解决HDFS中下文件过多造成系统瓶颈的问题。

另外，相对于现有的HDFS通过文件列表枚举方式获取文件，对于文件状态查询、文件下载、文件上传、文件删除等文件处理请求，可以通过第一文件系统上存储的基本信息进行文件的快速定位，因此能够提高文件处理效率。

对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作并不一定是本发明实施例所必须的。

参照图9，示出了根据本发明一个实施例的一种文件处理装置的结构框图，具体可以包括如下模块：

请求接收模块901，用于接收文件处理请求；

目录加锁模块902，用于对所述文件处理请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

信息获取模块903，用于从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息具体可以包括：文件在第二分布式文件系统上的存储路径；

请求处理模块904，用于依据所述待处理文件的基本信息，对所述文件处理请求进行处理。

可选地，所述文件处理请求具体可以包括：文件下载请求，所述请求处理模块904具体可以包括：

文件内容读取子模块，用于依据所述存储路径，从所述第二分布式文件系统上读取所述待处理文件的文件内容；

文件内容下载子模块，用于下载所述待处理文件的文件内容。

可选地，所述文件处理请求具体可以包括：文件删除请求，所述请求处理模块904具体可以包括：

第一删除子模块，用于依据所述存储路径，在所述第二分布式文件系统上删除所述待处理文件的文件内容；

第二删除子模块，用于在所述第一分布式文件系统上删除所述待处理文件的基本信息。

可选地，所述文件处理请求具体可以包括：文件状态查询请求，所述基本信息还可以包括文件状态信息，所述请求处理模块904包括：

状态信息处理子模块，用于从所述待处理文件的基本信息中获取文件状态信息，并将所述文件状态信息作为处理结果返回。

可选地，所述文件处理请求可以包括：文件上传请求，所述基本信息还可以包括：上传完成标识，所述请求处理模块904具体可以包括：

第一判断子模块，用于依据所述基本信息中的上传完成标识，判断是否完成所述待处理文件的上传；

第一结果返回子模块，用于当确定完成所述待处理文件的上传时，返回完成上传的处理结果。

可选地，所述基本信息还可以包括：处理状态标识，所述请求处理模块904还可以包括：

第二判断子模块，用于当确定未完成所述待处理文件的上传时，依据所述基本信息中的处理状态标识判断所述待处理文件是否存在处理异常；

异常处理子模块，用于当确定所述待处理文件存在处理异常时，在第二文件系统上进行所述待处理文件的异常处理；

第三判断子模块，用于在完成所述异常处理后，依据所述待处理文件在第二文件系统上的存储状态判断所述待处理文件是否被成功上传；

第二结果返回子模块，用于当确定所述待处理文件被成功上传时，返回成功上传的处理结果。

可选地，所述请求处理模块904还可以包括：

第一写入处理子模块，用于当确定所述待处理文件不存在处理异常、或者确定所述待处理文件未被成功上传时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；

第三结果返回子模块，用于在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。

可选地，所述装置还可以包括：

第二写入处理子模块，用于当第一分布式文件系统上不存在所述待处理文件的基本信息时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；

第四结果返回子模块，用于在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。

可选地，所述装置还可以包括：

扫描请求接收模块，用于接收随机扫描请求；所述随机扫描请求中携带有需要随机扫描的主键；

路径读取模块，用于从第一分布式文件系统上读取所述需要随机扫描的主键对应文件在第二分布式文件系统上的存储路径；

文件内容读取模块，用于依据所述存储路径，从所述第二分布式文件系统上获取所述需要随机扫描的主键对应文件的文件内容；

扫描模块，用于利用扫描工具进行所获取文件内容的扫描。

可选地，所述装置还可以包括：

文件合并模块，用于定期对新增存储的文件进行合并操作。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的文件处理方法和装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网平台上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包括”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明公开了A1、一种文件处理方法，包括：

接收文件处理请求；

对所述文件处理请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息包括：文件在第二分布式文件系统上的存储路径；

依据所述待处理文件的基本信息，对所述文件处理请求进行处理。

A2、如A1所述的方法，所述文件处理请求包括：文件下载请求，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，包括：

依据所述存储路径，从所述第二分布式文件系统上读取所述待处理文件的文件内容；

下载所述待处理文件的文件内容。

A3、如A1所述的方法，所述文件处理请求包括：文件删除请求，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，包括：

依据所述存储路径，在所述第二分布式文件系统上删除所述待处理文件的文件内容；

在所述第一分布式文件系统上删除所述待处理文件的基本信息。

A4、如A1所述的方法，所述文件处理请求包括：文件状态查询请求，所述基本信息还包括文件状态信息，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，包括：

从所述待处理文件的基本信息中获取文件状态信息，并将所述文件状态信息作为处理结果返回。

A5、如A1所述的方法，所述文件处理请求包括：文件上传请求，所述基本信息还包括：上传完成标识，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，包括：

依据所述基本信息中的上传完成标识，判断是否完成所述待处理文件的上传；

当确定完成所述待处理文件的上传时，返回完成上传的处理结果。

A6、如A5所述的方法，所述基本信息还包括：处理状态标识，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，还包括：

当确定未完成所述待处理文件的上传时，依据所述基本信息中的处理状态标识判断所述待处理文件是否存在处理异常；

当确定所述待处理文件存在处理异常时，在第二文件系统上进行所述待处理文件的异常处理；

在完成所述异常处理后，依据所述待处理文件在第二文件系统上的存储状态判断所述待处理文件是否被成功上传；

当确定所述待处理文件被成功上传时，返回成功上传的处理结果。

A7、如A6所述的方法，所述依据所述待处理文件的基本信息，对所述文件处理请求进行处理的步骤，还包括：

当确定所述待处理文件不存在处理异常、或者确定所述待处理文件未被成功上传时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；

在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。

A8、如A5所述的方法，所述方法还包括：

当第一分布式文件系统上不存在所述待处理文件的基本信息时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；

在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。

A9、如A1至A8中任一所述的方法，所述方法还包括：

接收随机扫描请求；所述随机扫描请求中携带有需要随机扫描的主键；

从第一分布式文件系统上读取所述需要随机扫描的主键对应文件在第二分布式文件系统上的存储路径；

依据所述存储路径，从所述第二分布式文件系统上获取所述需要随机扫描的主键对应文件的文件内容；

利用扫描工具进行所获取文件内容的扫描。

A10、如A1至A8中任一所述的方法，所述方法还包括：

定期对新增存储的文件进行合并操作。

本发明还公开了B11、一种文件处理装置，包括：

请求接收模块，用于接收文件处理请求；

目录加锁模块，用于对所述文件处理请求对应待处理文件所属的文件目录进行加锁；所述待处理文件的基本信息存储于第一文件系统，所述待处理文件的文件内容存储于第二文件系统；

信息获取模块，用于从第一分布式文件系统上读取所述待处理文件的基本信息；所述基本信息包括：文件在第二分布式文件系统上的存储路径；

请求处理模块，用于依据所述待处理文件的基本信息，对所述文件处理请求进行处理。

B12、如B11所述的装置，所述文件处理请求包括：文件下载请求，所述请求处理模块包括：

文件内容读取子模块，用于依据所述存储路径，从所述第二分布式文件系统上读取所述待处理文件的文件内容；

文件内容下载子模块，用于下载所述待处理文件的文件内容。

B13、如B11所述的装置，所述文件处理请求包括：文件删除请求，所述请求处理模块包括：

第一删除子模块，用于依据所述存储路径，在所述第二分布式文件系统上删除所述待处理文件的文件内容；

第二删除子模块，用于在所述第一分布式文件系统上删除所述待处理文件的基本信息。

B14、如B11所述的装置，所述文件处理请求包括：文件状态查询请求，所述基本信息还包括文件状态信息，所述请求处理模块包括：

状态信息处理子模块，用于从所述待处理文件的基本信息中获取文件状态信息，并将所述文件状态信息作为处理结果返回。

B15、如B11所述的装置，所述文件处理请求包括：文件上传请求，所述基本信息还包括：上传完成标识，所述请求处理模块包括：

第一判断子模块，用于依据所述基本信息中的上传完成标识，判断是否完成所述待处理文件的上传；

第一结果返回子模块，用于当确定完成所述待处理文件的上传时，返回完成上传的处理结果。

B16、如B15所述的装置，所述基本信息还包括：处理状态标识，所述请求处理模块还包括：

第二判断子模块，用于当确定未完成所述待处理文件的上传时，依据所述基本信息中的处理状态标识判断所述待处理文件是否存在处理异常；

异常处理子模块，用于当确定所述待处理文件存在处理异常时，在第二文件系统上进行所述待处理文件的异常处理；

第三判断子模块，用于在完成所述异常处理后，依据所述待处理文件在第二文件系统上的存储状态判断所述待处理文件是否被成功上传；

第二结果返回子模块，用于当确定所述待处理文件被成功上传时，返回成功上传的处理结果。

B17、如B16所述的装置，所述请求处理模块还包括：

第一写入处理子模块，用于当确定所述待处理文件不存在处理异常、或者确定所述待处理文件未被成功上传时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；

第三结果返回子模块，用于在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。

B18、如B15所述的装置，所述装置还包括：

第二写入处理子模块，用于当第一分布式文件系统上不存在所述待处理文件的基本信息时，将所述基本信息中的处理状态标识置为异常，将所述待处理文件写入所述第二文件系统，并在成功写入后将所述基本信息中的处理状态标识置为正常；

第四结果返回子模块，用于在将所述基本信息中的处理状态标识置为正常后，返回成功上传的处理结果。

B19、如B11至B18中任一所述的装置，所述装置还包括：

扫描请求接收模块，用于接收随机扫描请求；所述随机扫描请求中携带有需要随机扫描的主键；

路径读取模块，用于从第一分布式文件系统上读取所述需要随机扫描的主键对应文件在第二分布式文件系统上的存储路径；

文件内容读取模块，用于依据所述存储路径，从所述第二分布式文件系统上获取所述需要随机扫描的主键对应文件的文件内容；

扫描模块，用于利用扫描工具进行所获取文件内容的扫描。

B20、如B11至B18中任一所述的装置，所述装置还包括：

文件合并模块，用于定期对新增存储的文件进行合并操作。