CN109634916A - 文件存储及下载方法、装置及存储介质 - Google Patents

Abstract

本发明涉及大数据，揭露了一种文件存储方法，该方法包括：接收文件存储指令；根据待存储文件的文件大小判断是否需要打包存储；若是，确定与所述待存储文件对应的打包对象，将所述待存储文件存储到所述打包对象中，生成待存储文件对应的索引信息，并根据预设算法将所述索引信息保存至预设数据库中。本发明还揭露了一种服务器、文件下载方法、装置及计算机存储介质。利用本发明，使索引信息查询存储的内容更简洁、更准确，并且提升查询下载效率。

Description

文件存储及下载方法、装置及存储介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种文件存储及下载方法、电子装置及计算机可读存储介质。

背景技术

小文件一般指大小在几千字节(KB)到几兆字节(MB)的单个文件，现有的网络上存在有大量的图片、文档等小文件，目前，用户在想要对网络上的小文件进行处理(比如：对从网络上的图片进行编辑或者修改等操作)时，需要将网络上的小文件下载到用户本地的文件系统中进行存储，然后才可以对存储的小文件进行处理。

然而，一方面，现有的文件系统中，通常小文件的索引文件存储的是小文件的文件名，在进行文件查找时，系统需要使用该索引文件中的文件名与用户提供的文件名进行对比，才可以定位用户查找的小文件的位置，但是文件名一般是英文、中文和数字混合的字符串，比较复杂，也比较长，所以比对的速度较慢，导致返回给用户待处理小文件的时间较长；另一方面小文件大量积压之后会造成系统负担过重，使得系统性能下降，影响用户使用体验。

发明内容

鉴于以上内容，本发明提供一种文件存储及下载方法、电子装置及计算机可读存储介质，其主要目的在于使索引信息查询存储的内容更简洁、更准确，并且提升查询下载效率，进而提升用户体验。

为实现上述目的，本发明提供一种文件存储方法，该方法包括：

S1、接收携带待存储文件的文件存储指令，所述文件存储指令中包括：待存储文件的属性信息及待存储文件对应的桶名；

S2、根据所述待存储文件的文件大小判断所述待存储文件的类型，根据所述带存储文件的类型判断所述待存储文件是否需要打包存储；及

S3、当所述待存储文件需要进行打包存储时，确定与所述待存储文件对应的打包对象，将所述待存储文件存储到所述打包对象中，生成待存储文件对应的索引信息，并根据预设算法将所述索引信息保存至预设数据库中。

为实现上述目的，本发明提供一种文件下载方法，该方法包括：

接收文件下载指令，所述文件下载指令中包括待下载文件的文件名及对应的桶名；

根据所述待下载文件的文件名确定所述待下载文件对应的索引信息的存储的虚拟节点，并从该虚拟节点读取所述索引信息；及

根据所述待下载文件的文件名、对应的桶名及所述索引信息确定所述待下载文件的存储位置，从所述存储位置获取所述待下载文件的数据，并将所述待下载文件反馈给客户端。

此外，本发明还提供一种服务器，该服务器包括：第一存储器、第一处理器，所述第一存储器上存储有可在所述第一处理器上运行的文件存储程序，所述文件存储程序被所述第一处理器执行时，可实现如上所述文件存储方法的任意步骤。

此外，本发明还提供一种文件下载装置，该装置包括：第二存储器、第二处理器，所述第二存储器上存储有可在所述第二处理器上运行的文件下载程序，所述文件下载程序被所述第二处理器执行时，可实现如上所述文件下载方法的任意步骤。

此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质中包括文件存储/下载程序，所述文件存储/下载程序被处理器执行时，可实现如上所述文件存储/下载方法的任意步骤。

本发明提出的文件存储及下载方法、装置、服务器及计算机可读存储介质，在判断待存储文件需要进行打包存储后，分析待存储文件对应的打包文件的位置，生成待存储文件对应的key-value形式的索引信息，基于CRUSH算法计算待存储文件的文件名的属性值，将属性信息保存在预设数据库中编号与属性值一致的虚拟节点上；在查询下载待下载文件时，通过计算待下载文件的文件名的属性值，确定索引信息的存储位置，并根据索引信息的value确定待下载文件的位置，查询过程比较简单，提高了文件查询下载效率，进而提升用户体验。

附图说明

图1为本发明实施例提出的文件存储的流程图；

图2为本发明实施例提出的服务器的示意图；

图3为图2中文件存储程序的程序模块示意图；

图4为本发明实施例提出的文件下载装置的示意图；

