CN106446099A

CN106446099A - 一种分布式云存储方法、系统及其上传下载方法

Info

Publication number: CN106446099A
Application number: CN201610821623.4A
Authority: CN
Inventors: 都政; 漆萌; 熊超超; 陈远磊; 张冬云; 靳绍巍; 罗文龙; 易明祥
Original assignee: Shenzhen Cloud Computing Center Co Ltd; NATIONAL SUPERCOMPUTING CENTER IN SHENZHEN (SHENZHEN CLOUD COMPUTING CENTER)
Current assignee: Shenzhen Cloud Computing Center Co Ltd; NATIONAL SUPERCOMPUTING CENTER IN SHENZHEN (SHENZHEN CLOUD COMPUTING CENTER)
Priority date: 2016-09-13
Filing date: 2016-09-13
Publication date: 2017-02-22

Abstract

本发明公开了一种分布式云存储方法、系统及其上传下载方法，该分布式云存储方法包括：将文件数据追加至数据块尾部；将文件数据于数据块中的类型长度以及地址信息插入至内存的哈希表中；依据文件数据的ID定位哈希表中文件数据的类型长度以及地址信息；依据类型长度以及地址信息读取数据块对应位置的文件数据。该发明的有益效果为：降低启动时数据块生成索引的开销，提高了存储效率；解决了hash查找效率问题，提高了查找效率，避免资源浪费；另外，通过优化的方法减少上传或下载时的线程开销，提高运行效率。

Description

一种分布式云存储方法、系统及其上传下载方法

技术领域

本发明涉及分布式存储技术领域，尤其涉及一种分布式云存储方法、系统及其上传下载方法。

背景技术

云存储提供的是存储服务，存储服务通过网络将本地数据存放在存储服务提供商(SSP)提供的在线存储空间。需要存储服务的用户不再需要建立自己的数据中心，只需向SSP申请存储服务，从而避免了存储平台的重复建设，节约了昂贵的软硬件基础设施投资。云计算将扩张并走向成熟，会诞生许多新的公共云热点、私有云服务、云应用以及将公共云与私有云联系起来的服务。云存储系统与传统存储系统相比，具有如下不同：

第一，从功能需求来看，云存储系统面向多种类型的网络在线存储服务，而传统存储系统则面向如高性能计算、事务处理等应用；

第二，从性能需求来看，云存储服务首先需要考虑的是数据的安全、可靠、效率等指标，而且由于用户规模大、服务范围广、网络环境复杂多变等特点，实现高质量的云存储服务必将面临更大的技术挑战；

第三，从数据管理来看，云存储系统不仅要提供类似于POSIX的传统文件访问，还要能够支持海量数据管理并提供公共服务支撑功能，以方便云存储系统后台数据的维护。

数据存储层：云存储系统对外提供多种不同的存储服务，各种服务的数据统一存放在云存储系统中，形成一个海量数据池。从大多数网络服务后台数据组织方式来看，传统基于单服务器的数据组织难以满足广域网多用户条件下的吞吐性能和存储容量需求；基于P2P架构的数据组织需要庞大的节点数量和复杂编码算法保证数据可靠性。相比而言，基于多存储服务器的数据组织方法能够更好满足在线存储服务的应用需求，在用户规模较大时，构建分布式数据中心能够为不同地理区域的用户提供更好的服务质量。

云存储的数据存储层将不同类型的存储设备互连起来，实现海量数据的统一管理，同时实现对存储设备的集中管理、状态监控以及容量的动态扩展，实质是一种面向服务的分布式存储系统。

数据管理层：云存储系统架构中的数据管理层为上层提供不同服务间公共管理的统一视图。通过设计统一的用户管理、安全管理、副本管理及策略管理等公共数据管理功能，将底层存储及上层应用无缝衔接起来，实现多存储设备之间的协同工作，以更好的性能对外提供多种服务。

数据服务层：数据服务层是云存储平台中可以灵活扩展的、直接面向用户的部分。根据用户需求，可以开发出不同的应用接口，提供相应的服务。比如数据存储服务、空间租赁服务、公共资源服务、多用户数据共享服务、数据备份服务等。

