基于对象的分布式云存储方法与流程

本发明属于云计算技术领域，更具体地涉及一种基于对象的分布式云存储方法。

背景技术：

谷歌于 2006 年第一次提出云计算技术，就引发了世界云技术的浪潮，Amazon，国际商用机器，Microsoft 等国际跨国公司先后投入研究，成为技术领域的先行者。云计算技术的精髓在于谷歌所推出的开放式编程平台，它能够使得普通用户可以和专家一样去编写程序。其软件开源性使得用户可以获取代码并完善，这都极大的促进了云计算技术的飞速发展。云计算技术包括分布式计算处理、并行计算处理以及网格计算处理，引领着互联网技术的发展趋势，未来在理论研究或者工程研究上的发展都不可限量。根据当前的情况来看，国内的云计算还处在刚刚进入发展的阶段，估计2016年之后，国内的云计算将会大跨步前进，度过成长阶段进入成熟阶段，云计算提供商将会大幅提升其技术水平，也将会有更多的国内大型企业加入到使用云计算的行列中去，埃森哲的报告显示称中国企业对于云计算的安全性考虑上，导致用户的使用率明显低于国外，相反，私有云的建设却如火如荼，而公有云则较为冷清。技术的创新，还是在国内吸引了各大通信运营商的注意，例如中国移动推出的 Big Cloud 云平台，中国电信倡导的 E 云计划平台以及中国联通则是构建了互联云，各大通信运营商都依次开发了众多的软件服务，并搭建了规模较大的云计算实验平台，用于数据发掘，云存储以及大数据搜索引擎等研究。由此可见，云计算革命正在国内悄然的进行量的积累，相信在不久的将来，技术日渐成熟，终将在未来云计算领域占有一席之地。

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

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

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

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

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

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

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

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

本方法主要是为了应对数据海量增加对数据存储带来的挑战。现阶段传统的存储方式已经在容量、性能、智能化等方面无法满足现有的需求。本方法能从功能上弥补了传统存储的不足，通过虚拟化大容量存储、分布式存储和自动化运维等功能，实现了存储空间无限增加和扩容，自动化和智能化功能提高了存储效率。另外，规模效应和弹性扩展，降低运营成本，避免资源浪费。

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

对象存储是为了满足用户大数据量及非结构化数据的存储而出现的，它综合了NAS和SAN的优点，同时具有SAN 的高速直接访问和NAS的数据共享等优势，提供了具有高性能、高可靠性、跨平台以及安全的数据共享的存储体系结构。

技术实现要素：

1、本发明的目的。

本发明为了解决现有技术中线程开销大，运行效率低等问题，而提出了一种基于对象的分布式云存储方法。

2、本发明所采用的技术方案。

本发明基于对象的分布式云存储方法，对象存储系统包含两种数据描述：容器、对象，以对象为基本单位，容器和对象都有一个全局唯一的ID，根据ID访问容器/对象及相关的数据、元数据和对象属性，即扁平化存储结构管理所有数据。

更进一步具体实施例中，对象数据在磁盘上存储都是以二进制字节形式，对象为任意类型的文件数据。

更进一步具体实施例中，所述的对象存储时设置头信息标识对象，在启动对象存储系统时，通过扫描对象数据的头信息形成index。

更进一步具体实施例中，容器中的每个block对应一个index文件，写文件时先将文件数据追加到block的尾部，然后将文件的index插入到内存hash表，最后将文件的index追加到index文件；在存储服务重启时，每个block根据其index文件来快速建立内存hash表，文件写入时，往block追加文件数据时同步刷盘，然后将记录插入到内存hash表；追加index记录时，发送完追加请求即认为写文件成功。

更进一步具体实施例中，将index文件和index内存hash表合二为一，将index文件本身以hash表的方式组织，直接使用mmap将index文件映射到内存，每个index条目增加一个next字段用于连接冲突链。

更进一步具体实施例中，文件合并采用文件的权重算法：

对于一个给定的文件，为全局调节正常量，和表示文件i和j的文件大小，代表两个文件的相关性；当接近1时，说明两个文件的相关性很大，文件合并的优先级高；当接近0时，说明两个文件的相关性很小， 文件合并的优先级低。

更进一步具体实施例中，对象存储系统中对象数据文件上传步骤如下：

步骤1 用户上传文件，在网络服务器接收数据并判断文件大小，若大于10MB则跳转到步骤4；否则，进行步骤2；

步骤2 将文件放入到合并队列中；

步骤3 利用权重算法合并文件并建立索引；

步骤4利用HDFS将文件上传至集群；