图5为图4中文件下载程序的程序模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1所示，为本发明实施例提出的文件存储方法的流程图。该方法可以由一个装置执行，该装置可以由软件和/或硬件实现。

本实施例中，所述文件存储方法适用于UUID节点对应的服务器，该文件存储方法包括步骤S1-S3。

S1、接收携带待存储文件的文件存储指令。

文件存储指令中包括：待存储文件的属性信息及待存储文件对应的桶名(bucket)。待存储文件可以是的图片、文档、音乐等文件。待存储文件的属性信息包括：待存储文件的文件名、文件大小等信息。待存储文件对应的桶名可以理解为待存储文件对应的文件夹名称。

文件存储指令是用户通过客户端发出的。其中，服务器可直接接收用户通过客户端发出的文件存储指令，也可以接收负载均衡服设备(例如，智能网关)根据预设的负载均衡规则分配的文件存储指令。也就是说，负载均衡设备接收用户通过客户端发出的一个或多个文件存储指令后，需将一个或多个文件存储指令分配至HTTP节点集群(服务器集群)中的某一个HTTP节点(每个都是独立的服务器)，以响应文件存储指令。

优选地，所述负载均衡设备根据预设的负载均衡规则分配所述文件存储指令，所述预设的负载均衡规则为：

根据预设HTTP节点列表中各HTTP节点的排序，按照轮询的方式，依次将所述一条或多条文件存储指令分配给各HTTP节点。

其中，预先确定HTTP节点集群中各HTTP节点的排序，生成HTTP节点列表。依次按照HTTP列表中各HTTP的顺序，将指令分配给各HTTP节点。

为了提高文件存储指令的处理效率，所述预设的负载均衡规则为：

分别统计各HTTP节点对应的负载数量，将所述请求分配给负载数量最少的HTTP节点。

其中，所述负载数量可以是待处理指令数量，实时或定时统计每个HTTP节点的待处理指令数量，将文件存储指令分配给待处理指令数量最少的HTTP节点，均衡各HTTP节点的负载。

为了有效地进行资源平分配，所述预设的负载均衡规则为：

依次接收各HTTP节点反馈的请求完成结果，按照反馈时间对各HTTP节点进行排序，根据排序顺序依次将请求分配给各HTTP节点。

也就是说，按照能者多得的方式分配，当某个HTTP节点完成请求(并不限于文件存储指令)后，主动去获取请求资源进行处理，这样可以有效地进行资源分配。

S2、根据所述待存储文件的文件大小判断所述待存储文件的类型，根据所述带存储文件的类型判断所述待存储文件是否需要打包存储。

其中，文件类型包括：小文件和大文件。待存储文件的文件大小根据文件字节进行衡量。具体地，该步骤包括：

从所述待存储文件的属性信息中获取所述待存储文件的文件大小；

当所述待存储文件的文件大小小于或等于第一预设阈值时，判断所述待存储文件为小文件，需要对所述待存储文件进行打包存储；

当所述待存储文件的文件大小大于第一预设阈值时，判断所述待存储文件为大文件，不需要对所述待存储文件进行打包存储。

例如，获取待存储文件的属性信息，从待存储文件的属性信息中读取待存储文件的文件字节，当待存储文件的文件字节小于或等于第一预设阈值(例如，4M)时，判断待存储文件为小文件，需要进行打包，当待存储文件的文件字节大于第一预设阈值(例如，4M)时，判断待存储文件为大文件，不需要进行打包。需要说明的是，第一预设阈值的大小可以根据需求调整。

S3、当所述待存储文件需要进行打包存储时，确定与所述待存储文件对应的打包对象，将所述待存储文件存储到所述打包对象中，生成待存储文件对应的索引信息，并根据预设算法将所述索引信息保存至预设数据库中。

在将待存储文件打包存储之前，需先确定待存储文件所依附的打包对象。其中，所述打包对象保存在后端存储系统中，可能是一个文件，也可能是多个文件合并后生成的。

具体地，步骤S3中的所述确定与所述待存储文件对应的大对象，包括：

从预设的UUID列表中筛选出对应缓存空间小于第二预设阈值(大于第一预设阈值)的UUID，对筛选出的UUID对应的打包对象进行排序，生成打包对象列表；选择排序靠前的打包对象作为所述待存储文件对应的打包对象。

预先在后端存储系统中设置多个通用唯一识别码(Universally UniqueIdentifier，UUID)，每个UUID对应一个第二预设阈值(例如，16M)的存储空间，并按照一定的顺序生成UUID列表，例如，根据UUID中的预设位数的数字串的大小顺序。其中，每个UUID对应一个打包对象。其中，打包对象列表中各打包对象的顺序与UUID列表对应。第二预设阈值可以根据需要进行调整。

