一种文件处理方法及系统与流程

本申请涉及文件处理技术领域，特别涉及一种文件处理方法及系统。

背景技术：

随着技术的发展，网络中需要存储的文件越来越多。通常将文件存储到文件服务系统中。

但现有技术中在存储文件时，会出现文件重复存储，造成文件冗余的情况。

技术实现要素：

有鉴于此，本申请的目的是提供一种文件处理方法及系统，用以解决现有技术中会存在文件重复存储，造成文件冗余的技术问题。

本申请提供了一种文件处理方法，包括：

接收文件存储请求，所述文件存储请求中至少包括：待存储的文件实体；

在已存储的文件中查找是否存在与所述文件实体相同的目标文件；

如果存在，在预设的记录集合中添加与所述文件实体相对应的文件记录，并将所述文件记录与所述目标文件建立映射关系；

如果不存在，将所述文件实体进行存储，在所述记录集合中添加与所述文件实体相对应的文件记录，并将所述文件记录与所述文件实体建立映射关系。

上述方法，优选的，将所述文件实体进行存储，包括：

判断所述文件实体是否为图片类型的文件实体；

如果所述文件实体为图片类型的文件实体，若需要进行压缩存储，则基于所述文件实体，生成压缩图，将所述压缩图进行存储；

如果所述文件实体不是图片类型的文件实体，直接将所述文件实体进行存储。

上述方法，优选的，还包括：

接收文件查询请求，所述文件查询请求至少包括：查询文件标识；

在所述记录集合中搜索是否存在与所述查询文件标识相对应的第一文件记录；

如果存在，在已存储的文件中获取与所述第一文件记录具有映射关系的文件实体。

上述方法，优选的，还包括：

接收文件删除请求，所述文件删除请求至少包括：删除文件标识；

在所述记录集合中搜索是否存在与所述删除文件标识相对应的第二文件记录；

如果存在，判断与所述第二文件记录具有映射关系的文件实体被引用的次数是否大于1；

如果大于1，删除所述记录集合中的第二文件记录；

如果不大于1，删除与所述第二文件记录具有映射关系的文件实体并删除所述记录集合中的第二文件记录。

上述方法，优选的，所述已存储的文件以MongoDB的分布式存储方式进行存储。

本申请还提供了一种文件处理系统，包括：

第一接收单元，用于接收文件存储请求，所述文件存储请求中至少包括：待存储的文件实体；

文件查找单元，用于在已存储的文件中查找是否存在与所述文件实体相同的目标文件，如果存在，运行记录添加单元及第一关系建立单元，如果不存在，运行文件存储单元、记录添加单元及第二关系建立单元；

记录添加单元，用于在预设的记录集合中添加与所述文件实体相对应的文件记录；

第一关系建立单元，用于将所述文件记录与所述目标文件建立映射关系；

文件存储单元，用于将所述文件实体进行存储；

第二关系建立单元，用于将所述文件记录与所述文件实体建立映射关系。

上述系统，优选的，所述文件存储单元具体用于：

判断所述文件实体是否为图片类型的文件实体，如果所述文件实体为图片类型的文件实体，若需要进行压缩存储，则基于所述文件实体，生成压缩图，将所述压缩图进行存储，如果所述文件实体不是图片类型的文件实体，直接将所述文件实体进行存储。

上述系统，优选的，还包括：

文件查询单元，用于接收文件查询请求，所述文件查询请求至少包括：查询文件标识；在所述记录集合中搜索是否存在与所述查询文件标识相对应的第一文件记录，如果存在，在已存储的文件中获取与所述第一文件记录具有映射关系的文件实体。

上述系统，优选的，还包括：

文件删除单元，用于接收文件删除请求，所述文件删除请求至少包括：删除文件标识；在所述记录集合中搜索是否存在与所述删除文件标识相对应的第二文件记录，如果存在，判断与所述第二文件记录具有映射关系的文件实体被引用的次数是否大于1，如果大于1，删除所述记录集合中的第二文件记录，如果不大于1，删除与所述第二文件记录具有映射关系的文件实体并删除所述记录集合中的第二文件记录。

