目录
一、分布式文件系统
1.什么是分布式文件系统？
分布式文件系统（Distributed File System,DFS）定义为“网络连接的相互依赖的计算机之间共享信息”。DFS是分布在多个文件服务器或多个位置的文件系统，通过计算机网络进行通信或交换信息。它允许程序像访问本地文件一样访问或存储独立的文件，允许程序员从任何网络或计算机访问文件。通过DFS，可以以受控和授权的方式在网络上的用户之间轻松地共享信息和文件（转自分布式文件系统简介_YoungSimon的博客-CSDN博客_分布式文件系统）。
DFS的目的就是让使用者访问网络上的文件就像在访问本地计算机上的文件一样！
2.分布式文件系统的兴起
分布式文件系统本质上是一个分布式存储系统，相较于传统的集中式存储系统，分布式存储系统的兴起与互联网技术和业务发展密不可分。
2.1互联网行业的快速发展，传统的集中存储结构模式不适应业务的快速发展
互联网公司由于其数据量大而资本积累少，而通常都使用大规模分布式存储系统。与传统的高端服务器、高端存储器和高端处理器不同的是，互联网公司的分布式存储系统由数量众多的、低成本和高性价比的普通 PC 服务器通过网络连接而成。其主要原因有以下三点：
（1）互联网的业务发展很快，而且注意成本消耗，这就使得存储系统不能依靠传统的纵向扩展的方式，即先买小型机，不够时再买中型机，甚至大型机。互联网后端的分布式系统要求支持横向扩展，即通过增加普通 PC 服务器来提高系统的整体处理能力。
（2）普通 PC 服务器性价比高，故障率也高，需要在软件层面实现自动容错，保证数据的一致性。
（3）随着服务器的不断加入，需要能够在软件层面实现自动负载均衡，使得系统的处理能力得到线性扩展（转自一文看懂分布式存储架构_Java烟雨 的博客-CSDN博客_分布式存储）。
2.2分布式存储是云存储和大数据技术的基础
移动终端的计算能力和存储空间有限，而且有在多个设备之间共享资源的强烈的需求，这就使得网盘、相册等云存储应用很快流行起来。然而，万变不离其宗，云存储的核心还是后端的大规模分布式存储系统。大数据则更近一步，不仅需要存储海量数据，还需要通过合适的计算框架或者工具对这些数据进行分析，抽取其中有价值的部分（转自一文看懂分布式存储架构_Java烟雨的博客-CSDN博客_分布式存储）。
3.常见的分布式文件系统
- GFS（Google File System）
Google公司为满足公司需求而开发的基于Linux的可扩展的分布式文件系统，用于大型的、分布式的、对大数据进行访问和应用，成本低，应用于廉价的普通硬件上，不开源。
- TFS（Taobao File System）
阿里巴巴为满足了淘宝对小文件存储的需求而开发的一个可扩展、高可用、高性能、面向互联网服务、开源的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。
- HDFS（Hadoop Distributed File System）
Hadoop分布式文件系统，适合运行在通用硬件上做分布式存储和计算，因为它具有高容错性和可扩展性的特点，可部署在廉价的机器上，适合大数据的处理，在离线批量处理大数据上有先天的优势。
- MooseFS
MooseFS 是来自波兰的开源且具备冗余容错功能的分布式 POSIX 文件系统，也是参照了 GFS 的架构，实现了绝大部分 POSIX 语义和 API，它支持通过FUSE方式将文件挂载操作，同时其提供的web管理界面非常方便查看当前的文件存储状态，对master服务器有单点依赖，用perl编写，用于中、大型文件应用，但性能相对较差。
- FastDFS
由淘宝的余庆先生所开发的一个开源分布式文件系统。它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。适合以文件为载体的在线服务，如相册网站、视频网站等等。FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS搭建一套高性能的文件服务器集群提供文件上传、下载等服务。
- MogileFS
MogileFS是一套高效开源的文件自动备份组件，由Six Apart开发，广泛应用在包LiveJournal等web2.0站点上。支持多节点冗余，可实现自动的文件复制。不需要RAID，应用层可以直接实现RAID，不共享任何东西，通过集群接口提供服务工作于应用层，没有特殊的组件要求。使用HTTP方式通信。国内所知道的使用 MogileFS 的公司有digg, 土豆, 豆瓣,1 号店, 大众点评,搜狗,安居客等等网站。
- GridFS
MongoDB是一种知名的NoSql数据库，GridFS是MongoDB的一个内置功能，它用于存储和恢复那些超过16M（BSON文件限制）的文件(如：图片、音频、视频等)，是文件存储的一种方式，但是它是存储在MonoDB的集合中。它可以直接利用已建立的复制或分片机制，所以对于文件存储来说故障恢复和扩展都容易，且GridFS不产生磁盘碎片。
- MinIO
MinIO 是一个基于Apache License v2.0开源协议的对象存储服务。它兼容亚马逊S3云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几kb到最大5T不等。它也是一个非常轻量的服务,可以很简单的和其他应用的结合。MinIO的特色在于简单、轻量级，对开发者友好，学习成本低，安装运维简单，开箱即用。
- SeaweedFS
SeaweedFS是基于go语言开发高度可扩展开源的分布式存储系统，能存储数十亿文件（最终受制于你的硬盘大小）、并且速度快，内存占用小。上手使用比fastDFS要简单很多，自带Rest API。对于中小型文件效率非常高，但是单卷最大容量被程序限制到30G，建议存储文件以100MB以内为主。
- Ceph
Ceph是Red Hat旗下一个成熟的分布式文件系统，而且还是一个有企业级功能的对象存储生态环境。该系统具备高性能、高可用性、高可扩展性、实时存储性等特点。虽然ceph很强大，但是学习成本高、安装运维复杂。Ceph用C++编写，存储容量可轻松达到PB级别。
- GlusterFS
GlusterFS 是由美国的 Gluster 公司开发的 POSIX 分布式文件系统（以 GPL 开源），它主要应用在集群系统中，具有高扩展性、高可用性、高性能、可横向扩展等特点，并且其没有元数据服务器的设计，让整个服务没有单点故障的隐患。该系统主要是为中大型文件设计的，存储容量可轻松达到PB。它存在扩容缩容影响服务器较多、遍历目录下文件耗时、小文件性能较差的缺点。
（转自常用的分布式文件系统 - 知乎）
二、FastDFS
FastDFS是一个开源的高性能分布式文件系统。它的可以解决海量非结构性数据的存储、同步和访问，以及高容量和负载平衡问题，为电商、视频、网盘和社交等网站提供可靠的文件存储服务。特别适合4kb-500mb大小的中小型文件的存储。
1.FastDFS架构
- Client:
服务的调用方。
- Tracker server:
Tracker server的主要作用是负载均衡和调度，而不负责文件索引和映射。Tracker server在内存中记录分组和Storage server的状态等信息，不记录文件索引信息，其占用的内存量也很少。Tracker server可以只有一个，也可以有多个组成Tracker cluster，这样的好处是可以提高对用户的响应能力和增加容灾性，此时各Tracker server相互对等，冗余备份，由应用端来轮流选择进行访问。
- Storage server:
Storage server完成文件管理的所有功能：存储、同步和提供存取接口，文件和metadata都存储在其上。Storage server类似于GFS中的Chunk server或TFS中的Data server，通常一个Storage server即一台机器，Storage server可以动态新增和删除。FastDFS的存储部分即Storage cluster，分为多个Volume，每个Volume中包括多个Storage server。同一Volume内的各Storage server之间是对等的，存储的内容相同，起冗余容错的作用。文件上传、下载、删除等操作可在Volume内任意一台 Storage server上进行。一个Volume的存储容量取决于该Volume内最小的Storage server的容量，因此Volume内各Storage server的软硬件配置最好是一致的。采用这种分Volume的存储方式的好处是灵活、可控性较强。比如上传文件时，可以由客户端直接指定上传到哪个Volume。当某个Volume的访问压力较大时，可以在该Volume内增加Storage server来扩充服务能力（纵向扩容）。当系统总容量不足时，可以增加Volume来扩充存储容量（横向扩容）。
Storage server直接利用OS的文件系统存储文件。FastDFS不会对文件进行分块存储，客户端上传的文件和Storage server上的文件一一对应。
关于Storage server的同步，不同Volume的Storage server之间不会相互通信，同Volume内的Storage server之间会相互连接进行文件同步。文件同步采用push方式，接受更新操作的文件称为源文件，其所在server称为源服务器，其它文件称为备份文件，其它server称为目标服务器。当文件更新操作发生时，源服务器向目标服务器发起同步，对所有备份文件进行更新。当有新Storage server加入本Volume时，由已有的一台 Storage server将其上的所有文件同步给该新增服务器。具体的同步实现在Storage server中由专门线程根据binlog进行，binlog记录了文件上传、删除等更新操作。为了最大程度地避免相互影响以及出于系统简洁性考虑，Storage server对同Volume内除自己以外的每台服务器都会启动一个线程来负责文件同步。
这种异步的同步方式带来了一致性问题，当源文件尚未来得及将所有备份文件同步更新时，访问这些备份文件将引发错误。文件的访问主要分为更新和下载两种情况：FastDFS规定更新操作只能对源文件进行，从而避免了同时对不同的备份文件进行更新导致的冲突；文件下载时，Tracker server记录了各Storage server中各文件的同步情况，会向Client提供同步后的文件所在的Storage server（转自分布式文件系统FastDFS看这一篇就够了(文件上传下载、单机部署及集群部署)_白大锅的博客-CSDN博客_fastdfs）。
2. 上传和下载流程
2.1上传文件
1）Storage server会定时的向Tracker发送心跳，表示服务正常运行
2）客户端发送上传请求给Tracker server，Tracker server会检查是否有可用Storage server
3）如果有可用的，客户端就可以接收到可用Storage server的ip和端口号，并上传文件数据（file content）和元数据（matadata）到这个Storage server上
4）Storage server生成file_id，将数据持久化并会返回路径信息给客户端
客户端存储file_id，并通过该路径信息找到上传的文件
2.2下载文件
1）Storage server会定时的向Tracker发送心跳，表示服务正常运行
2）客户端发送上传请求给Tracker server，Tracker server会检查是否有可用Storage server
3）如果有可用的，客户端就可以接收到可用Storage server的ip和端口号，并拿着file_id到这个Storage server上去找对应的文件
4）Storage server从磁盘读取对应文件，将文件内容并返回给客户端
文件索引（ file_id ）是客户端上传文件后Storage返回给客户端的一个字符串，是以后访问该文件的索引信息 文件索引（ file_id ）信息包括：组名、虚拟磁盘路径、数据两级目录、文件名等信息。
- 组名：文件上传后所在的 Storage 组名称。
- 虚拟磁盘路径：Storage 配置的虚拟路径，与磁盘选项store_path*对应。如果配置了store_path0则是M00，如果配置了store_path1则是M01，以此类推。
- 数据两级目录：Storage 服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件。
- 文件名：由存储服务器根据特定信息生成，文件名包含:源存储服务器IP地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。
970
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