本实施例中的预设数据库可以是leveldb。本实施例中的索引信息以key-value(键-值)的形式存在，供后续下载文件时根据索引信息查询文件位置。具体地，所述生成待存储文件对应的索引信息，包括：

根据所述待存储文件的文件名及对应的桶名确定索引信息中的键；

根据所述打包对象中已有字节确定索引信息中的偏移，根据所述待存储文件的大小确定文件长度，生成索引信息中的值；

对所述键、值进行合并，确定所述待存储文件对应的索引信息。

例如，所述待存储文件对应的索引信息中的键(key)为：桶名+文件名。桶名和文件名从文件上传指令中获取。所述待存储文件对应的索引信息中的值(value)为：打包对象名：偏移：文件长度。合并上述key、value，生成待存储文件对应的索引信息。

需要说明的是，当所述待存储文件对应的UUID不存在打包对象时，直接创建一个新的打包对象，该打包对象以对应的UUID命名。创建的新的打包对象的内容为空，直接将待存储文件的内容写入该打包对象中，打包对象的内容即为待存储文件的内容。在生成待存储文件对应的索引信息时，偏移为0。

可选地，所述预设算法为crush算法。本实施例中所述根据预设算法将所述索引信息保存至预设数据库中，包括：

根据所述待存储文件的文件名计算所述待存储文件对应的文件名属性值；

从预先确定的预设数据库中的预设数量的虚拟节点中，选择编号与所述待存储文件对应的文件名属性值一致的虚拟节点作为所述待存储文件对应的索引信息的存储位置。

预先确定所述数据库中的预设数量(例如，1000000)的虚拟节点，每个虚拟节点对应的一个编号，例如，虚拟节点的编号为1-10000。需要存储索引信息时，计算待存储文件的文件名对应的属性值，选择编号与属性值相同的虚拟节点作为待存储文件对应的索引信息应该保存的位置，至此，待存储文件存储完毕。

假设需要将待存储文件file1存储至bucket1中，根据文件名和桶名算出的打包对象名为sadasd121312312312，将待存储文件file1附在打包对象sadasd121312312312的后面，生成索引信息，索引信息为<bucket1+1.jpg,sadasd121312312312:**:23400>，根据待存储文件的文件名file1算出的属性值为100，则将索引信息存入编号为100的虚拟节点上。

在其他实施例中，该方法还包括：

当所述待存储文件不需要进行打包存储，且所述待存储文件大小大于第二预设阈值时，对所述待存储文件进行分片存储。

可以理解的是，第二预设阈值的大小与后台存储系统中预设的每个UUID对应的存储空间阈值有关，一般略小于或者等于每个UUID对应的存储空间阈值，例如，第二预设阈值可以是16M，第二预设阈值的大小可根据需求进行调整。

当待存储文件的大小超过了第二阈值，那么一个UUID对应的存储空间无法存储该待存储文件，因此需要进行分片处理。具体地，所述对所述待存储文件进行分片存储，包括：

将所述待存储文件进行分成大小小于或等于第三预设阈值的分片，生成多个待存储子文件及分片信息(例如，多个待存储子文件的名称)，根据预设算法将所述分片信息存储至预设数据库中；

对于不需打包存储的待存储子文件，从预设的UUID列表中筛选出多个(与不需打包存储的待存储子文件数量相同)对应缓存空间为第二预设阈值的UUID，依次将所述多个待存储子文件作为所多个UUID对应的打包对象；

对于需打包存储的待存储子文件，确定与所述需打包存储的待存储子文件对应的打包对象，将所述需打包存储的待存储子文件存储到所述打包对象中；

生成所述多个待存储子文件对应的索引信息，并根据预设算法将所述索引信息保存至预设数据库中。

其中，第三预设阈值小于或等于第二预设阈值，例如，15M。需要说明的是，并不是所有的待存储子文件的大小都相同，例如，上传一个文件名为file1、大小为63M的文件到bucket1上，文件file1会被切分为以上的5个分片，分片结果为：15M、15M、15M、15M、3M，即5个子文件，每一个分片对应的子文件的文件名称分别以bucket1_file1_shadow_1---bucket1_file1_shadow_5标识。需要说明的是，在对待存储子文件进行分片处理后需将分片信息存储至预设数据库中，分片信息存储的位置的确定步骤与步骤S3中索引信息的确定步骤大致相同，这里不作赘述。