传统的存储技术包括DAS、SAN和NAS，它们是基于块存储或文件存储。现有的科技文献中指出它们在面临海量数据存储时，会自呈现出不同的问题。DAS存储方式在数据请求和传送时需要文件服务器的参与，当大规模的数据访问时，这会给服务器的存储转发带来非常大的开销，从而文件服务器便成了整个系统中的性能瓶颈，而NAS的瓶颈是带宽要求，SAN因其架构封闭而无法整合不同系统，且它的规模过大成本较高。

对象存储是为了满足用户大数据量及非结构化数据的存储而出现的，它综合了NAS和SAN的优点，同时具有SAN的高速直接访问和NAS的数据共享等优势，提供了具有高性能、高可靠性、跨平台以及安全的数据共享的存储体系结构。如图1a及图1b所示，DAS、SAN和NAS以固定大小的数据块作为存储的基本单元，而对象存储以对象为基本单位，采用扁平化存储结构管理所有数据，特别适合大数据量和非结构化数据的存储。对象存储系统包含两种数据描述：容器(Bucket)、对象(Object)，容器和对象都有一个全局唯一的ID，只需要根据ID就可以访问容器/对象及相关的数据(Data)、元数据(metadata)和对象属性(Attribute)。

在数据库中，Object最后在磁盘上存储都是以二进制字节形式，对Object类型没有限制，可以存储任意类型的数据。

随着互联网的高速发展，数据量呈指数增长，海量数据的存储与分析已成为热门的研究领域。现有技术中，为了存储其内部无比庞大的数据，设计了分布式文件系统GFS(Google File System)。Hadoop分布式文件系统(Hadoop Distributed File System，HDFS)是GFS的Java开源实现，是一个可扩展的分布式文件系统，可以在廉价的硬件上运行，并且有可靠的容错能力。HDFS是一个不错的分布式文件系统，它有很多的优点，但也存在有一些缺点。目前而言，它在以下几个方面就效率不佳：

1.低延时访问：HDFS不太适合于那些要求低延时(数十毫秒)访问的应用程序，因为HDFS是设计用于大吞吐量数据的，这是以一定延时为代价的。HDFS是单Master的，所有的对文件的请求都要经过它，当请求多时，肯定会有延时。当前，对于那些有低延时要求的应用程序，HBase是一个更好的选择。现在HBase的版本是0.20，相对于以前的版本，在性能上有了很大的提升，它的口号就是goes real time。使用缓存或多master设计可以降低client的数据请求压力，以减少延时。可以通过对HDFS系统内部的修改，这时需权衡大吞吐量与低延时了。

2.大量小文件：Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间。如果有100万个文件，每一个占据一个Block，就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。

在云链系统中，用户可以通过B/S模式访问系统，进行文件的上传、下载操作。在实际使用中，用户经常上传、下载体积较小的图片、文档到云链网站。当数量达到一定程度时，就暴露出了HDFS的一个缺陷：对大量小文件的处理比较乏力。HDFS能支持超大文件和快速应对硬件故障，是通过将文件切分成多个块(默认块大小为64MB)，以机架感知(RackAwareness)的方式存储在多个数据节点(DataNode)上，并将文件的元数据保存在名称节点(NameNode)的内存中，包括文件到数据块的映射信息和数据块到数据节点的映射信息。每个文件需要保存的信息约为150Byte。如果存储107个小文件，每个文件占用一个数据块，则名称节点大约需要2GB内存空间。如果存储109个文件，则名称节点需要200GB的内存空间。由此可见，名称节点的内存空间制约了Hadoop集群的扩展。另一方面，访问大量小文件的速度远小于访问少量大文件的速度。如上述所述，HDFS是通过流式数据的方式访问文件，如果访问大量的小文件，则需要不断从一个数据节点跳转到另一个数据节点，严重影响了系统性能。

对于小文件的问题，一方面，Hadoop系统自身提供了3个解决方法，分别是HadoopArchive，Sequence File和Map File。

Hadoop Archive是通过执行MapReduce任务将多个小文件归档成一个HAR文件，保证在减少名称节点内存使用的同时，能够对文件进行透明访问。但该方案存在以下缺陷：生成的HAR文件不能更改，要增加、删除文件必须重建。归档的文件名内不能包含空格，否则会抛出异常；合并耗时很长，读取时间甚至比从原始HDFS中读取耗时更长。

Sequence File通过key-value键值对的形式存储小文件，以key为小文件名、value为小文件内容，将大量小文件合并成一个大文件。但是，由于其没有索引，读取任一小文件都需要遍历整个大文件，因此该方案并不适合低延时的随机访问，而更适合MapReduce类型的作业。

