文件管理系统
<h3>fastdfs和ceph对比：</h3>
<p><strong>fastdfs文档：</strong>
官方网站：<a href="https://github.com/happyfish100/">https://github.com/happyfish100/</a>
配置文档：<a href="https://github.com/happyfish100/fastdfs/wiki/">https://github.com/happyfish100/fastdfs/wiki/</a>
参考资料：<a href="https://www.oschina.net/question/tag/fastdfs">https://www.oschina.net/question/tag/fastdfs</a>
<strong>ceph文档：</strong>
官网：<a href="https://ceph.com/">https://ceph.com/</a>
官方文档：<a href="http://docs.ceph.com/docs/master/">http://docs.ceph.com/docs/master/</a>#
<strong>fastdfs优缺点</strong>
优点
1）系统无需支持POSIX(可移植操作系统)，降低了系统的复杂度，处理效率更高
2）支持在线扩容机制，增强系统的可扩展性
3）实现了软RAID，增强系统的并发处理能力及数据容错恢复能力
4）支持主从文件，支持自定义扩展名
5）主备Tracker服务，增强系统的可用性
缺点
1）不支持断点续传，对大文件将是噩梦（FastDFS不适合大文件存储）
2）不支持POSIX通用接口访问，通用性较低
3）对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略
4）同步机制不支持文件正确性校验，降低了系统的可用性
5）通过API下载，存在单点的性能瓶颈
<strong>ceph优缺点</strong>
优点：
a.具备块存储的读写高速。
b.具备文件存储的共享等特性。
缺点：
1.Ceph确实有无限扩容的能力，但需要良好的初始规划，扩容过程也并不完美。中心化造就了扩容的上限是单台master结点的物理极限，造就了无限扩容的理论基础，但实际扩容时，服务质量会受严重制约。
2.ceph有些浪费硬件，成本核算时要考虑更多。
3.Ceph本身的去中心化设计牺牲了不少元数据，比如lastacesstime，这给未来数据治理带来了压力，也需要更强的团队来运维和二次开发。
<img src="https://www.showdoc.cc/server/api/common/visitfile/sign/19bba597623a0d384290f9f02eed32da?showdoc=.jpg" alt="" /></p>
<p>开源协议说明</p>
<p>GPL:不允许修改后和衍生的代码做为闭源的商业软件发布和销售，修改后该软件产品必须也采用GPL协议；
GPL V2：修改文本的整体就必须按照GPL流通，不仅该修改文本的源码必须向社 会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制;
GPL V3：要求用户公布修改的源代码，还要求公布相关硬件;
LGPL：更宽松的GPL</p>
<pre><code>一.TFS
TFS（Taobao File System）是由淘宝开发的一个分布式文件系统，其内部经过特殊的优化处理，适用于海量的小文件存储，目前已经对外开源；
TFS采用自有的文件系统格式存储，因此需要专用的API接口去访问，
1.特性
1）在TFS文件系统中，NameServer负责管理文件元数据，通过HA机制实现主备热切换，由于所有元数据都是在内存中，其处理效率非常高效，系统架构也非常简单，管理也很方便；
2）TFS的DataServer作为分部署数据存储节点，同时也具备负载均衡和冗余备份的功能，由于采用自有的文件系统，对小文件会采取合并策略，减少数据碎片，从而提升IO性能；
3）TFS将元数据信息（BlockID、FileID）直接映射至文件名中，这一设计大大降低了存储元数据的内存空间；
2.优点
1）针对小文件量身定做，随机IO性能比较高；
2）支持在线扩容机制，增强系统的可扩展性；
3）实现了软RAID，增强系统的并发处理能力及数据容错恢复能力；
4）支持主备热倒换，提升系统的可用性；
5）支持主从集群部署，其中从集群主要提供读/备功能；
3.缺点
1）TFS只对小文件做优化，不适合大文件的存储；
2）不支持POSIX通用接口访问，通用性较低；
3）不支持自定义目录结构，及文件权限控制；
4）通过API下载，存在单点的性能瓶颈；
5）官方文档少，学习成本高；
4.应用场景
1）多集群部署的应用
2）存储后基本不做改动
3）海量小型文件
根据目前官方提供的材料，对单个集群节点，存储节点在1000台以内可以良好工作，如存储节点扩大可能会出现NameServer的性能瓶颈，目前淘宝线上部署容量已达到1800TB规模（2009年数据）
</code></pre>
<pre><code>二. HDFS:
Hadoop分布式文件系统.
1.概念：
（1）保存多个副本，且提供容错机制，副本丢失或宕机自动恢复。默认存3份。
（2） 运行在廉价的机器上。
（3） 适合大数据的处理。HDFS默认会将文件分割成block，128M为1个block。然后将block按键值对存储在HDFS上，并将键值对的映射存到内存中(namenode)。如果小文件太多，那内存的负担会很重
2.架构：
HDFS按照Master和Slave的结构。分NameNode、SecondaryNameNode、DataNode这几个角色。
NameNode：是Master节点，是管理者。（1）、管理数据块映射；（2）、处理客户端的读写请求；（3）、配置副本策略；（4）、管理HDFS的名称空间；
SecondaryNameNode：分担namenode的工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。
3.应用场景：
1） HDFS不适合大量小文件的存储
2） HDFS适用于高吞吐量，而不适合低时间延迟的访问
3）流式读取的方式，不适合多用户写入一个文件
4）HDFS更加适合写入一次，读取多次的应用场景</code></pre>
<pre><code>三、Fastdfs
1.概念：
FastDFS是用c语言编写的一款开源的分布式文件系统。FastDFS充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。
官方网站：https://github.com/happyfish100/
配置文档：https://github.com/happyfish100/fastdfs/wiki/
参考资料：https://www.oschina.net/question/tag/fastdfs
2.架构：
FastDFS架构包括 Tracker server和Storage server。客户端请求Tracker server进行文件上传、下载，通过Trackerserver调度最终由Storage server完成文件上传和下载。
Trackerserver作用是负载均衡和调度，通过Trackerserver在文件上传时可以根据一些策略找到Storageserver提供文件上传服务。可以将tracker称为追踪服务器或调度服务器。
Storageserver作用是文件存储，客户端上传的文件最终存储在Storage服务器上，Storage server没有实现自己的文件系统而是利用操作系统 的文件系统来管理文件。可以将storage称为存储服务器。
在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10,提升并发IO的性能、简单负载均衡及数据的冗余备份；同时通过线性的添加新的逻辑存储组，从容实现存储容量的线性扩容。
文件下载上，除了支持通过API方式，目前还提供了apache和nginx的插件支持，同时也可以不使用对应的插件，直接以Web静态资源方式对外提供下载。
目前FastDFS(V4.x)代码量大概6w多行，内部的网络模型使用比较成熟的libevent三方库，具备高并发的处理能力。
3.特性
1）在上述介绍中Tracker服务器是整个系统的核心枢纽，其完成了访问调度（负载均衡），监控管理Storage服务器，由此可见Tracker的作用至关重要，也就增加了系统的单点故障，为此FastDFS支持多个备用的Tracker，虽然实际测试发现备用Tracker运行不是非常完美，但还是能保证系统可用。
2）在文件同步上，只有同组的Storage才做同步，由文件所在的源Storage服务器push至其它Storage服务器，目前同步是采用Binlog方式实现，由于目前底层对同步后的文件不做正确性校验，因此这种同步方式仅适用单个集群点的局部内部网络，如果在公网上使用，肯定会出现损坏文件的情况，需要自行添加文件校验机制。
3）支持主从文件，非常适合存在关联关系的图片，在存储方式上，FastDFS在主从文件ID上做取巧，完成了关联关系的存储。
4.优点
1）系统无需支持POSIX(可移植操作系统)，降低了系统的复杂度，处理效率更高
2）支持在线扩容机制，增强系统的可扩展性
3）实现了软RAID，增强系统的并发处理能力及数据容错恢复能力
4）支持主从文件，支持自定义扩展名
5）主备Tracker服务，增强系统的可用性
5.缺点
1）不支持断点续传，对大文件将是噩梦（FastDFS不适合大文件存储）
2）不支持POSIX通用接口访问，通用性较低
3）对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略
4）同步机制不支持文件正确性校验，降低了系统的可用性
5）通过API下载，存在单点的性能瓶颈
6.应用场景
1）单集群部署的应用
2）存储后基本不做改动
3）FastDFS适合的存储范围为4KB至500M之间，它更倾向于存储中小型文件，如图片网站、短视频网站、文档、app下载站等。
FastDFS的用户有支付宝、京东、赶集网、58同城、UC、51CTO和一些网盘公司，可以说目前用到FastDFS的公司特别多，因为移动互联网的兴起，一些短视频、电子书、小音频和一些app，都在十几兆或者一两百兆左右，使用FastDFS十分合适。
7.部署：
FastDFS是一个开源的，高性能的的分布式文件系统，他主要的功能包括：文件存储，同步和访问，设计基于高可用和负载均衡，FastDFS非常适用于基于文件服务的站点，例如图片分享和视频分享网站
FastDFS有两个角色：跟踪服务(tracker)和存储服务(storage)，跟踪服务控制，调度文件以负载均衡的方式访问；存储服务包括：文件存储，文件同步，提供文件访问接口，同时以key value的方式管理文件的元数据
跟踪和存储服务可以由1台或者多台服务器组成，同时可以动态的添加，删除跟踪和存储服务而不会对在线的服务产生影响，在集群中，tracker服务是对等的
存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，
一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。在卷中增加服务器时，同步已有的文件由系统自动完成，同
步完成后，系统自动将新增服务器切换到线上提供服务。当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的
卷，这样就扩大了存储系统的容量。
8.FastDFS上传/下载过程：
首 先客户端 client 发起对 FastDFS 的文件传输动作，是通过连接到某一台 Tracker Server
的指定端口来实现的，Tracker Server 根据目前已掌握的信息，来决定选择哪一台 Storage Server
，然后将这个Storage Server 的地址等信息返回给 client，然后 client 再通过这些信息连接到这台 Storage
Server，将要上传的文件传送到给 Storage Server上。
上传文件后会生成一个http的下载地址， 通过http的方式进行下载
9.相对于MogileFS，FastDFS具有如下特点和优势：
1. FastDFS完善程度较高，不需要二次开发即可直接使用；
2. FastDFS裁减了跟踪用的数据库，只有两个角色：tracker和storage。FastDFS的架构既简化了系统，同时也消除了性能瓶颈；
3. 在系统中增加任何角色的服务器都很容易：增加tracker服务器时，只需要修改storage和client的配置文件（增加一行tracker配置）；增加storage服务器时，通常不需要修改任何配置文件，系统会自动将该卷中已有文件复制到该服务器；
4. FastDFS比MogileFS更高效。表现在如下几个方面：
1）参见上面的第2点，FastDFS和MogileFS相比，没有文件索引数据库，FastDFS整体性能更高；
2）从采用的开发语言上看，FastDFS比MogileFS更底层、更高效。FastDFS用C语言编写，代码量不到2万行，没有依赖其他开源软件或程序包，安装和部署特别简洁；而MogileFS用perl编写；
3）FastDFS直接使用socket通信方式，相对于MogileFS的HTTP方式，效率更高。并且FastDFS使用sendfile传输文件，采用了内存零拷贝，系统开销更小，文件传输效率更高。
5. FastDFS有着详细的设计和使用文档，而MogileFS的文档相对比较缺乏。
6. FastDFS的日志记录非常详细，系统运行时发生的任何错误信息都会记录到日志文件中，当出现问题时方便管理员定位错误所在。
7. FastDFS还对文件附加属性（即meta data，如文件大小、图片宽度、高度等）进行存取，应用不需要使用数据库来存储这些信息。
8. FastDFS从V1.14开始支持相同文件内容只保存一份，这样可以节省存储空间，提高文件访问性能。</code></pre>
<pre><code>四、mooseFS
MooseFS是一个高可用的故障容错分布式文件系统，它支持通过FUSE方式将文件挂载操作，同时其提供的web管理界面非常方便查看当前的文件存储状态。
官网：https://moosefs.com/
文档：https://my.oschina.net/noryar/blog/3045311
https://moosefs.com/Content/Downloads/moosefs-3-0-users-manual.pdf
1.特性
1）MooseFS文件系统由四部分组成：Managing Server 、Data Server 、Metadata Backup Server 及Client
2）其中所有的元数据都是由Managing Server管理，为了提高整个系统的可用性，Metadata Backup Server记录文件元数据操作日志，用于数据的及时恢复
3）Data Server可以分布式部署，存储的数据是以块的方式分布至各存储节点的，因此提升了系统的整体性能，同时Data Server提供了冗余备份的能力，提升系统的可靠性
4）Client通过FUSE方式挂载，提供了类似POSIX的访问方式，从而降低了Client端的开发难度，增强系统的通用性
元数据服务器（master）:负责各个数据存储服务器的管理，文件读写调度，文件空间回收以及恢复
元数据日志服务器（metalogger）:负责备份master服务器的变化日志文件，以便于在master server出问题的时候接替其进行工作
数据存储服务器（chunkserver）:数据实际存储的地方，由多个物理服务器组成，负责连接管理服务器，听从管理服务器调度，提供存储空间，并为客户提供数据传输；多节点拷贝;在数据存储目录，看不见实际的数据
2.优点
1）部署安装非常简单，管理方便
2）支持在线扩容机制，增强系统的可扩展性
3）实现了软RAID，增强系统的 并发处理能力及数据容错恢复能力
4）数据恢复比较容易，增强系统的可用性
5）有回收站功能，方便业务定制
3.缺点
1）存在单点性能瓶颈及单点故障
2）MFS Master节点很消耗内存
3）对于小于64KB的文件，存储利用率较低
4.应用场景
1）单集群部署的应用
2）中、大型文件
</code></pre>
<pre><code>五、Ceph
1.简介：
Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。ceph 的统一体现在可以提供文件系统、块存储和对象存储，分布式体现在可以动态扩展。在国内一些公司的云环境中，通常会采用 ceph 作为openstack 的唯一后端存储来提高数据转发效率。
Ceph是一个可以按对象/块/文件方式存储的开源分布式文件系统，其设计之初，就将单点故障作为首先要解决的问题，因此该系统具备高可用性、高性能及可 扩展等特点。
Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。
官网：https://ceph.com/
官方文档：http://docs.ceph.com/docs/master/#
2.架构
支持三种接口：
Object：有原生的API，而且也兼容Swift和S3的API。
Block：支持精简配置、快照、克隆。
File：Posix接口，支持快照
3.特点：
(1)高性能：
a. 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
c. 能够支持上千个存储节点的规模，支持TB到PB级的数据。
(2)高可用性：
a. 副本数可以灵活控制。
b. 支持故障域分隔，数据强一致性。
c. 多种故障场景自动进行修复自愈。
d. 没有单点故障，自动管理。
(3)高可扩展性：
a. 去中心化。
b. 扩展灵活。
c. 随着节点增加而线性增长。
(4)特性丰富：
a. 支持三种存储接口：块存储、文件存储、对象存储。
b. 支持自定义接口，支持多种语言驱动。
4.Ceph核心组件：Monitor，OSD，MDS，Object，PG，RADOS，Libradio，CRUSH，RBD，RGW，CephFS
1）Monitors：一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据。监视器，维护集群状态的多种映射，同时提供认证和日志记录服务，包括有关monitor 节点端到端的信息，其中包括 Ceph 集群ID，监控主机名和IP以及端口。并且存储当前版本信息以及最新更改信息，通过 "ceph mon dump"查看 monitor map。
（2）MDS（Metadata Server）：Ceph 元数据，主要保存的是Ceph文件系统的元数据。注意：ceph的块存储和ceph对象存储都不需要MDS。
（3）OSD：即对象存储守护程序，也就是负责响应客户端请求返回具体数据的进程。但是它并非针对对象存储。是物理磁盘驱动器，将数据以对象的形式存储到集群中的每个节点的物理磁盘上。OSD负责存储数据、处理数据复制、恢复、回（Backfilling）、再平衡。完成存储数据的工作绝大多数是由 OSD daemon 进程实现。在构建 Ceph OSD的时候，建议采用SSD 磁盘以及xfs文件系统来格式化分区。此外OSD还对其它OSD进行心跳检测，检测结果汇报给Monitor。一个Ceph集群一般都有很多个OSD。
（4）Object：Ceph最底层的存储单元是Object对象，每个Object包含元数据和原始数据。
（5）PG：PG全称Placement Grouops，是一个逻辑的概念，一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。
（6）RADOS：Reliable Autonomic Distributed Object Store。RADOS是ceph存储集群的基础。在ceph中，所有数据都以对象的形式存储，并且无论什么数据类型，RADOS对象存储都将负责保存这些对象。RADOS层可以确保数据始终保持一致。是Ceph集群的精华，用户实现数据分配、Failover等集群操作。
（7）librados：librados库，为应用程度提供访问接口。同时也为块存储、对象存储、文件系统提供原生的接口。Librados是Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFS都是通过librados访问的，目前提供PHP、Ruby、Java、Python、C和C++支持。
（8）CRUSH：CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。
（6）RADOSGW：网关接口，提供对象存储服务。它使用librgw和librados来实现允许应用程序与Ceph对象存储建立连接。并且提供S3 和 Swift 兼容的RESTful API接口。
（7）RBD：是Ceph对外提供的块设备服务。它能够自动精简配置并可调整大小，而且将数据分散存储在多个OSD上。
（8）CephFS：是Ceph对外提供的文件系统服务，与POSIX兼容的文件系统，基于librados封装原生接口。
5.特性
1）Ceph底层存储是基于RADOS（可靠的、自动的分布式对象存储），它提供了LIBRADOS/RADOSGW/RBD/CEPH FS方式访问底层的存储系统
2）通过FUSE（用户空间文件系统，是Linux 中用于挂载某些网络空间，如SSH，到本地文件系统的模块），Ceph支持类似的POSIX访问方式；Ceph分布式系统中最关键的MDS节点是可以部署多台，无单点故障的问题，且处理性能大大提升
3）Ceph通过使用CRUSH算法动态完成文件inode number到object number的转换，从而避免再存储文件metadata信息，增强系统的灵活性
6.应用场景：
Ceph可以提供对象存储、块设备存储和文件系统服务，其对象存储可以对接网盘（owncloud）应用业务等；其块设备存储可以对接（IaaS），当前主流的IaaS运平台软件，如：OpenStack、CloudStack、Zstack、Eucalyptus等以及kvm等。
Ceph是一个高性能、可扩容的分布式存储系统，它提供三大功能：
对象存储（RADOSGW）：提供RESTful接口，也提供多种编程语言绑定。兼容S3、Swift；
块存储（RDB）：由RBD提供，可以直接作为磁盘挂载，内置了容灾机制；
文件系统（CephFS）：提供POSIX兼容的网络文件系统CephFS，专注于高性能、大容量存储；
5.什么是块存储/对象存储/文件系统存储？
（1）对象存储：
也就是通常意义的键值存储，其接口就是简单的GET、PUT、DEL 和其他扩展，代表主要有 Swift 、S3 以及 Gluster 等；
典型设备：内置大容量硬盘的分布式服务器(swift, s3)
多台服务器内置大容量硬盘，安装上对象存储管理软件，对外提供读写访问功能。
优点：
a.具备块存储的读写高速。
b.具备文件存储的共享等特性。
使用场景：(适合更新变动较少的数据)
图片存储。
视频存储。
（2）块存储：
这种接口通常以 QEMU Driver 或者 Kernel Module 的方式存在，这种接口需要实现 Linux 的 Block Device 的接口或者 QEMU 提供的 Block Driver 接口，如 Sheepdog，AWS 的 EBS，青云的云硬盘和阿里云的盘古系统，还有 Ceph 的 RBD（RBD是Ceph面向块存储的接口）。在常见的存储中 DAS、SAN 提供的也是块存储；
典型设备：磁盘阵列，硬盘
主要是将裸磁盘空间映射给主机使用的。
优点：
通过Raid与LVM等手段，对数据提供了保护。
多块廉价的硬盘组合起来，提高容量。
多块磁盘组合出来的逻辑盘，提升读写效率。
缺点：
采用SAN架构组网时，光纤交换机，造价成本高。
主机之间无法共享数据。
使用场景：
docker容器、虚拟机磁盘存储分配。
日志存储。
文件存储。
（3）文件系统存储：
通常意义是支持 POSIX 接口，它跟传统的文件系统如 Ext4 是一个类型的，但区别在于分布式存储提供了并行化的能力，如 Ceph 的 CephFS (CephFS是Ceph面向文件存储的接口)，但是有时候又会把 GlusterFS ，HDFS 这种非POSIX接口的类文件存储接口归入此类。当然 NFS、NAS也是属于文件系统存储；
典型设备：FTP、NFS服务器
为了克服块存储文件无法共享的问题，所以有了文件存储。
在服务器上架设FTP与NFS服务，就是文件存储。
优点：
造价低，随便一台机器就可以了。
方便文件共享。
缺点：
读写速率低。
传输速率慢。
使用场景：
日志存储。
有目录结构的文件存储。
概括一下，块设备速度快，对存储的数据没有进行组织管理，但在大多数场景下，用户数据读写不方便（以块设备位置offset + 数据的length来记录数据位置，读写数据）。而在块设备上构建了文件系统后，文件系统帮助块设备组织管理数据，数据存储对用户更加友好（以文件名来读写数据）。Ceph文件系统接口解决了“Ceph块设备+本地文件系统”不支持多客户端共享读写的问题，但由于文件系统结构的复杂性导致了存储性能较Ceph块设备差。对象存储接口是一种折中，保证一定的存储性能，同时支持多客户端共享读写。
7.Ceph的坑，参考http://storage.it168.com/a2018/0703/3212/000003212605.shtml
1、Ceph确实有无限扩容的能力，但需要良好的初始规划，扩容过程也并不完美。中心化造就了扩容的上限是单台master结点的物理极限，造就了无限扩容的理论基础，但实际扩容时，服务质量会受严重制约。
2、Ceph有些浪费硬件，成本核算时要考虑更多。
3、Ceph本身的去中心化设计牺牲了不少元数据，比如lastacesstime，这给未来数据治理带来了压力，也需要更强的团队来运维和二次开发。</code></pre>
<p>目前数据库存储：
视频最大 3g， 最小12kb, 平均大小为：67m,
500m有800个，总数为86473个视频
图片4359万，占用约41G</p>