对于file1_shadow_1-file1_shadow_4这四个待存储子文件，由于文件大小大于第一预设阈值，故不进行打包存储，直接将这四个待存储子文佳作为打包对象。对于file1_shadow_5这个待存储子文件，由于文件大小小于第一预设阈值，故需进行打包存储，具体打包存储的过程与步骤S3中一种，这里不作赘述。

参照图2所示，为本发明实施例提出的服务器的示意图。

本实施例中，所述服务器1为服务器集群中任意一台服务器，每台所述服务器1对应一个HTTP节点。所述服务器1可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器。

该服务器1包括第一存储器11、第一处理器12，及第一网络接口13。

其中，第一存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、磁性存储器、磁盘、光盘等。第一存储器11在一些实施例中可以是所述服务器1的内部存储单元，例如该服务器1的硬盘。第一存储器11在另一些实施例中也可以是所述服务器1的外部存储设备，例如该服务器1上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，第一存储器11还可以既包括该服务器1的内部存储单元也包括外部存储设备。

第一存储器11不仅可以用于存储安装于该服务器1的应用软件及各类数据，例如文件存储程序10等，还可以用于暂时地存储已经输出或者将要输出的数据。

第一处理器12在一些实施例中可以是一中央处理器(Central Processing Unit,CPU)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行第一存储器11中存储的程序代码或处理数据，例如文件存储程序10等。

第一网络接口13可选的可以包括标准的有线接口、无线接口(如WI-FI接口)，通常用于在该服务器1与其他电子设备之间建立通信连接。例如，客户端(图中未标注)或者负载均衡设备(图中未标注)。

图2仅示出了具有组件11-13的服务器1，本领域技术人员可以理解的是，图2示出的结构并不构成对服务器1的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

可选地，该服务器1还可以包括用户接口，用户接口可以包括显示器(Display)、输入单元比如键盘(Keyboard)，可选的用户接口还可以包括标准的有线接口、无线接口。

可选地，在一些实施例中，显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及有机发光二极管(Organic Light-Emitting Diode，OLED)触摸器等。其中，显示器也可以称为显示屏或显示单元，用于显示在服务器1中处理的信息以及用于显示可视化的用户界面。

在图2所示的服务器1实施例中，作为一种计算机存储介质的第一存储器11中存储文件存储程序10的程序代码，第一处理器12执行文件存储程序10的程序代码时，实现如下步骤：

A1、接收携带待存储文件的文件存储指令。

文件存储指令中包括：待存储文件的属性信息及待存储文件对应的桶名(bucket)。待存储文件可以是的图片、文档、音乐等文件。待存储文件的属性信息包括：待存储文件的文件名、文件大小等信息。待存储文件对应的桶名可以理解为待存储文件对应的文件夹名称。

文件存储指令是用户通过客户端发出的。其中，服务器可直接接收用户通过客户端发出的文件存储指令，也可以接收负载均衡服设备(例如，智能网关)根据预设的负载均衡规则分配的文件存储指令。也就是说，负载均衡设备接收用户通过客户端发出的一个或多个文件存储指令后，需将一个或多个文件存储指令分配至HTTP节点集群(服务器集群)中的某一个HTTP节点(每个都是独立的服务器)，以响应文件存储指令。

优选地，所述负载均衡设备根据预设的负载均衡规则分配所述文件存储指令，所述预设的负载均衡规则为：

根据预设HTTP节点列表中各HTTP节点的排序，按照轮询的方式，依次将所述一条或多条文件存储指令分配给各HTTP节点。

其中，预先确定HTTP节点集群中各HTTP节点的排序，生成HTTP节点列表。依次按照HTTP列表中各HTTP的顺序，将指令分配给各HTTP节点。

为了提高文件存储指令的处理效率，所述预设的负载均衡规则为：

分别统计各HTTP节点对应的负载数量，将所述请求分配给负载数量最少的HTTP节点。

其中，所述负载数量可以是待处理指令数量，实时或定时统计每个HTTP节点的待处理指令数量，将文件存储指令分配给待处理指令数量最少的HTTP节点，均衡各HTTP节点的负载。

为了有效地进行资源平分配，所述预设的负载均衡规则为：

依次接收各HTTP节点反馈的请求完成结果，按照反馈时间对各HTTP节点进行排序，根据排序顺序依次将请求分配给各HTTP节点。

也就是说，按照能者多得的方式分配，当某个HTTP节点完成请求(并不限于文件存储指令)后，主动去获取请求资源进行处理，这样可以有效地进行资源分配。