Map File类似于Sequence File，以键值对存储小文件，并维护了一个部分索引，默认为每隔128个key记录一个到索引文件中，读取性能优于Sequence File。但是，该方案读取一个文件还是要遍历一个索引间隔，仍不适合低延时的随机读取。

目前研究人员对基于HDFS的小文件做了不少改进。现有文献针对WebGIS系统的数据特点，将保存相邻地理位置信息的小文件合并成一个大的文件，并对所有小文件建立哈希索引，有效提高了小文件的存取效率。另有文献针对“中华字库”工程，提出了一种层次索引的小文件合并方法，实现部分索引文件在集群中的分布式存储，将索引信息作为独立的存储文件，与对应的block块一起存储到同一数据节点的同一位置，有效提高了小文件的存储和读取效率，适合应用在一定目录结构的海量小文件存储的应用场合。此外，现有技术还根据文件之间的相关性设定优先级，对小于5MB的文件按优先级高低合并后再上传，并生成索引记录。结合随机化思想，采用两级缓存策略，将预提取数据缓存在内存池中，提高访问效率。

发明内容

本发明要解决的技术问题在于，针对上述现有技术中传统的存储方法在容量、性能、智能化无法满足现有的需求，而且不易进行规模效应及弹性扩展，造成运营成本高、资源浪费的问题，提供一种分布式云存储方法、系统及其上传下载方法。

本发明解决其技术问题所采用的技术方案是：

一方面，构造一种分布式云存储方法，包括：

将文件数据追加至数据块尾部；

将所述文件数据于所述数据块中的类型长度以及地址信息插入至内存的哈希表中；

依据所述文件数据的ID定位所述哈希表中所述文件数据的类型长度以及地址信息；

依据所述类型长度以及地址信息读取数据块对应位置的文件数据。

在本发明所述的分布式云存储方法中，所述将文件数据追加至数据块尾部的步骤包括以下子步骤：

设置数据块对应的索引文件；

将文件数据追加至数据块尾部，并将所述文件数据的索引信息插入至所述哈希表中；

将所述索引信息追加至所述索引文件。

在本发明所述的分布式云存储方法中，所述将文件数据追加至数据块尾部的步骤还包括以下子步骤：

将所述索引文件与所述哈希表的建立对应关系，并将所述索引文件映射到内存中；

于所述索引信息中增加用于连接冲突链的next字段。

一方面，提供一种分布式云存储系统，包括文件数据追加模块、哈希插入模块、文件数据定位模块以及文件数据读取模块；

所述文件数据追加模块用于将文件数据追加至数据块尾部；

所述哈希插入模块用于将所述文件数据于所述数据块中的类型长度以及地址信息插入至内存的哈希表中；

所述文件数据定位模块用于依据所述文件数据的ID定位所述哈希表中所述文件数据的类型长度以及地址信息；

所述文件数据读取模块用于依据所述类型长度以及地址信息读取数据块对应位置的文件数据。

在本发明所述的分布式云存储系统中，所述文件数据追加模块包括：

索引文件设置子模块，用于设置数据块对应的索引文件；

索引信息插入子模块，用于将文件数据追加至数据块尾部，并将所述文件数据的索引信息插入至所述哈希表中；

索引文件追加子模块，用于将所述索引信息追加至所述索引文件。

在本发明所述的分布式云存储系统中，所述文件数据追加模块还包括：

关系建立子模块，用于将所述索引文件与所述哈希表的建立对应关系，并将所述索引文件映射到内存中；

字段增加子模块，用于在所述索引信息中增加用于连接冲突链的next字段。

一方面，提供一种基于分布式云存储系统的上传下载方法，提供如上所述的分布式云存储系统，包括文件数据上传步骤以及文件数据下载步骤。

在本发明所述的上传下载方法中，所述上传步骤包括以下子步骤：

S101、藉由网络服务器接收所需上传的文件数据，判断所述文件数据的大小是否大于预设值，若是，转至步骤S103，若否，转至步骤S102；

S102、将所述文件数据加入合并队列中，并依据权重算法合并所述文件数据；

S103、藉由HDFS客户端将所述文件数据存储至集群系统。

在本发明所述的上传下载方法中，所述下载步骤包括以下子步骤：

