fastdfs云存储毕业论文

1.云计算存储开发

2003年，谷歌发表论文GFS，披露解决了索引地球的海量互联网数据的存储问题。2006年，亚马逊推出了划时代的AWS云计算服务EC2和S3，开启了改变世界IT格局的云计算时代。谷歌，微软，阿里云等。都跟着。

上面提到的A Bite os S3 Arch如何构建一个分布式存储系统来支持大规模S3对象存储。云计算还有另外两个重要的基础存储基础架构组件EBS(弹性块存储)和EFS(弹性文件服务)，分别对应传统IT基础架构中的本地磁盘和共享文件存储服务。

云计算很重要的一点就是超卖和灵活性，所以支持EBS和EFS方案的底层基础存储层的支持不太可能是本地本地化方案，必须是分布式的存储资源管理和分配系统。

然而，与S3服务相比，EBS底层的分布式存储系统提供的IO模型实际上有很大不同。S3的基本外部接口功能是PUT/GET/DELETE，它对底层分布式文件系统的要求是Append。EBS和EFS需要支持对用户随机地址空间的重写，那么如何设计底层存储系统来支持这两类服务呢？

对于这一块的业务架构，目前各大互联网公司基本都没有开源，基本架构也没有或者很少正面出来。这一方面可能被视为商业秘密，另一方面可能从安全、舆论等方面考虑。

当然，开源系统的论文和一些互联网公司的存储系统可以参考，比如ceph、Lustre、HDFS、GlusterFS、FastDFS、Window Azure Storage、GFS等等。这些都称自己为分布式文件系统，但是在具体的场景和文件的定义上有很多不同。以下几个方面差别很大。

EBS底层的分布式存储系统至少需要确保以下几点

EBS底层分布式存储系统需要提供上述重要特性，还有一些重要的核心需求。

那么如何设计和构建EBS底层的分布式存储系统来满足业务的需求，也就是如何设计一个向上层业务提供随机IO能力的分布式存储系统。这里有一些可能的方法来建立它。

对于EBS业务，抽象地说，需要底层分布式文件系统提供可以随机读写的文件的能力。按照最直接的方式，可以如下图逻辑映射。1TB Vdisk /dev/sad对应的是底层分布式文件系统为/foo/sda的文件。1TB地址空间上的chunk是按需分配的，分配的基本单元一般是固定的，如下图，4MB。

Qemu等。提供了对接块设备驱动的API，只要在分布式文件系统对接对应的客户端实现API，块设备就可以向上输出。

网易实现了这种从0到1的构建方式。CURVE现在是开源的(百度类似于这个方案)，底层抽象为典型的分布式文件系统，向服务输出具有随机读写能力的文件，以支持上层块设备的EBS类型服务。架构基本类似于经典分布式文件系统的鼻祖GFS，如下图所示。

基础设施

数据表面核心

底层ChunkServer基于Raft)状态机来实现副本一致性。有关详细信息，请参见Raft对等复制状态机。所有上层用户的写入都依赖于一致性协议来确保多个副本的一致性，每个用户的区块都分配给这些复制组。

如上图所示

这种架构方案优点是：

该方案的缺点：

上述构建模式1是一种0对1的架构设计和实现。第二种构造方法主要是和圈内的童鞋沟通，细节无法研究，但从整体结构层面解释分析没有大问题。

其基本架构类似于Window Azure Storage的架构。Stream层构建在底层，Partition层构建在Stream层的基础上(类似GFS)，EBS方案可以构建在Partition层的基础上(类似BigTable)。

如何支持基于这种架构的服务，需要从另一个角度思考如何解决这个问题。回到问题的出发点，EBS随机地址空间读写方案的核心是什么问题？

简单来说，块设备提供对每个地址空间(比如4KB)的原子读写(PUT/GET)。换句话说，如果为每个EBS实例的每个4KB内容定义了一个全局可编码的惟一键，那么它的内容就是4KB的固定大小值。那么底层的分布式存储系统就是一个专用的分布式键值系统。

