1.什么是分布式文件系统2.FastDFS 与 HDFS比较3.什么是FastDFS4.常见术语5.FastDFS详细介绍

5.1 发展历史

5.2 FastDFS的使用用户

5.3 简介

5.4 特性

5.5 角色

5.6 存储策略

5.7 上传过程

5.8 文件同步

5.9 下载过程

1.什么是分布式文件系统

随着文件数据的越来越多，通过tomcat或nginx虚拟化的静态资源文件在单一的一个服务器节点内是存不下的，如果用多个节点来存储也可以，但是不利于管理和维护，所以我们需要一个系统来管理多台计算机节点上的文件数据，这就是分布式文件系统。

分布式文件系统是一个允许文件通过网络在多台节点上分享的文件系统，多台计算机节点共同组成一个整体，为更多的用户提供分享文件和存储空间。比如常见的网盘，本质就是一个分布式的文件存储系统。虽然我们是一个分布式的文件系统，但是对用户来说是透明的，用户使用的时候，就像是访问本地磁盘一样。

分布式文件系统可以提供冗余备份，所以容错能力很高。 系统中有某些节点宕机，但是整体文件服务不会停止，还是能够为用户提供服务，整体还是运作的，数据也不会丢失。分布式文件系统的可扩展性强，增加或减少节点都很简单，不会影响线上服务，增加完毕后会发布到线上，加入到集群中为用户提供服务。

分布式文件系统可以提供负载均衡能力，在读取文件副本的时候可以由多个节点共同提供服务，而且可以通过横向扩展来确保性能的提升与负载。

为什么要使用分布式文件系统

海量文件数据存储

文件数据高可用(冗余备份)

读写性能和负载均衡

以上3点都是我们之前使用tomcat或nginx所不能够实现的，这也是我们为什么要使用分布式文件系统的原因

2.FastDFS 与 HDFS比较

说到分布式文件存储，肯定会有人想到HDFS，他们两者主要定位和应用场景是不一样的。

Hadoop中的文件系统HDFS主要解决并行计算中分布式存储数据的问题。其单个数据文件通常很大，采用了分块（切分）存储的方式，所以是大数据大文件存储来使用的场景。

FastDFS主要用于互联网网站，为文件上传和下载提供在线服务。所以在负载均衡、动态扩容等方面都支持得比较好，FastDFS不会对文件进行分快存储。FastDFS用于存储中小文件都是不错的，比如用户头像啊，一些较小的音视频文件啊等等都行(4KB<filesize<500M)。

3.什么是FastDFS

FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。

特别适合以文件为载体的在线服务，如相册网站、视频网站等等。FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

FastDFS服务端有两个角色：跟踪器（tracker）和存储节点（storage）。跟踪器主要做调度工作，在访问上起负载均衡的作用。

存储节点存储文件，完成文件管理的所有功能：就是这样的存储、同步和提供存取接口，FastDFS同时对文件的metadata进行管理。所谓文件的meta data就是文件的相关属性，以键值对（key value）方式表示，如：width=1024，其中的key为width，value为1024。文件metadata是文件属性列表，可以包含多个键值对。

跟踪器和存储节点都可以由一台或多台服务器构成。跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。

为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。

在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。

当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。

FastDFS中的文件标识分为两个部分：卷名和文件名，二者缺一不可。

4.常见术语

tracker：追踪者服务器，主要用于协调调度，可以起到负载均衡的作用，记录storage的相关状态信息。

storage：存储服务器，用于保存文件以及文件的元数据信息。

group：组，同组节点提供冗余备份，不同组用于扩容。

mata data：文件的元数据信息，比如长宽信息，图片后缀，视频的帧数等。

5.FastDFS详细介绍

5.1 发展历史

2008年4月项目正式启动

2008年7月推出V1.00

2010年8月推出V2.00

2011年6月推出V3.00

2012年10月推出V4.00

2013年12月推出V5.00

2019年10月推出V6.00

FastDFS系统架构从第一个版本发布后一直没有大的调整，高版本完全兼容低版本的数据，可以做到平滑升级，推荐更新升级到最新版本。

5.2 FastDFS的使用用户

UC（）

支付宝（）

京东商城（）

淘淘搜（）

飞信（）

赶集网（）

淘米网（）

蚂蜂窝（）

华师京城教育云平台（）

视友网（）

搜道网（）

58同城（）

搜房网（）

5.3 简介

官网:

社区:

FastDFS 是一个开源的高性能分布式文件系统（DFS）。 它的主要功能包括：文件存储，文件同步和文

件访问，以及高容量和负载平衡。主要解决了海量数据存储问题，特别适合以中小文件（建议范围：

4KB < file_size <500MB）为载体的在线服务。

FastDFS设计是用来存储小文件的，过大的文件处理方案是拆分为小文件，可跟踪小文件的上传情况。

如果应用场景都是处理大文件，可能选择其他分布式文件系统方案会更合适。

具体应用场景:互联网海量非结构化数据的存储需求

电商网站：海量商品图片

视频网站：海量视频文件

网盘 : 海量文件

社交网站：海量图片

5.4 特性

FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性

能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

优点：

文件不分块存储，文件和系统中的文件一一对应。

对文件内容做hash处理，避免出现重复文件，节约磁盘空间。

比如: M001/XXX/XX/随机数.后缀名

下载文件支持HTTP协议，可基于内置Web Server或外部Web Server。

比如: fastDFS整合nginx,实现的目的:通过浏览器访问上传的文件或者下载文件