S201、藉由网络服务器接收下载文件数据的请求；

S202、检查所述文件数据是否被下载过，若否，转至步骤S203，若是，转至步骤S204；

S203、从集群系统下载所述文件数据至缓存；

S204、查找所述文件数据；

S205、依据所述文件数据的索引信息判断所述文件数据是否被合并过，若是，转至步骤S206，若否，向所述集群系统的数据节点获取所述文件数据并转至步骤S209；

S206、藉由HDFS客户端向集群系统的名称节点查询所述文件数据的数据块信息，并缓存在数据块池中；

S207、依据所述数据块信息向所述集群系统的数据节点获取待拆分的文件数据；

S208、拆分待拆分的文件数据并将其存放至文件池中；

S209、将所述文件数据藉由所述网络服务器返回给用户。

在本发明所述的上传下载方法中，所述权重算法为：

其中，α为全局调节正常量，I_i及I_i表示两个文件数据，w_ij表示两个所述文件数据的相关性，依据所述相关性确定两个所述文件数据合并的优先级。

上述公开的一种分布式云存储方法、系统及其上传下载方法具有以下有益效果：降低启动时数据块生成索引的开销，提高了存储效率；解决了hash查找效率问题，提高了查找效率，避免资源浪费；另外，通过优化的方法减少上传或下载时的线程开销，提高运行效率。

附图说明

图1a为现有技术的块存储的示意图；

图1b为现有技术的对象存储的示意图；

图2为本发明提供的一种分布式云存储方法的流程图；

图3为本发明一实施例提供的基于对象的分布式缓存系统的结构示意图；

图4为本发明一实施例提供的HDFS操作流程图；

图5为本发明第一实施例提供的数据块与索引信息的关系示意图；

图6为本发明第二实施例提供的数据块与索引信息的关系示意图；

图7为本发明第三实施例提供的数据块与索引信息的关系示意图；

图8为本发明一实施例提供的一种基于分布式云存储系统的上传方法的流程图；

图9为本发明一实施例提供的一种基于分布式云存储系统的下载方法的流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明提供了一种分布式云存储方法、系统及其上传下载方法，其目的在于，降低启动时数据块生成索引的开销，提高了存储效率；解决了hash(哈希)查找效率问题，提高了查找效率，避免资源浪费；另外，通过优化的方法减少上传或下载时的线程开销，提高运行效率。从而应对数据海量增加对数据存储带来的挑战。现阶段传统的存储方式已经在容量、性能、智能化等方面无法满足现有的需求。本方法能从功能上弥补了传统存储的不足，通过虚拟化大容量存储、分布式存储和自动化运维等功能，实现了存储空间无限增加和扩容，自动化和智能化功能提高了存储效率。另外，规模效应和弹性扩展，降低运营成本，避免资源浪费。

参见图2，图2为本发明提供的一种分布式云存储方法的流程图，该分布式云存储方法采用如图3所示的系统，图3为本发明一实施例提供的基于对象的分布式缓存系统100的结构示意图，该分布式缓存系统100包括服务层1、业务处理层2及存储层3，业务处理层2包括网络服务器21、文件合并区22、HDFS客户端23、索引信息24、文件池25及数据块池26，存储层3包括名称节点31及一至多个数据节点32，该分布式云存储方法主要针对HDFS客户端23与存储层3之间的分布式云存储的部署，服务层1为用户操作端，参见图4，图4为本发明一实施例提供的HDFS操作流程图，HDFS文件操作流程为图4中的101-106：

101、HDFS客户端23打开分布式计算。

102、从名称节点31处获得数据块201位置。

103、HDFS客户端23读取FSData InputStream数据流。

104-105、向一至多个数据节点32读取数据。

106、HDFS客户端23关闭FSData InputStream数据流。

具体的，该分布式云存储方法包括以下步骤S1-S4：