A2、根据所述待存储文件的文件大小判断所述待存储文件的类型，根据所述带存储文件的类型判断所述待存储文件是否需要打包存储。

其中，文件类型包括：小文件和大文件。待存储文件的文件大小根据文件字节进行衡量。具体地，该步骤包括：

从所述待存储文件的属性信息中获取所述待存储文件的文件大小；

当所述待存储文件的文件大小小于或等于第一预设阈值时，判断所述待存储文件为小文件，需要对所述待存储文件进行打包存储；

当所述待存储文件的文件大小大于第一预设阈值时，判断所述待存储文件为大文件，不需要对所述待存储文件进行打包存储。

例如，获取待存储文件的属性信息，从待存储文件的属性信息中读取待存储文件的文件字节，当待存储文件的文件字节小于或等于第一预设阈值(例如，4M)时，判断待存储文件为小文件，需要进行打包，当待存储文件的文件字节大于第一预设阈值(例如，4M)时，判断待存储文件为大文件，不需要进行打包。需要说明的是，第一预设阈值的大小可以根据需求调整。

A3、当所述待存储文件需要进行打包存储时，确定与所述待存储文件对应的打包对象，将所述待存储文件存储到所述打包对象中，生成待存储文件对应的索引信息，并根据预设算法将所述索引信息保存至预设数据库中。

在将待存储文件打包存储之前，需先确定待存储文件所依附的打包对象。其中，所述打包对象保存在后端存储系统中，可能是一个文件，也可能是多个文件合并后生成的。

具体地，步骤A3中的所述确定与所述待存储文件对应的大对象，包括：

从预设的UUID列表中筛选出对应缓存空间小于第二预设阈值(大于第一预设阈值)的UUID，对筛选出的UUID对应的打包对象进行排序，生成打包对象列表；选择排序靠前的打包对象作为所述待存储文件对应的打包对象。

预先在后端存储系统中设置多个通用唯一识别码(Universally UniqueIdentifier，UUID)，每个UUID对应一个第二预设阈值(例如，16M)的存储空间，并按照一定的顺序生成UUID列表，例如，根据UUID中的预设位数的数字串的大小顺序。其中，每个UUID对应一个打包对象。其中，打包对象列表中各打包对象的顺序与UUID列表对应。第二预设阈值可以根据需要进行调整。

本实施例中的预设数据库可以是leveldb。本实施例中的索引信息以key-value(键-值)的形式存在，供后续下载文件时根据索引信息查询文件位置。具体地，所述生成待存储文件对应的索引信息，包括：

根据所述待存储文件的文件名及对应的桶名确定索引信息中的键；

根据所述打包对象中已有字节确定索引信息中的偏移，根据所述待存储文件的大小确定文件长度，生成索引信息中的值；

对所述键、值进行合并，确定所述待存储文件对应的索引信息。

例如，所述待存储文件对应的索引信息中的键(key)为：桶名+文件名。桶名和文件名从文件上传指令中获取。所述待存储文件对应的索引信息中的值(value)为：打包对象名：偏移：文件长度。合并上述key、value，生成待存储文件对应的索引信息。

需要说明的是，当所述待存储文件对应的UUID不存在打包对象时，直接创建一个新的打包对象，该打包对象以对应的UUID命名。创建的新的打包对象的内容为空，直接将待存储文件的内容写入该打包对象中，打包对象的内容即为待存储文件的内容。在生成待存储文件对应的索引信息时，偏移为0。

可选地，所述预设算法为crush算法。本实施例中所述根据预设算法将所述索引信息保存至预设数据库中，包括：

根据所述待存储文件的文件名计算所述待存储文件对应的文件名属性值；

从预先确定的预设数据库中的预设数量的虚拟节点中，选择编号与所述待存储文件对应的文件名属性值一致的虚拟节点作为所述待存储文件对应的索引信息的存储位置。

预先确定所述数据库中的预设数量(例如，1000000)的虚拟节点，每个虚拟节点对应的一个编号，例如，虚拟节点的编号为1-10000。需要存储索引信息时，计算待存储文件的文件名对应的属性值，选择编号与属性值相同的虚拟节点作为待存储文件对应的索引信息应该保存的位置，至此，待存储文件存储完毕。

假设需要将待存储文件file1存储至bucket1中，根据文件名和桶名算出的打包对象名为sadasd121312312312，将待存储文件file1附在打包对象sadasd121312312312的后面，生成索引信息，索引信息为<bucket1+1.jpg,sadasd121312312312:**:23400>，根据待存储文件的文件名file1算出的属性值为100，则将索引信息存入编号为100的虚拟节点上。