上述系统，优选的，所述文件存储单元具体用于将所述文件实体以MongoDB的分布式存储方式进行存储。

由上述方案可知，本申请提供的一种文件处理方法及系统，通过将文件实体与文件信息分开存储，对存储过的文件实体不再进行存储，而是将对应的文件记录进行登记，只存储没有存储过的文件实体，由此，对文件实体只进行一次存储操作，从而避免了文件冗余。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为文件服务系统中的网络结构布局图；

图2为本申请实施例一提供的一种文件处理方法的流程图；

图3、图4及图5分别为本申请实施例一的部分流程图；

图6为本申请实施例二提供的一种文件处理系统的结构示意图；

图7为本申请实施例二提供的一种文件处理系统的另一结构示意图。

具体实施方式

图1所示为文件服务系统中的网络结构布局图，其中包括有客户端、服务器及数据库，用户可以通过输入用户名及密码登录到客户端，客户端与服务器相连接，服务器通过rest接口对外提供服务器，而服务器与数据库相连接，数据库中存储有各种文件的数据。客户端可以通过HTTP(HyperText Transfer Protocol，超文本传输协议)请求，调用服务器上的reset接口，对数据库中的文件进行操作。

以下方案为图1中服务器对客户端进行文件存储、查找及删除等操作的实现方案，如下：

图2所示为本申请实施例一提供的一种文件处理方法的实现流程图，本实施例在图1中的服务器上实现，其中可以包括有以下步骤：

步骤201：接收文件存储请求。

其中，文件存储请求中至少包括：待存储的文件实体。

本实施例中，用户登录客户端后，通过在客户端进行相应的输入操作，基于需要存储的文件实体生成文件存储请求，并基于HTTP协议向服务器发送文件存储请求，由服务器接收这一文件存储请求。

步骤202：在已存储的文件中查找是否存在与文件实体相同的目标文件，如果存在，执行步骤203～步骤204，如果不存在，执行步骤205、步骤203及步骤206。

其中，本实施例中可以首先根据文件实体，提取或确定文件实体的文件特征，如文件名、文件扩展名、文件大小及文件的md5值中的一个或多个等，进而通过数据访问接口在数据库中根据这些文件特征搜索或查找与待存储的文件实体相同的目标文件。

步骤203：在预设的记录集合中添加与文件实体相对应的文件记录。

其中，这里的文件记录可以基于文件实体的文件特征来生成，如文件信息ID，作为唯一表征本次引用该文件实体的标识符。在数据库中，多个文件实体可以以组的形式保存，每个组具有组ID。

步骤204：将添加的文件记录与目标文件建立映射关系。

也就是说，如果在数据库中已经存在与待存储的文件实体相同的目标文件，则不需要再次将文件实体上传，而是只在服务器中的记录集合中添加相应的文件记录，以表征数据库中已经存在这个文件实体。

这里的记录集合可以以文件信息表的形式存在，记录集合中的文件记录即文件信息表中的一条文件信息记录。

本实施例中将添加的文件记录与目标文件建立映射关系时，可以利用指针的数据结构的指向原理，将文件记录指向目标文件，使得基于文件记录能够找到其指向的目标文件。

由此，在本实施例中，服务器中的文件记录与数据库中的文件实体具有映射关系，其中，文件记录与文件实体之间为多对一的关系，即多个文件记录可能对应同一个文件实体，但一个文件实体只对应一条文件记录。

步骤205：将文件实体进行存储。

其中，本实施例可以利用多种文件存储的实现方案，如MongoDB或hudoop等，多种文件存储实现方案公用一个API接口，具体实现方案对外不可见，可以通过修改配置文件中的配置项类设置具体采用哪一种存储实现方案。

其中，由于MongoDB的方案中支持大于16M的文件处理，由此，本实施例可以通过设置大文件上传接口，来实现大于16M的大文件存储等操作。