S1、将文件数据追加至数据块201尾部。该实施例参见图5，图5为本发明第一实施例提供的数据块201与索引信息24的关系示意图，该实施例主要针对索引文件203不持久化存储，在内存中组织为哈希表202(或顺序表，如果能接受二分查找的功能)；存储时将文件数据追加到block(数据块201)尾部后。该实施例中，由于哈希表202是全闪存化的，访问文件只需一次IO(Input/Output)，这种方案的优点在于，每次存储文件时，只需要一次IO操作，不会出现索引与block实际文件数据不一致大情况；缺点在于，索引只存在于内存，当服务重启时，index信息需要根据block(数据块201)的数据来重建，这就要求文件在block中存储时，必须存储一些额外的头信息，比如magicnum，使得block的文件具有自描述能力，在每次启动时，通过扫描block数据来生成index。以2T磁盘、64MB block为例，磁盘上会有约30000个block；假设扫描一个block需要1s，那么启动时间约为500min*0.8(磁盘使用率80％)＝400min，显然，每次启动时扫描block来生成index的开销是不可接受的。其中，slot为周边元件扩展插槽。

参见图6，图6为本发明第二实施例提供的数据块201与索引信息24的关系示意图，该实施例中，步骤S1包括以下子步骤S11-S13：

S11、设置数据块201对应的索引文件203；即在第一实施例的基础上，每个block对应一个index文件。

S12、将文件数据追加至数据块201尾部，并将所述文件数据的索引信息24插入至所述哈希表202中；写文件时先将文件数据追加到block的尾部，然后将文件的index(索引信息24)插入到内存hash表。

S13、将所述索引信息24追加至所述索引文件203，即最后将文件的index追加到index文件(索引文件203)；在存储服务重启时，每个block根据其index文件来快速建立内存hash表。

该实施例解决了索引重建的问题，但其每次写文件需要两次IO，写文件的延时就高了。为了降低写的延时，在文件写入时，往block追加文件数据时同步刷盘，然后将记录插入到内存hash表，接下来追加index记录时，发送完追加请求就认为写文件成功，即index并不立即刷盘，这样写的延时缩短到一次IO。

文件index异步追加，可能导致一个问题，文件在block里存在，但在index文件里没有这个文件的记录，在根据index文件重建内存hash表时，hash表就是不完整的，导致部分文件访问不到。为了解决这个问题，haystack通过在重建时，从block尾部开始扫描，找出所有可能缺失index的文件，并生成index追加到index文件。(因为文件在block和index里顺序相同，缺失index的文件一定是在block尾部的一批)

参见图7，图7为本发明第三实施例提供的数据块201与索引信息24的关系示意图，该实施例建立在第二实施例的基础上，步骤S1还包括以下子步骤S14-S15：

S14、将所述索引文件203与所述哈希表202的建立对应关系，并将所述索引文件203映射到内存中；即第二实施例中index的数据实际上是存在两份的，一份是内存hash表里的，一份是index文件里的，因为linux的页缓存机制，文件里的index也是可能cache在内存里，所以方案二对内存的利用不是最优的，可以考虑将index文件和index内存hash表合二为一，将index文件本身以hash表的方式组织，直接使用mmap(将一个文件或者其它对象映射进内存)将index文件映射到内存。

S15、于所述索引信息24中增加用于连接冲突链的next字段。通过将index文件和内存hash表合二为一，操作内存index即为操作index文件，管理index会方便不少。为了解决hash冲突问题，每个index条目需要额外增加一个next字段用于连接冲突链。这种方案还存在hash扩展的问题，当block内存储的小文件数量很多时，按照预估的hash桶数(预估值通常不会太大，太大会有很多空间浪费)，可能会导致冲突链很长，这时要提高hash查找的效率就必须扩展桶的数量，如果使用第一实施例，扩展只会导致额外的内存拷贝，而在这个方案里，则会导致整个index文件重写，会产生IO操作。

S2、将所述文件数据于所述数据块201中的类型长度以及地址信息插入至内存的哈希表202中；其中，size用来读取指定源地址数据的类型长度，offset用来读取指定数据的偏移地址，即将文件在block内部的offset以及文件size信息，插入到hash表中。

S3、依据所述文件数据的ID定位所述哈希表202中所述文件数据的类型长度以及地址信息；即访问该文件时，先根据文件的id在hash表中定位文件的offset和size。

S4、依据所述类型长度以及地址信息读取数据块201对应位置的文件数据。即在block对应位置读取文件数据。Block(数据块201)为数据库中的最小存储和处理单位，包含块本身的头信息数据或PL/SQL代码。

分布式云存储系统通过在如图3所示的基于对象的分布式缓存系统100中部署相应的软件实现，该分布式云存储系统包括文件数据追加模块、哈希插入模块、文件数据定位模块以及文件数据读取模块。

所述文件数据追加模块用于将文件数据追加至数据块201尾部；