更进一步具体实施例中，对象存储系统中对象数据文件下载步骤如下：

步骤1 网络服务器接收到用户下载文件的请求，首先查看文件该文件是否下载过，如果下载过，在缓存池进行查找该文件；

步骤2 查看索引文件确定目标文件是否合并过小文件，如果没有，则直接将文件给用户，如果有，进行步骤3；

步骤3 通过HDFS客户端向名字节点查询合并文件的块信息，缓存在数据块信息池中；

步骤4 由块信息向数据节点获取文件；

步骤5 拆分合并文件，并将拆分的文件放入文件池中，并利用LRU算法更新。

3、本发明的有益效果。

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

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

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

附图说明

图1为本发明现有技术块存储示意图

图2本发明对象存储示意图。

图3为本发明实施例二示意图。

图4为本发明实施例三示意图。

图5为本发明文件上传流程图。

图6为本发明文件下载流程图。

图7为本发明HDFS操作流程图。

具体实施方式

实施例1

如图2所示，基于对象的分布式云存储方法，对象存储系统包含两种数据描述：容器、对象，以对象为基本单位，容器和对象都有一个全局唯一的ID，根据ID访问容器/对象及相关的数据、元数据和对象属性，即扁平化存储结构管理所有数据。对象数据在磁盘上存储可采用二进制字节形式，对象为任意类型的文件数据。所述的对象存储时设置头信息标识对象，在启动对象存储系统时，通过扫描对象数据的头信息形成index。

这种方案的优点在于，每次存储文件时，只需要一次IO操作，不会出现索引与block实际文件数据不一致大情况；缺点在于，索引只存在于内存，当服务重启时，index信息需要根据block的数据来重建，这就要求文件在block中存储时，必须存储一些额外的头信息，比如magicnum，使得block的文件具有自描述能力，在每次启动时，通过扫描block数据来生成index。以2T磁盘、64MB block为例，磁盘上会有约30000个block；假设扫描一个block需要1s，那么启动时间约为500min * 0.8（磁盘使用率80%）= 400min，显然，每次启动时扫描block来生成index的开销是不可接受的。

实施例2

如图3所示，在实施例1的基础上，每个block对应一个index文件，写文件时先将文件数据追加到block的尾部，然后将文件的index插入到内存hash表，最后将文件的index追加到index文件；在存储服务重启时，每个block根据其index文件来快速建立内存hash表。

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

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

实施例3

如图4所示，在实施例2中index的数据实际上是存在两份的，一份是内存hash表里的，一份是index文件里的，因为linux的页缓存机制，文件里的index也是可能cache在内存里，所以方案二对内存的利用不是最优的，可以考虑将index文件和index内存hash表合二为一，将index文件本身以hash表的方式组织，直接使用mmap将index文件映射到内存。

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

实施例4

针对文件的合并，提出文件的权重算法：

对于一个给定的文件，为全局调节正常量，和表示文件i和j的文件大小，代表两个文件的相关性；当接近1时，说明两个文件的相关性很大，文件合并的优先级高；当接近0时，说明两个文件的相关性很小， 文件合并的优先级低。

实施例5

如图5所示，对象存储系统中对象数据文件上传步骤如下：

步骤1 用户上传文件，在网络服务器接收数据并判断文件大小，若大于10MB则跳转到步骤4；否则，进行步骤2；

步骤2 将文件放入到合并队列中；

步骤3 利用权重算法合并文件并建立索引；

步骤4利用HDFS将文件上传至集群；

实施例6

如图6所示，对象存储系统中对象数据文件下载步骤如下：

步骤1 网络服务器接收到用户下载文件的请求，首先查看文件该文件是否下载过，如果下载过，在缓存池进行查找该文件；

步骤2 查看索引文件确定目标文件是否合并过小文件，如果没有，则直接将文件给用户，如果有，进行步骤3；

步骤3 通过HDFS客户端向名字节点查询合并文件的块信息，缓存在数据块信息池中；

步骤4 由块信息向数据节点获取文件；

步骤5 拆分合并文件，并将拆分的文件放入文件池中，并利用LRU算法更新。

实施例7

如图7所示，HDFS文件操作流程索引文件不持久化存储，在内存里组织为hash表（或顺序表，如果能接受二分查找的性能）；存储时将文件追加到block尾部后，将文件在block内部的offset以及文件size信息，插入到hash表中；访问该文件时，先根据文件的id在hash表中定位文件的offset和size，然后在block对应位置读取文件数据，由于hash表是全内存化的，访问文件只需一次IO。