本实施例在实际应用中可以默认设置使用MongoDB的存储实现方案保存文件，可以方便文件实体的数据备份与数据库的扩展，以提高服务器系统的可靠性、高效性及可伸缩性。

步骤206：将添加的文件记录与文件实体建立映射关系。

由此，如果在数据库中还没有存储与待存储的文件实体相同的目标文件，那么除了需要将文件实体存储到数据库中之外，还需要添加相应的文件记录，并将文件记录与存储的文件实体之间建立映射关系，由此，后续可以根据这一映射关系对文件实体进行其他操作。

由上述方案可知，本申请实施例一提供的一种文件处理方法，通过将文件实体与文件信息分开存储，对存储过的文件实体不再进行存储，而是将对应的文件记录进行登记，只存储没有存储过的文件实体，由此，对文件实体只进行一次存储操作，从而避免了文件冗余。

另外，本实施例通过避免文件冗余，减少数据库的压力，进一步的，对于数据库的后续迁移、备份等日常管理也会带来很大的便利。

同时，本实施例中因为对于相同的文件实体，只会存储一份文件实体在数据库中，当有重复的文件或者存在多次上传同一文件时，本实施例只会存储文件记录，因此可以大大减少客户端与服务器端的数据传输，以及服务器及数据库间的数据传输。

图3所示，为图2中将文件实体进行存储时的具体实现流程图，其中，可以包括以下步骤：

步骤301：判断所述文件实体是否为图片类型的文件实体，如果是，执行步骤302，否则，执行步骤303。

本实施例中可以通过判断文件名称、文件扩展名等文件特征来判断文件实体是否为图片类型的文件实体。

步骤302：判断是否需要进行压缩存储，如果是执行步骤304。

步骤303：直接将文件实体进行存储。

步骤304：基于文件实体，生成压缩图，将压缩图进行存储。

本实施例可以为了节省存储空间，在进行文件实体的存储时，首先判断文件实体是否为需要进行压缩存储的图片类型的文件实体，由此，可以根据需求基于文件实体首先生成指定类型、大小或尺寸的压缩图或缩略图，再进行存储，进而节省空间，也方便文件的后续操作处理。

图4所示，为图1中服务器进行文件查询时的实现流程图，其中，可以包括有以下步骤：

步骤401：接收文件查询请求。

其中，文件查询请求中至少包括：待查询的文件实体的查询文件标识。

本实施例中，用户可以通过登录客户端后，在客户端上进行操作，继而生成文件查询请求，由客户端将文件查询请求发送到服务器，再由服务器对这一文件查询请求进行响应，执行后续操作流程。

步骤402：在记录集合中搜索是否存在与文件查询标识相对应的第一文件记录，如果存在，执行步骤403，如果不存在，执行步骤404。

步骤403：在已存储的文件中获取与第一文件记录具有映射关系的文件实体。

步骤404：返回不存在文件实体的查询结果。

也就是说，服务器在接收到文件查询请求之后，不需要直接去数据库中查找相应的文件实体，而是可以首先在服务器的记录集合中搜索是否有相应的文件记录，如果记录集合中存在与查询文件标识相对应的第一文件记录，则表明数据库中肯定存在相应的文件实体，此时，再从数据库的已存储的文件中获取与这个文件记录具有映射关系的文件实体，而如果记录集合中并不存在与查询文件标识相对应的文件记录，则表明数据库中肯定不存在与这个文件记录具有映射关系的文件实体，则直接向客户端返回没有这个文件实体的查询结果，由此，提高文件查询效率。

另外，本实施例在查询到文件实体之后，除了可以直接下载文件之后，还可以对文件实体进行后续操作，如图片文件的选择、旋转、剪切到指定大小等操作。也就是说，用户可以通过客户端输入操作参数，如剪切的大小、旋转的角度等，由此，服务器在查询到文件之后，可以直接对文件中的图片进行剪切或旋转等操作。

图5所示，为图1中服务器对文件进行删除的实现流程图，其中可以包括以下步骤：