构造方法2基本上遵循这样的思想。

作为上面的基本逻辑视图示例，底层物理层结构如下图所示。

StreamLayer:类似于GFS/HDFS层次结构，每个流类似于一个文件，流只支持append。Stream由盘区组成(类似于HDFS/GFS的chunk)，盘区使用固定复制组的方案实现多个副本/EC(参考微软PacificA协议)。范围支持可变长度。当盘区不可用时，seal/new创建一个新的盘区继续提供写入，以保证写入的高可用性。

分区服务器：提供一段表(根据字典

序分裂）的kv 存储服务（增/删/改/查）。其通过WAL实现数据的快速和及时写入，保障数据的持久性；然后写入MemStore（SkipList跳表实现），在MemStore达到固定大小，比如128MB的时候Dump成SSTable（Sorted String Table），Block Cache 负责SStable 热点数据的读缓存。一个Partiton Server 负责多个Partition。

架构方面的更加具体的参考Window Azure Storage 的paper或者BigTable开源实现方面的书籍和资料，这里不多做展开。

在实际操作层面，对于一个上层的EFS实例，有挺多的映射关系：

一般来说为了实现EFS的快照和克隆功能，一个EFS实例一般都选择一个table。如果是只有一个WAL，写入的吞吐容易受影响，可以在上层使用一定的间接的业务逻辑手段使得多个相邻的地址空间换分到不同的Region，从而把上层IO映射到更多的Region，使用多个WAL写入能力提升带宽。比如将地址空间按照1MB取模划分到4个独立的连续字典序区间Region。

此种构架方案的优点：

反脆弱：这是这种方案我认为最最大的优点，也是相比方案一的绝对杀手锏，很多分布式存储系统其实从 基层层面都没有好好考虑这个问题，或者到意识到这种方案的巨大优势。即从读层面WAS基本实现了 已经seal 数据的任何副本是可读的。对于写数据来说，由于写入只限制在当前 尚未seal 掉的chunk上，也就是3个磁盘上，并且在故障情况下随时可以seal掉转移。这两点使得虽然 上层一个table的数据打散到底层这么多磁盘上。但是从爆炸半径来说，基本上算是实现了本地盘方案的爆炸半径，甚至在故障，过载情况下可以实现快速转移。从这点上来说，这样基本为分布式存储方案去完全干掉本地存储方案，打下了极其坚实的基础。

此种构建方案的缺点：

构建方案3类似方案2的变种。核心的不同点在于，构建方案2的全局排序和垃圾回收工作依赖于后期的compaction。而构建方式3倾向于尽可能块得进行原地排序。

其基本原理是，通过WAL 写入确保数据持久性，然后使用到内存。后台定期将写入原地使用到随机读写文件（没错，底层除了需要实现AppendFile，还需要实现弱一致的随机读写文件RandomFile，多幅本的数据一致性由Client负责，这引入一个缺点，随机读写文件很难做EC），WAL使用seal-new的方式确保写入可用性，读取采用Merge 更新数据（wal） 基线数据（随机读写文件数据）的方式实现数据的读取。在内存中建立对整个WAL内容的索引，最新的数据在WAL中则直接从WAL中读取，否则从随机读写文件中读取，其基本读写流程图如下

写入：写入还是一样写入WAL，然后更新内存索引，将最新数据的使用MemTable(Hash表)指向WAL。但是最终结果的Dump其实并不是按照sstable的方式，而是直接后台异步dump到对应RandomFile的随机地址空间。

PS1：WAL 也是类似Segment方式，定期做checkpoint（刷入RandomFile），在内存中会构建所有WAL segment的索引，WAL采用Seal/New的方式来保障可用性。

PS2: RandomFile是随机读写文件，为了保障WAL长度的收敛性，后台线程会将WAL数据写入RandomFile。RandomFile 没法使用Seal-New的可用性，但是由于是BackGround的写入。所以如果发现一个副本失败，会使得BackGround dump机制阻塞（这种方案在坏盘恢复场景下，会导致BackGround写入会卡很久）。

读取: 读取会首先通过Memtable查找最新数据是否在WAL中，不存在的情况下再读RandomFile。对于RandomFile未达到一致性状态的数据，会从WAL里头进行读取。（PS:由于WAL(AppendFile) 到 RandomFile的写入是全三副本，并且一直是卡着的，所以RandomFile的恢复可以采用很鲁棒的方式，直接选中任意一个还在复制组中的副本作为数据源复制。)