在其他实施例中，第一处理器12执行文件存储程序10的程序代码时，还实现如下步骤：

当所述待存储文件不需要进行打包存储，且所述待存储文件大小大于第二预设阈值时，对所述待存储文件进行分片存储。

可以理解的是，第二预设阈值的大小与后台存储系统中预设的每个UUID对应的存储空间阈值有关，一般略小于或者等于每个UUID对应的存储空间阈值，例如，第二预设阈值可以是16M，第二预设阈值的大小可根据需求进行调整。

当待存储文件的大小超过了第二阈值，那么一个UUID对应的存储空间无法存储该待存储文件，因此需要进行分片处理。具体地，所述对所述待存储文件进行分片存储，包括：

将所述待存储文件进行分成大小小于或等于第三预设阈值的分片，生成多个待存储子文件及分片信息(例如，多个待存储子文件的名称)，根据预设算法将所述分片信息存储至预设数据库中；

对于不需打包存储的待存储子文件，从预设的UUID列表中筛选出多个(与不需打包存储的待存储子文件数量相同)对应缓存空间为第二预设阈值的UUID，依次将所述多个待存储子文件作为所多个UUID对应的打包对象；

对于需打包存储的待存储子文件，确定与所述需打包存储的待存储子文件对应的打包对象，将所述需打包存储的待存储子文件存储到所述打包对象中；

生成所述多个待存储子文件对应的索引信息，并根据预设算法将所述索引信息保存至预设数据库中。

其中，第三预设阈值小于或等于第二预设阈值，例如，15M。需要说明的是，并不是所有的待存储子文件的大小都相同，例如，上传一个文件名为file1、大小为63M的文件到bucket1上，文件file1会被切分为以上的5个分片，分片结果为：15M、15M、15M、15M、3M，即5个子文件，每一个分片对应的子文件的文件名称分别以bucket1_file1_shadow_1---bucket1_file1_shadow_5标识。需要说明的是，在对待存储子文件进行分片处理后需将分片信息存储至预设数据库中，分片信息存储的位置的确定步骤与步骤A3中索引信息的确定步骤大致相同，这里不作赘述。

对于file1_shadow_1-file1_shadow_4这四个待存储子文件，由于文件大小大于第一预设阈值，故不进行打包存储，直接将这四个待存储子文佳作为打包对象。对于file1_shadow_5这个待存储子文件，由于文件大小小于第一预设阈值，故需进行打包存储，具体打包存储的过程与步骤A3中一种，这里不作赘述。

可选地，在其他的实施例中，文件存储程序10还可以被分割为一个或者多个模块，一个或者多个模块被存储于第一存储器11中，并由一个或多个处理器(本实施例为第一处理器12)所执行，以完成本发明，本发明所称的模块是指能够完成特定功能的一系列计算机程序指令段。例如，参照图3所示，为图2中文件存储程序10的模块示意图，该实施例中，文件存储程序10可以被分割为第一接收模块110、判断模块120、打包存储模块130及分片存储模块140，所述模块110-140所实现的功能或操作步骤均与上文类似，此处不再详述。

基于上述文件存储方法的实施例，本发明实施例还提出一种文件下载方法。本实施例中，所述文件下载方法包括：

接收文件下载指令，所述文件下载指令中包括待下载文件的文件名及对应的桶名；

根据所述待下载文件的文件名确定所述待下载文件对应的索引信息的存储的虚拟节点，并从该虚拟节点读取所述索引信息；及

根据所述待下载文件的文件名、对应的桶名及所述索引信息确定所述待下载文件的存储位置，从所述存储位置获取所述待下载文件的数据，并将所述待下载文件反馈给客户端。

一般情况下，用户都是通过HTTP协议进行上传下载，指令的格式一般为http://服务域名/桶名/文件名。

基于CRUSH算法，计算待下载文件的文件名对应的属性值，确定数据库的预设虚拟节点中，编号与属性值相同的虚拟节点为保存待下载文件对应的索引信息对应的存储地址。同一个虚拟节点处保存着多条索引信息，需根据待下载文件的文件名及对应的桶名确定对应的索引键(key)，并根据key查询并获取索引信息的索引值(value)。根据索引值确定待下载文件对应的打包文件、偏移量及字节长度，进而下载待下载文件。

例如，计算出存储索引信息的虚拟节点编号为100，根据bucket1+file1这个key获取索引值为<bucket1+1.jpg,sadasd121312312312:**:23400>，表示将从后端存储一个叫sadasd121312312312的对象中从偏移量**开始获取23400个字节的数据。