步骤501：接收文件删除请求。

其中，文件删除请求至少包括：删除文件标识。

本实施例中，用户可以通过登录客户端后，在客户端上进行操作，继而生成文件删除请求，由客户端将文件删除请求发动到服务器，再由服务器对这一文件删除请求进行响应，执行后续操作流程。

步骤502：在记录集合中搜索是否存在与删除文件标识相对应的第二文件记录，如果存在，执行步骤503～步骤505，如果不存在，执行步骤506。

步骤503：判断与第二文件记录具有映射关系的文件实体被引用的次数是否大于1，如果是，执行步骤504，否则，执行步骤505及步骤504。

步骤504：删除记录集合中搜索到的第二文件记录。

步骤505：删除与第二文件记录具有映射关系的文件实体。

步骤506：返回文件不存在的结果。

也就是说，本实施例中，判断与第二文件记录具有映射关系的文件实体被引用的次数是否大于1的目的在于，判断第二文件记录映射的文件实体是否有其他文件记录具有映射关系，如果大于1，则说明有其他文件记录指向这个文件实体，此时，这个文件实体不能被删除，只需要删除搜索到的第二文件记录即可，而如果不大于1，则说明没有其他文件记录指向这个文件实体，此时，这个文件实体及相应的第二文件记录均可以被删除掉，完成文件删除。

图6所示为本申请实施例二提供的一种文件处理系统的结构示意图，应用图1所示的服务器中，可以包括有以下结构：

第一接收单元601，用于接收文件存储请求，所述文件存储请求中至少包括：待存储的文件实体。

文件查找单元602，用于在已存储的文件中查找是否存在与所述文件实体相同的目标文件，如果存在，运行记录添加单元603及第一关系建立单元604，如果不存在，运行文件存储单元605、记录添加单元603及第二关系建立单元606。

记录添加单元603，用于在预设的记录集合中添加与所述文件实体相对应的文件记录。

第一关系建立单元604，用于将所述文件记录与所述目标文件建立映射关系。

文件存储单元605，用于将所述文件实体进行存储。

其中，文件存储单元605具体用于：

判断所述文件实体是否为图片类型的文件实体，如果所述文件实体为图片类型的文件实体，若需要进行压缩存储，则基于所述文件实体，生成压缩图，将所述压缩图进行存储，如果所述文件实体不是图片类型的文件实体，直接将所述文件实体进行存储。

需要说明的是，所述文件存储单元605具体用于将所述文件实体以MongoDB的分布式存储方式进行存储。由于MongoDB的方案中支持大于16M的文件处理，由此，本实施例可以通过设置大文件上传接口，来实现大于16M的大文件存储等操作。

第二关系建立单元606，用于将所述文件记录与所述文件实体建立映射关系。

由上述方案可知，本申请实施例二提供的一种文件处理系统，通过将文件实体与文件信息分开存储，对存储过的文件实体不再进行存储，而是将对应的文件记录进行登记，只存储没有存储过的文件实体，由此，对文件实体只进行一次存储操作，从而避免了文件冗余。

图7所示为本申请实施例二提供的一种文件处理系统的另一结构示意图，其中，还可以包括以下结构：

文件查询单元607，用于接收文件查询请求，所述文件查询请求至少包括：查询文件标识；在所述记录集合中搜索是否存在与所述查询文件标识相对应的第一文件记录，如果存在，在已存储的文件中获取与所述第一文件记录具有映射关系的文件实体。

文件删除单元608，用于接收文件删除请求，所述文件删除请求至少包括：删除文件标识；在所述记录集合中搜索是否存在与所述删除文件标识相对应的第二文件记录，如果存在，判断与所述第二文件记录具有映射关系的文件实体被引用的次数是否大于1，如果大于1，删除所述记录集合中的第二文件记录，如果不大于1，删除与所述第二文件记录具有映射关系的文件实体并删除所述记录集合中的第二文件记录。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种文件处理方法及系统进行了详细介绍，对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。