这种方案可以一定程度解决。读放大、空间利用率等方面的问题。但是在克隆、快照等方面会稍微差一些，并且随机读写文件很难做EC（EC改写好麻烦）。

如上对3种构建方式进行了简要的构建和优缺点的说明。没有绝对的那个构建方案优于另外一个构建方案。在实践过程中应结合自身面向的实际业务特点和技术条件等进行选择，能快速跟上业务发展并且对方案做中长期的评估适时进行调整。

很重要一点是一定得进行抽丝剥茧、形而上得分析问题的本质。这样才能够把精力集中在真正的问题上，好钢放在刀刃上。

简单来说，块设备提供了对每一个地址空间（比如4KB）的原子写入和读取(PUT/GET)。换一个角度来说如果对每一个EBS实例的每一个4KB内容定义一个全局可编码的唯一Key，其内容为4KB的固定大小的Value。那么这个底层分布式存储系统就是一个专用的分布式Key-Value系统。

以上不同的方案，从逻辑上往上抽象都可以认为是向业务提供KV存储。最本质的区别可以认为是排序在什么时候进行。构建方案1总体来说是即刻全局排序。构建方案2 则采用局部有序的方案。而架构方案3则 使用架构方案1和方案2 的折中。

另外一个很重要的差别是从核心可靠性的角度来说，构建方案1采用了多数派（如Raft）方案应对分布式的CAP问题。而构建方案2、3采用PrimayBackup Master（多数派） Append Only的特点来应对CAP问题。