支持在线扩容，动态添加卷。

比如: 动态创建storage(创建一个硬盘)

支持文件冗余备份和负载均衡。

存储服务器上可以保存文件属性（meta-data）

V2.0 网络通信采用libevent，支持大并发访问，整体性能更好。

缺点：

直接按文件存储，可直接查看文件内容，缺乏文件安全性。

数据同步无校验，存在静默IO问题，降低系统可用性。

单线程数据同步，仅适合存储小文件（1）。

备份数根据存储分卷（分组）决定，缺乏文件备份数设置灵活性。

单个挂载点异常会导致整个存储节点下线。

缺乏多机房容灾支持。

静态的负载均衡机制。

优点与缺点并存，但针对中小型系统已经完全足够使用了。

5.5 角色

Tracker Server：跟踪服务器，主要做调度工作，起到均衡的作用；负责管理所有的 storage

server和 group，每个 storage 在启动后会连接 Tracker，告知自己所属 group 等信息，并保持周

期性心跳。

**Storage Server：**存储服务器，主要提供容量和备份服务；以 group 为单位，每个 group 内可以

有多台 storage server，数据互为备份。

**Client：**客户端，上传下载数据的服务器，也就是我们自己的项目所部署在的服务器

Tracker相当于一个调度中心，上传和下载都通过它来进行分配指定。Storage cluster部分，由Volume1、Volume2……VolumeK组成，它们称为卷（或者叫做组），卷与卷之间是平行的关系，可以根据资源的使用情况随时增加，卷内服务器文件相互同步备份，以达到容灾的目的。

5.6 存储策略

为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立

的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量

5.7 上传过程

当服务启动之后，Storage Server会定期的向Tracker Server发送存储信息。如果Tracker Server是集群形式，则每个Tracker之间的关系是对等的，客户端上传时选择任意一个Tracker即可。

整体流程：当客户端请求Tracker进行上传操作时，会获取存储服务器相关信息，主要包括IP和端口。根据返回信息上传文件，通过存储服务器写入磁盘，并返回给客户端file_id、路径信息、文件名等信息。

对应流程图如下：

其中，当Tracker收到客户端上传文件的请求时，会为该文件分配一个可以存储文件的group，当选定了group后就要决定给客户端分配group中的哪一个storage server。当分配好storage server后，客户端向storage发送写文件请求，storage将会为文件分配一个数据存储

目录。然后为文件分配一个fileID，最后根据以上的信息生成文件名存储文件。

生成的文件名基本格式如下：

组名:文件上传后所在的 storage 组名称，在文件上传成功后有 storage 服务器返回， 需要客户

端自行保存。

虚拟磁盘路径: storage 配置的虚拟路径，与磁盘选项 store_path* 对应。如果配置了

store_path0 则是 M00 ，如果配置了 store_path1 则是 M01 ，以此类推。

数据两级目录: storage 服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据 文件。

文件名:与文件上传时不同。是由存储服务器根据特定信息生成，文件名包含:源存储 服务器 IP 地

址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。

5.8 文件同步

写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage server写完文件后，会由后台线程将文件同步至同

group内其他的storage server。每个storage写文件后，同时会写一份binlog日志，binlog里不包含文件数据，只包含文件名等元信息，

这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方

式进行记录，所以最好能保证集群内所有server的时钟保持同步。storage的同步进度会作为元数据的一部分汇报到tracker上，tracker在

选择读storage的时候会以同步进度作为参考。

比如一个group内有A、B、C三个storage server，A向C同步到进度为T1 (T1以前写的文件都已经同步到B上了），B向C同步到时间戳为

T2（T2 > T1)，tracker接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳为

T1（即所有T1以前写的数据都已经同步到C上了）；同理，根据上述规则，tracker会为A、B生成一个同步时间戳。

其他特性

FastDFS提供了设置/获取文件扩展属性的接口（setmeta/getmeta)，扩展属性以key-value对的方式存储在storage上的同名文件（拥

有特殊的前缀或后缀），比如/group/M00/00/01/some_file为原始文件，则该文件的扩展属性存在/group/M00/00/01/.some_file.meta

文件（真实情况不一定是这样，但机制类似），这样根据文件名就能定位到存储扩展属性的文件。

​ 以上两个接口作者不建议使用，额外的meta文件会进一步“放大”海量小文件存储问题，同时由于meta非常小，其存储空间利用率也不高，比如100bytes的meta文件也需要占用4K（block_size）的存储空间。

​ FastDFS还提供appender file的支持，通过upload_appender_file接口存储，appender file允许在创建后，对该文件进行append操作。实际上，appender file与普通文件的存储方式是相同的，不同的是，appender file不能被合并存储到trunk file。

5.9 下载过程

跟上传一样，在下载时客户端可以选择任意Tracker server。

客户端带文件名信息请求Tracker，Tracker从文件名中解析出文件的group、大小、创建时间等信息，

然后选择一个storage用来服务处理请求，返回对应文件。

对应流程图如下：

如果是基于Web的http请求，此处的Client可以是Nginx代理服务。下面这张图更加形象的描述了相关的

流程。

HTTP访问支持

FastDFS的tracker和storage都内置了http协议的支持，客户端可以通过http协议来下载文件，tracker在接收到请求时，通过http的redirect机制将请求重定向至文件所在的storage上；除了内置的http协议外，FastDFS还提供了通过apache或nginx扩展模块下载文件的支持