所述哈希插入模块用于将所述文件数据于所述数据块201中的类型长度以及地址信息插入至内存的哈希表202中；

所述文件数据定位模块用于依据所述文件数据的ID定位所述哈希表202中所述文件数据的类型长度以及地址信息；

所述文件数据读取模块用于依据所述类型长度以及地址信息读取数据块201对应位置的文件数据。

优选的，所述文件数据追加模块包括：

索引文件203设置子模块，用于设置数据块201对应的索引文件203；

索引信息24插入子模块，用于将文件数据追加至数据块201尾部，并将所述文件数据的索引信息24插入至所述哈希表202中；

索引文件203追加子模块，用于将所述索引信息24追加至所述索引文件203。

优选的，所述文件数据追加模块还包括：

关系建立子模块，用于将所述索引文件203与所述哈希表202的建立对应关系，并将所述索引文件203映射到内存中；

字段增加子模块，用于在所述索引信息24中增加用于连接冲突链的next字段。

此外，基于分布式云存储系统的上传下载方法采用如上所述的分布式云存储系统，该基于分布式云存储系统的上传下载方法包括文件数据上传步骤以及文件数据下载步骤。

参见图8，图8为本发明一实施例提供的一种基于分布式云存储系统的上传方法的流程图，所述上传步骤包括以下子步骤S101-S103：

S101、藉由网络服务器21接收所需上传的文件数据，判断所述文件数据的大小是否大于预设值，若是，转至步骤S103，若否，转至步骤S102；例如，用户上传文件，通过网络服务器21接收并判断所需上传的文件数据的大小，预设值可以设为10MB。

S102、将所述文件数据加入合并队列中，并依据权重算法合并所述文件数据；优选的，所述权重算法为：

其中，α为全局调节正常量，I_i及I_i表示两个文件数据，w_ij表示两个所述文件数据的相关性，依据所述相关性确定两个所述文件数据合并的优先级。当w_ij接近1时，说明两个文件的相关性很大，文件合并的优先级高。当w_ij接近0时，说明两个文件的相关性很小，文件合并的优先级低。

此外，还可设置合并文件的策略：

对于一个已选中的待合并文件，对其余合并队列中的小文件定义相对优先级。根据文件的属性，优先级按一下顺序由高到低排列：

优先级1、同一用户的相同类型文件；

优先级2、同一用户的不同类型文件；

优先级3、不同用户的相同类型文件；

优先级4、不同用户的不同类型文件。

针对不同的优先级，制定相应的合并策略：

策略1、优先选取优先级高的文件进行合并。

策略2、对于同一优先级的文件，优先选取合并后最接近块大小的文件。

策略3、文件合并后不能超过块大小，避免跨块保存。

S103、藉由HDFS客户端23将所述文件数据存储至集群系统，集群系统对应于图3中的存储层3。

参见图9，图9为本发明一实施例提供的一种基于分布式云存储系统的下载方法的流程图，所述下载步骤包括以下子步骤：

S201、藉由网络服务器21接收用户下载文件数据的请求；

S203、从集群系统下载所述文件数据至缓存；

S204、查找所述文件数据；即在缓存中查找该文件数据。

S205、依据所述文件数据的索引信息24判断所述文件数据是否被合并过，若是，转至步骤S206，若否，向所述集群系统的数据节点32获取所述文件数据并转至步骤S209；

S206、藉由HDFS客户端23向集群系统的名称节点31查询所述文件数据的数据块201信息，并缓存在数据块201池26中；

S207、依据所述数据块201信息向所述集群系统的数据节点32获取待拆分的文件数据；

S208、拆分待拆分的文件数据并将其存放至文件池25中；利用LRU(LeastRecently Used)算法更新，即最近最少使用，常用于页面置换算法。

S209、将所述文件数据藉由所述网络服务器21返回给用户。

综上所述，本发明提供的分布式云存储方法、系统及其上传下载方法具有以下有益效果：

(1)针对性强：针对小文件的云存储，采用权值合并算法，减少线程开销，提高运行效率。

(2)适应性高：对于不同的文件结构，对文件进行对象封装。

(3)效率高：对文件的下载地址进行md5加密，以加密后的值为key，文件为value，进行存储。避免文件重复下载。