问题一：当前主流分布式文件系统有哪些?各有什么优缺点 目前几个主流的分布式文件系统除GPFS外，还有PVFS、Lustre、PanFS、GoogleFS等。 (Parallel Virtual File System)项目是Clemson大学为了运行Linux集群而创建的一个开源项目,目前PVFS还存在以下不足： 1）单一管理节点:只有一个管理节点来管理元数据，当集群系统达到一定的规模之后，管理节点将可能出现过度繁忙的情况，这时管理节点将成为系统瓶颈; 2）对数据的存储缺乏容错机制:当某一I/O节点无法工作时，数据将出现不可用的情况; 3）静态配置:对PVFS的配置只能在启动前进行，一旦系统运行则不可再更改原先的配置。 文件系统是一个基于对象存储的分布式文件系统，此项目于1999年在Carnegie Mellon University启动，Lustre也是一个开源项目。它只有两个元数据管理节点,同PVFS类似,当系统达到一定的规模之后，管理节点会成为Lustre系统中的瓶颈。 (Panasas File System)是Panasas公司用于管理自己的集群存储系统的分布式文件系统。 (Google File System)是Google公司为了满足公司内部的数据处理需要而设计的一套分布式文件系统。 5.相对其它的文件系统，GPFS的主要优点有以下三点： 1)使用分布式锁管理和大数据块策略支持更大规模的集群系统,文件系统的令牌管理器为块、inode、属性和目录项建立细粒度的锁，第一个获得锁的客户将负责维护相应共享对象的一致性管理，这减少了元数据服务器的负担; 2)拥有多个元数据服务器,元数据也是分布式,使得元数据的管理不再是系统瓶颈; 3)令牌管理以字节作为锁的最小单位,也就是说除非两个请求访问的是同一文件的同一字节数据,对于数据的访问请求永远不会冲突. 问题二：分布式存储是什么？选择什么样的分布式存储更好？ 分布式存储系统，是将数据分散存储在多 *** 立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。 联想超融合ThinkCloud AIO超融合云一体机是联想针对企业级用户推出的核心产品。ThinkCloud AIO超融合云一体机实现了对云管理平台、计算、网络和存储系统的无缝集成，构建了云计算基础设施即服务的一站式解决方案，为用户提供了一个高度简化的一站式基础设施云平台。这不仅使得业务部署上线从周缩短到天，而且与企业应用软件、中间件及数据库软件完全解耦，能够有效提升企业IT基础设施运维管理的效率和关键应用的性能 问题三：什么是分布式存储系统？ 就是将数据分散存储在多 *** 立的设备上 问题四：什么是分布式数据存储 定义： 分布式数据库是指利用高速计算机网络将物理上分散的多个数据存储单元连接起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获取更大的存储容量和更高的并发访问量。近年来，随着数据量的高速增长，分布式数据库技术也得到了快速的发展，传统的关系型数据库开始从集中式模型向分布式架构发展，基于关系型的分布式数据库在保留了传统数据库的数据模型和基本特征下，从集中式存储走向分布式存储，从集中式计算走向分布式计算。 特点： 1.高可扩展性：分布式数据库必须具有高可扩展性，能够动态地增添存储节点以实现存储容量的线性扩展。 2 高并发性：分布式数据库必须及时响应大规模用户的读/写请求，能对海量数据进行随机读/写。 3. 高可用性：分布式数据库必须提供容错机制，能够实现对数据的冗余备份，保证数据和服务的高度可靠性。 问题五：分布式文件系统有哪些主要的类别？ 分布式存储在大数据、云计算、虚拟化场景都有勇武之地，在大部分场景还至关重要。 下面简要介绍*nix平台下分布式文件系统的发展历史： 1、单机文件系统 用于操作系统和应用程序的本地存储。 2、网络文件系统（简称：NAS） 基于现有以太网架构，实现不同服务器之间传统文件系统数据共享。 3、集群文件系统 在共享存储基础上，通过集群锁，实现不同服务器能够共用一个传统文件系统。 4、分布式文件系统 在传统文件系统上，通过额外模块实现数据跨服务器分布，并且自身集成raid保护功能，可以保证多台服务器同时访问、修改同一个文件系统。性能优越，扩展性很好，成本低廉。 问题六：分布式文件系统和分布式数据库有什么不同 分布式文件系统（dfs）和分布式数据库都支持存入，取出和删除。但是分布式文件系统比较暴力，可以当做key/value的存取。分布式数据库涉及精炼的数据，传统的分布式关系型数据库会定义数据元组的schema，存入取出删除的粒度较小。 分布式文件系统现在比较出名的有GFS（未开源），HDFS（Hadoop distributed file system）。分布式数据库现在出名的有Hbase，oceanbase。其中Hbase是基于HDFS，而oceanbase是自己内部实现的分布式文件系统，在此也可以说分布式数据库以分布式文件系统做基础存储。 问题七：分布式存储有哪些 华为的fusionstorage属于分布式 您好，很高兴能帮助您，首先，FusionDrive其实是一块1TB或3TB机械硬盘跟一块128GB三星830固态硬盘的组合。我们都知道，很多超极本同样采用了混合型硬盘，但是固态硬盘部分的容量大都只有8GB到32GB之间，这个区间无法作为系统盘来使用，只能作 问题八：linux下常用的分布式文件系统有哪些 这他妈不是腾讯今年的笔试题么 NFS（tldp/HOWTO/NFS-HOWTO/index） 网络文件系统是FreeBSD支持的文件系统中的一种，也被称为NFS。 NFS允许一个系统在网络上与它人共享目录和文件。通过使用NFS， 用户和程序可以象访问本地文件一样访问远端系统上的文件。它的好处是： 1、本地工作站使用更少的磁盘空间，因为通常的数据可以存放在一台机器上而且可以通过网络访问到。 2、用户不必在每个网络上机器里面都有一个home目录。home目录可以被放在NFS服务器上并且在网络上处处可用。 3、诸如软驱、CDROM、和ZIP之类的存储设备可以在网络上面被别的机器使用。可以减少整个网络上的可移动介质设备的数量。 开发语言c/c++,可跨平台运行。 OpenAFS（openafs） OpenAFS是一套开放源代码的分布式文件系统，允许系统之间通过局域网和广域网来分享档案和资源。OpenAFS是围绕一组叫做cell的文件服务器组织的，每个服务器的标识通常是隐藏在文件系统中，从AFS客户机登陆的用户将分辨不出他们在那个服务器上运行，因为从用户的角度上看，他们想在有识别的Unix文件系统语义的单个系统上运行。 文件系统内容通常都是跨cell复制，一便一个硬盘的失效不会损害OpenAFS客户机上的运行。OpenAFS需要高达1GB的大容量客户机缓存，以允许访问经常使用的文件。它是一个十分安全的基于kerbero的系统，它使用访问控制列表(ACL）以便可以进行细粒度的访问，这不是基于通常的Linux和Unix安全模型。开发协议IBM Public，运行在linux下。 MooseFs（） Moose File System是一个具备容错功能的网路分布式文件统，它将数据分布在网络中的不同服务器上，MooseFs通过FUSE使之看起来就 是一个Unix的文件系统。但有一点问题，它还是不能解决单点故障的问题。开发语言perl,可跨平台操作。 pNFS（pnfs） 网络文件系统(Network FileSystem,NFS)是大多数局域网(LAN）的重要的组成部分。但NFS不适用于高性能计算中苛刻的输入书橱密集型程序，至少以前是这样。NFS标准的罪行修改纳入了Parallel NFS(pNFS），它是文件共享的并行实现，将传输速率提高了几个数量级。 开发语言c/c++,运行在linu下。 googleFs 据说是一个比较不错的一个可扩展分布式文件系统，用于大型的，分布式的，对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能，它可以给大量的用户提供性能较高的服务。google自己开发的。 问题九：分布式存储都有哪些，并阐述其基本实现原理 神州云科 DCN NCS DFS2000（简称DFS2000）系列是面向大数据的存储系统，采用分布式架构，真正的分布式、全对称群集体系结构，将模块化存储节点与数据和存储管理软件相结合，跨节点的客户端连接负载均衡，自动平衡容量和性能，优化集群资源，3-144节点无缝扩展，容量、性能岁节点增加而线性增长，在 60 秒钟内添加一个节点以扩展性能和容量。 问题十：linux 分布式系统都有哪些？ 常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。各自适用于不同的领域。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。 GFS（Google File System） -------------------------------------- Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。 下面分布式文件系统都是类 GFS的产品。 HDFS -------------------------------------- Hadoop 实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。 Hadoop是Apache Lucene创始人Doug Cutting开发的使用广泛的文本搜索库。它起源于Apache Nutch，后者是一个开源的网络搜索引擎，本身也是Luene项目的一部分。Aapche Hadoop架构是MapReduce算法的一种开源应用，是Google开创其帝国的重要基石。 Ceph --------------------------------------- 是加州大学圣克鲁兹分校的Sage weil攻读博士时开发的分布式文件系统。并使用Ceph完成了他的论文。 说 ceph 性能最高，C++编写的代码，支持Fuse，并且没有单点故障依赖， 于是下载安装， 由于 ceph 使用 btrfs 文件系统， 而btrfs 文件系统需要 Linux 以上的内核才支持。 可是ceph太不成熟了，它基于的btrfs本身就不成熟，它的官方网站上也明确指出不要把ceph用在生产环境中。 Lustre --------------------------------------- Lustre是一个大规模的、安全可靠的，具备高可用性的集群文件系统，它是由SUN公司开发和维护的。 该项目主要的目的就是开发下一代的集群文件系统，可以支持超过10000个节点，数以PB的数据量存储系统。 目前Lustre已经运用在一些领域，例如HP SFS产品等。