进一步地，在所述“根据所述待下载文件的文件名确定所述待下载文件对应的索引信息的存储的虚拟节点，并从该虚拟节点读取所述索引信息”之前，该方法还包括：

根据所述待下载文件的文件名确定所述待下载文件对应的分片信息，根据所述分片信息确定所述待下载文件对应的多个待下载子文件的文件名；

根据所述多个待下载子文件的文件名分别确定所述多个待下载子文件对应的索引信息的存储的虚拟节点，并分别从各虚拟节点读取所述多个待下载子文件对应的索引信息；及

根据所述多个待下载子文件的文件名、对应的桶名及所述索引信息分别确定所述多个待下载子文件的存储位置，分别从所述存储位置获取所述多个待下载子文件的数据，合并所述多个待下载子文件的数据，生成所述待下载文件，并将所述待下载文件反馈给客户端。

在获取待下载文件的数据之前，首先需要判断待下载文件是否被分片存储，若是，则需要从数据库获取待下载文件的分片信息，并依次获取每一个分片对应的数据，并根据每个分片的编号中的预设位数的数据串(例如，bucket1_file1_shadow_1中shadow后的数值“1”)由小到大的顺序组装数据。其中，每个分片对应的待下载子文件数据的获取步骤与上述实施例一致，这里不作赘述。

进一步地，该方法还包括：

判断所述下载指令中是否需要对待下载文件进行处理，若是，对所述待下载文件进行处理后反馈至客户端。

例如，当待下载文件为图片时，可能需要对图片进行裁剪/缩略图片，对获取的图片进行裁剪/缩略的处理后返给客户端。

参照图4所示，为本发明实施例提出的文件下载装置的示意图。

本实施例中，文件下载装置2可以是服务器、智能手机、平板电脑、便携计算机、桌上型计算机等具有数据处理功能的终端设备，所述服务器可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器。

该文件下载装置2包括第二存储器21、第二处理器22，及第二网络接口23。

其中，第二存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、磁性存储器、磁盘、光盘等。第二存储器21在一些实施例中可以是所述文件下载装置2的内部存储单元，例如该文件下载装置2的硬盘。第二存储器21在另一些实施例中也可以是所述文件下载装置2的外部存储设备，例如该文件下载装置2上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，第二存储器21还可以既包括该文件下载装置2的内部存储单元也包括外部存储设备。

第二存储器21不仅可以用于存储安装于该文件下载装置2的应用软件及各类数据，例如文件下载程序20等，还可以用于暂时地存储已经输出或者将要输出的数据。

第二处理器22在一些实施例中可以是一中央处理器(Central Processing Unit,CPU)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行第二存储器21中存储的程序代码或处理数据，例如文件下载程序20等。

第二网络接口23可选的可以包括标准的有线接口、无线接口(如WI-FI接口)，通常用于在该文件下载装置2与其他电子设备之间建立通信连接。例如，客户端(图中未标注)或者负载均衡设备(图中未标注)。

图4仅示出了具有组件21-23的文件下载装置2，本领域技术人员可以理解的是，图4示出的结构并不构成对文件下载装置2的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

可选地，该文件下载装置2还可以包括用户接口，用户接口可以包括显示器(Display)、输入单元比如键盘(Keyboard)，可选的用户接口还可以包括标准的有线接口、无线接口。

可选地，在一些实施例中，显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及有机发光二极管(Organic Light-Emitting Diode，OLED)触摸器等。其中，显示器也可以称为显示屏或显示单元，用于显示在文件下载装置2中处理的信息以及用于显示可视化的用户界面。

在图4所示的文件下载装置2实施例中，作为一种计算机存储介质的第二存储器21中存储文件下载程序20的程序代码，第二处理器22执行文件下载程序20的程序代码时，实现如上述文件存储方法中的任意步骤。

可选地，在其他的实施例中，文件下载程序20还可以被分割为一个或者多个模块，一个或者多个模块被存储于第二存储器21中，并由一个或多个处理器(本实施例为第二处理器22)所执行，以完成本发明，本发明所称的模块是指能够完成特定功能的一系列计算机程序指令段。例如，参照图5所示，为图4中文件下载程序20的模块示意图，该实施例中，文件下载程序20可以被分割为第二接收模块210、判断索引信息获取模块220、下载模块230，所述模块210-230所实现的功能或操作步骤均与上文类似，此处不再详述。