本文提供了实施例的各种操作。在一个实施例中，所述的一个或操作可以构成一个或计算机可读介质上存储的计算机可读指令，其在被电子设备执行时将使得计算设备执行所述操作。描述一些或所有操作的顺序不应当被解释为暗示这些操作必需是顺序相关的。本领域技术人员将理解具有本说明书的益处的可替代的排序。而且，应当理解，不是所有操作必需在本文所提供的每个实施例中存在。

而且，本文所使用的词语“优选的”意指用作实例、示例或例证。奉文描述为“优选的”任意方面或设计不必被解释为比其他方面或设计更有利。相反，词语“优选的”的使用旨在以具体方式提出概念。如本申请中所使用的术语“或”旨在意指包含的“或”而非排除的“或”。即，除非另外指定或从上下文中清楚，“X使用A或B”意指自然包括排列的任意一个。即，如果X使用A；X使用B；或X使用A和B二者，则“X使用A或B”在前述任一示例中得到满足。

而且，尽管已经相对于一个或实现方式示出并描述了本公开，但是本领域技术人员基于对本说明书和附图的阅读和理解将会想到等价变型和修改。本公开包括所有这样的修改和变型，并且仅由所附权利要求的范围限制。特别地关于由上述组件(例如元件、资源等)执行的各种功能，用于描述这样的组件的术语旨在对应于执行所述组件的指定功能(例如其在功能上是等价的)的任意组件(除非另外指示)，即使在结构上与执行本文所示的本公开的示范性实现方式中的功能的公开结构不等同。此外，尽管本公开的特定特征已经相对于若干实现方式中的仅一个被公开，但是这种特征可以与如可以对给定或特定应用而言是期望和有利的其他实现方式的一个或其他特征组合。而且，就术语“包括”、“具有”、“含有”或其变形被用在具体实施方式或权利要求中而言，这样的术语旨在以与术语“包含”相似的方式包括。

本发明实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。上述提到的存储介质可以是只读存储器，磁盘或光盘等。上述的各装置或系统，可以执行相应方法实施例中的存储方法。

综上所述，虽然本发明已以优选实施例揭露如上，但上述优选实施例并非用以限制本发明，本领域的普通技术人员，在不脱离本发明的精神和范围内，均可作各种更动与润饰，因此本发明的保护范围以权利要求界定的范围为准。

Claims

1.一种分布式云存储方法，其特征在于，包括：

将文件数据追加至数据块尾部；

2.根据权利要求1所述的分布式云存储方法，其特征在于，所述将文件数据追加至数据块尾部的步骤包括以下子步骤：

设置数据块对应的索引文件；

将所述索引信息追加至所述索引文件。

3.根据权利要求2所述的分布式云存储方法，其特征在于，所述将文件数据追加至数据块尾部的步骤还包括以下子步骤：

于所述索引信息中增加用于连接冲突链的next字段。

4.一种分布式云存储系统，其特征在于，包括文件数据追加模块、哈希插入模块、文件数据定位模块以及文件数据读取模块；

所述文件数据追加模块用于将文件数据追加至数据块尾部；

5.根据权利要求4所述的分布式云存储系统，其特征在于，所述文件数据追加模块包括：

索引文件设置子模块，用于设置数据块对应的索引文件；

6.根据权利要求5所述的分布式云存储系统，其特征在于，所述文件数据追加模块还包括：

7.一种基于分布式云存储系统的上传下载方法，提供如权利要求4所述的分布式云存储系统，其特征在于，包括文件数据上传步骤以及文件数据下载步骤。

8.根据权利要求7所述的上传下载方法，其特征在于，所述上传步骤包括以下子步骤：

S103、藉由HDFS客户端将所述文件数据存储至集群系统。

9.根据权利要求7所述的上传下载方法，其特征在于，所述下载步骤包括以下子步骤：

S201、藉由网络服务器接收下载文件数据的请求；

S203、从集群系统下载所述文件数据至缓存；

S204、查找所述文件数据；

S208、拆分待拆分的文件数据并将其存放至文件池中；

S209、将所述文件数据藉由所述网络服务器返回给用户。

10.根据权利要求8所述的上传下载方法，其特征在于，所述权重算法为：

w_{i j} = e^{- α | I_{i} - I_{j} |}

其中，α为全局调节正常量，I_i及I_j表示两个文件数据，w_ij表示两个所述文件数据的相关性，依据所述相关性确定两个所述文件数据合并的优先级。