此外，本发明实施例还提出一种计算机可读存储介质，所述计算机可读存储介质中包括文件存储/下载程序，所述文件/下载程序被处理器执行时，可实现如上所述文件存储/下载方法的任意步骤。

本发明之计算机可读存储介质的具体实施方式与上述文件存储/下载方法的具体实施方式大致相同，在此不再赘述。

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

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种文件存储方法，应用于服务器，其特征在于，所述方法包括：

S1、接收携带待存储文件的文件存储指令；

S2、根据所述待存储文件的文件大小判断所述待存储文件的类型，根据所述带存储文件的类型判断所述待存储文件是否需要打包存储；及

S3、当所述待存储文件需要进行打包存储时，确定与所述待存储文件对应的打包对象，将所述待存储文件存储到所述打包对象中，生成待存储文件对应的索引信息，并根据预设算法将所述索引信息保存至预设数据库中。

2.根据权利要求1所述的文件存储方法，其特征在于，所述步骤S2包括：

从所述待存储文件的属性信息中获取所述待存储文件的文件大小；

当所述待存储文件的文件大小小于或等于第一预设阈值时，判断所述待存储文件为小文件，需要对所述待存储文件进行打包存储；及

当所述待存储文件的文件大小大于第一预设阈值时，判断所述待存储文件为大文件，不需要对所述待存储文件进行打包存储。

3.根据权利要求1所述的文件存储方法，其特征在于，步骤S3中的所述确定与所述待存储文件对应的大对象，包括：

从预设的通用唯一识别码(Universally Unique Identifier，UUID)列表中筛选出对应缓存空间小于第二预设阈值的UUID，对筛选出的UUID对应的打包对象进行排序，生成打包对象列表；及

选择排序靠前的打包对象作为所述待存储文件对应的打包对象。

4.根据权利要求1所述的文件存储方法，其特征在于，所述生成待存储文件对应的索引信息，包括：

根据所述待存储文件的文件名及对应的桶名(bucket)确定索引信息中的键；

根据所述打包对象中已有字节确定索引信息中的偏移，根据所述待存储文件的大小确定文件长度，生成索引信息中的值；及

对所述键、值进行合并，确定所述待存储文件对应的索引信息。

5.根据权利要求4所述的文件存储方法，其特征在于，步骤S3中的所述根据预设算法将所述索引信息保存至预设数据库中，包括：

根据所述待存储文件的文件名计算所述待存储文件对应的文件名属性值；

从预先确定的预设数据库中的预设数量的虚拟节点中，选择编号与所述待存储文件对应的文件名属性值一致的虚拟节点作为所述待存储文件对应的索引信息的存储位置。

6.根据权利要求1至5中任意一项所述的文件存储方法，其特征在于，该方法还包括：

当所述待存储文件不需要进行打包存储，且所述待存储文件大小大于第二预设阈值时，对所述待存储文件进行分片存储。

7.根据权利要求6所述的文件存储方法，其特征在于，所述“对所述待存储文件进行分片存储”，包括：

将所述待存储文件进行分成大小小于或等于第三预设阈值的分片，生成多个待存储子文件及分片信息，根据预设算法将所述分片信息存储至预设数据库中；

对于不需打包存储的待存储子文件，从预设的UUID列表中筛选出多个对应缓存空间为第二预设阈值的UUID，依次将所述多个待存储子文件作为所多个UUID对应的打包对象；

对于需打包存储的待存储子文件，确定与所述需打包存储的待存储子文件对应的打包对象，将所述需打包存储的待存储子文件存储到所述打包对象中；及

生成所述多个待存储子文件对应的索引信息，并根据预设算法将所述索引信息保存至预设数据库中。

8.一种文件下载方法，其特征在于，该方法包括：

接收文件下载指令，所述文件下载指令中包括待下载文件的文件名及对应的桶名；

根据所述待下载文件的文件名确定所述待下载文件对应的索引信息的存储的虚拟节点，并从该虚拟节点读取所述索引信息；及

根据所述待下载文件的文件名、对应的桶名及所述索引信息确定所述待下载文件的存储位置，从所述存储位置获取所述待下载文件的数据，并将所述待下载文件反馈给客户端。

9.一种服务器，其特征在于，该服务器包括：第一存储器、第一处理器，所述第一存储器上存储有可在所述第一处理器上运行的文件存储程序，所述文件存储程序被所述第一处理器执行时，可实现如权利要求1至7中任意一项所述的文件存储方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中包括文件存储程序，所述文件存储程序被处理器执行时，可实现如权利要求1至7中任意一项所述的文件存储方法的步骤。