【FastDFS-V5.11】FastDFS分布式文件系统内部架构及其原理解析

系统管理员 2021-12-19 15:25 493阅读 0赞

> ### 前言 ###

在分布式微服务的架构中，我们都会遇到一个问题，那就是文件的存储，而这个文件还不能单独存储在某一台应用服务器上，如果存储在某一台单独的应用服务器上，在分布式环境下或者当前应用服务器需要横向扩展的时候，就会大大的增加其运行维护的复杂度，和维护成本，所以这里就需要文件的存储抽取出来，作为一个单独服务器-文件服务器，这样不论应用服务器如何的扩展，都不会影响，而且如果文件服务器压力打，还可以单独的优化。

关于文件服务器，市面上流行的有很多，例如：FastDFS、HDFS、Lustre、MogileFs、MooseFS、GlusterFS、TFS 等等，各有优点，在项目中具体使用那个文件服务器，就需要项目的Leader根据各项因素去衡量了，那本篇文件主要对FastDFS进行介绍，通过本篇文章学习，你将深入的认识FastDFS分布式文件系统，并了解其架构原理、以及基于FastDFS的上传/下载流程等内容。

> ### FastDFS分布式文件系统内部架构及其原理解析 ###

**1、关于FastDFS**

FastDFS 是用 C 语言编写的一款**轻量级的开源的分布式文件系统**，主要解决了在实际应用中一些大文件存储和高并发访问的问题。FastDFS 为互联网应用量身定制，适合中大型网站应用，其主要用作资源的存/取服务器（例如：图片、文档、音频、视频等等），且充分考虑了冗余备份（**高可用**）、负载均衡（**高并发量**）、线性扩容（**添加服务器或者磁盘**）等机制，并注重高可用、高性能等指标，使用 FastDFS 很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

FastDFS 由三个核心部分组成：客户端（Client）、跟踪服务器（Tracker Server）、存储服务器（Storage Server）

**版本演变：**

*  2008年4月项目启动，7月发布第一个版本V1.00，两年的时间内持续升级到V1.29；
 *  2010年8月推出V2.00。V2.x最新版本是V2.13；
 *  2011年6月推出V3.00。当前最新版本是V3.06。V3.x后续会一直进行维护和升级；
 *  V1和V2系列后续不再维护和升级；
 *  2014年9月退出V5.00。最近一次发布迭代版本是在2017年6月，主要对一些客户端进行优化；

**版本历史：**

*  V1.x：采用传统的一个请求一个线程服务的模式，系统资源消耗较大，支持的并发连接数在1K左右；
 *  V2.x：采用libevent异步IO模型，磁盘读写采用专门的线程，比V1.x的工作模型更加先进和高效。支持的并发连接数可以达到10K；
 *  V3.x：支持小文件合并存储，解决海量小文件的存储问题；
 *  V4.x: 
 *  V5.x:

**特点：**

1.  分组存储，灵活简洁，对等结构，不存在单点；
2.  文件ID由FastDFS生成，作为文件访问凭证。FastDFS不需要传统的name server和流行的web server无缝衔接，FastDFS已提供apache和nginx扩展模块的支持；
3.  大、中、小文件均可以很好支持，支持海量小文件存储（V3.x加入的）；
4.  支持多块磁盘，支持单盘数据恢复；
5.  支持相同文件内容只保存一份，节省存储空间；
6.  存储服务器上可以保存文件附加属性；
7.  下载文件支持多线程方式，且支持断点续传；

**2、FastDFS架构**

FastDFS 只有两个角色，即 **Tracker server** 和 **Storage server**。其服务器上所有文件的索引信息无需存储，所有服务器都是**对等**的，不存在 Master-Slave 关系，存储服务器采用**分组存储**的方式，同组内存储服务器上的文件完全相同（RAID 1），不同组的 storage server 之间是不会相互通信的，所有 storage server 主动向 tracker server 报告自身的状态信息，tracker server 之间通常不会相互通信。

客户端请求 Tracker server 进行文件上传、下载，通过 Tracker server 调度最终由 Storage server 来完成文件上传和下载。

**Tracker server：**作用是实现负载均衡和调度的，通过 Tracker server 在文件上传时可以根据一些策略找到相应的 Storage server 来提供文件上传服务。可以将 Tracker server 称为**追踪服务器**或**调度服务器**。

**Storage server：**作用是实现文件存储的，在客户端上传的文件最终都将存储在 Storage server 上，Storage server 没有实现自己的文件系统而是利用操作系统的文件系统来管理文件。可以将 Storage server 称为**存储服务器**。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hlbGxvX1dvcmxkX1FXUA_size_16_color_FFFFFF_t_70][]

**1）、Tracker Cluster**

FastDFS 集群中的 Tracker server 可以有多台，Tracker server 之间是相互平等关系同时提供服务，Tracker server 不存在单点故障。客户端请求 Tracker server 默认采用轮询方式，如果当前请求的tracker无法提供服务则切换到另一个tracker。

**2）、Storage Cluster**

Storage Cluster 采用了分组存储方式。Storage 集群由一个或多个组构成，集群存储总容量为集群中所有组的存储容量之和。一个组由一台或多台存储服务器组成，组内的Storage server之间是平等关系，不同组的Storage server之间不会相互通信，但是在同一组内的Storage server之间会相互连接进行文件同步的，从而保证同组内每个Storage Server 上的文件完全一致的。一个组的存储容量为该组内所有Storage Server 容量最小的那个基准，由此可见组内存储服务器的软硬件配置最好是一致的，否则会浪费不必要的资源。

**3）、关于Storage Cluster的分组存储**

FastDFS 之所以采用分组存储方式，其带来的好处是**灵活**、**可控性较强**。比如在上传文件时，可以由客户端直接指定上传到的组也可以由tracker进行调度选择。一个分组的存储服务器访问压力较大时，可以在该组增加存储服务器来扩充服务能力（纵向扩容）。当系统容量不足时，可以增加组来扩充存储容量（横向扩容）。

**4）、Storage Server 状态上传**

Storage server 会连接集群中所有的 Tracker server，并定时向 Tracker server 上传自己的状态信息，包括磁盘剩余空间、文件同步情况、文件上传下载次数等信息。

**5）、FastDFS同步机制**

FastDFS 采用了 binlog 文件记录文件上传、删除等操作，根据 binlog 进行文件同步，binlog 中只记录文件名，不会记录文件内容，通过增量同步的方式，记录已同步的位置到 “ .mark ” 文件中。

在同一个组内的 storage\_server 之间是对等的，文件上传、删除等操作可以在任意一台 storage\_server 上进行，文件的同步只在同组内的 storage\_server 之间进行，采用 push 的方式，即源头服务器同步给目标服务器。

**3、FastDFS 的文件上传流程**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hlbGxvX1dvcmxkX1FXUA_size_16_color_FFFFFF_t_70 1][]

Client 上传文件后Storage Server 会将 File\_ID 返回给客户端，此File\_ID主要用于在以后访问该文件时的唯一索引信息。文件索引信息包括：组名、虚拟磁盘路径、数据两级目录、文件名、文件对应的后缀。

![20190731145318582.png][]

*  **组名：**文件上传后所在的 storage 组名称，在文件上传成功后由 Storage Server 返回，客户端成功接收后自行保存。
 *  **虚拟磁盘路径：**storage 配置的虚拟路径，与磁盘选项 store\_path\* 对应。如果配置了store\_path0则是M00，如果配置了 store\_path1 则是M01，以此类推。
 *  **数据两级目录：**storage 服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件。
 *  **文件名：**与文件上传时不同。是由Storage Server根据特定信息生成的，文件名包含：源存储服务器IP地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。
 *  **后缀名：**上传时的文件后缀名，列如图片的有：JPG、PNG、JPEG等，文件的有：PDF、EXCEL、WORD等。

**4、FastDFS 的文件下载流程**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hlbGxvX1dvcmxkX1FXUA_size_16_color_FFFFFF_t_70 2][]

Tracker 根据请求的File\_ID 来快速定位访问的文件。

![20190731145318582.png][]

*  通过组名Tracker能够很快的定位到客户端需要访问的Storage Server 组是 group1，并选择合适的Storage Server来提供客户端服务。
 *  存储服务器根据 “文件存储虚拟磁盘路径” 和 “数据文件两级目录” 可以很快定位到文件所在目录，并根据文件名和后缀找到客户端需要访问的目标文件。

**如上文件下载流程图，关于如何选择 storag 的策略**

首先 client 会询问 tracker 有哪些 storage 可以下载指定文件时，tracker 会返回满足如下四个条件之一的 storage：

*  文件创建时间戳 < storage 被同步到的时间戳
 *  (当前时间 -文件创建时间戳) > 同步延迟阀值
 *  文件创建时间戳 == storage 被同步到的时间戳且(当前时间 -文件创建时间戳) > 文件同步最大时间
 *  该文件上传到的源头 storage

**一般缺省采用 HTTP 方式下载文件：**

FastDFS 分组存储方式，为 HTTP 方式下载提供了便利，FastDFS 支持 HTTP 方式下载文件，不建议使用内置 web server，推荐使用外部 web server，如果apache或nginx，因为需要解决文件同步延迟的问题，因此，在 apache 或者 nginx 上需要使用基于 FastDFS 扩展模块。尤其是在 V3.x 版本引入小文件合并存储后，必须使用扩展模块来读取文件的方式。

**5、其它补充说明**

**1）、FastDFS的扩展模块（可以使用Apache 或 Nginx，目前最佳实践为Nginx->fastdfs-nginx-module）**

**特性：**

1.  仅支持HTTP HEAD和GET
2.  支持指定保存的缺省文件名，URL参数名为filename
3.  支持断点续传
4.  支持token方式的防盗链（缺省是关闭的）->ts：生成token的时间（unix元年的时间戳）； token：32位的token字符串（md5签名）

**要点：**

1.  如果请求的文件在当前storage上不存在，通过文件ID反解析出源storage，直接请求源storage;
2.  在每台storage\_server上部署web server，直接对外提供HTTP服务;
3.  FastDFS扩展模块不依赖于FastDFS server，可以独立存在;
4.  tracker\_server上不需要部署web\_server;
5.  使用扩展模块来解决文件同步延迟问题;
6.  目前已提供apache和nginx扩展模块;

**2）、FastDFS的常用配置**

**配置最大并发连接数：**  
参数名：max\_connections  
缺省值：256  
说明：FastDFS 采用预先分配好 buffer 队列的做法，分配的内存大小为：max\_connections \* buff\_size，因此配置的连接数越大，消耗的内存越多。所以连接数不建议配置得过大，以避免无谓的内存开销。

**配置工作线程数：**  
参数名： work\_threads  
缺省值：4   
说明：为了避免CPU上下文切换的开销，以及不必要的资源消耗，不建议将本参数设置得过大。为了发挥出多个CPU的效能，系统中的线程数总和，应等于CPU总数。  
对于 tracker server，公式为：  
work\_threads + 1 = CPU数  
对于storage，公式为：  
work\_threads + 1 + (disk\_reader\_threads + disk\_writer\_threads) \* store\_path\_count = CPU数

**配置 storage\_server 目录数**：  
参数名：subdir\_count\_per\_path  
缺省值：256  
说明：FastDFS采用二级目录的做法，目录会在FastDFS初始化时自动创建。存储海量小文件，打开了trunk存储方式的情况下，建议将本参数适当改小，比如设置32，此时存放文件的目录数为 32 \* 32 = 1024。假如trunk文件大小采用缺省值64MB，磁盘空间为2TB，那么每个目  
录下存放的trunk文件数均值为：2TB / (1024 \* 64MB) = 32个

**配置 storage\_server 磁盘读写线程：**  
disk\_reader\_threads：单个磁盘读线程数  
disk\_writer\_threads：单个磁盘写线程数  
disk\_rw\_separated：磁盘读写是否分离  
如果磁盘读写混合，单个磁盘读写线程数为读线程数和写线程数之后  
对于单盘挂载方式，磁盘读写线程分别设置为1即可  
如果磁盘做了RAID，那么需要酌情加大读写线程数，这样才能最大程度地发挥磁盘性能

**配置 storage\_server 同步延迟相关：**  
sync\_binlog\_buff\_interval：将binlog buffer写入磁盘的时间间隔，取值大于0，缺省值为60s  
sync\_interval：同步完一个文件后，休眠的毫秒数，缺省值为0  
为了缩短文件同步时间，可以将上述3个参数适当调小即可

**3）、FastDFS 部署方案：**  
文件上传和删除等操作：使用FastDFS client API，目前提供了 C、PHP extension 和 Java 的 client API【[API连接][API]】  
文件下载采用 HTTP 方式：使用 nginx 或者 apache 扩展模块，不推荐使用 FastDFS 内置的 web server【[扩展模块连接][Link 1]】  
不要做RAID，通过直接挂载单盘的方式，每个硬盘作为一个 mount point

**4）、关于FastDFS常见的面试题**

FastDFS 是如何解决同步延迟问题的 ？

storage 生成的文件名中，包含源头 storage IP 地址和文件创建时间戳，源头 storage 会定时向 tracker 报告同步情况，包括向目标服务器同步到的文件时间戳，tracker 收到 storage 的同步报告后，找出该组内每台 storage 被同步到的时间戳（取最小值），作为 storage 属性保存到内存中。

FastDFS 是如何做到无索引服务器的 ？

上传文件时，其文件 ID 由 storage server 生成并返回给 client 端进行存储，文件 ID 包含了组名和文件名，storage server 可以直接根据该文件名定位到文件。  
一般一个标准的文件 ID 示例如下图：

![20190731145318582.png][]

文件名中包含的信息：  
采用Base64编码，包含的字段包括：源storage server IP地址、文件创建时间、文件大小、文件CRC32校验码及随机数。

合并存储文件ID格式：

*  在文件名后面，增加了16个字节的字符
 *  合并存储文件ID采用 Base64 编码，包含的字段包括：存放的 trunk file ID、文件偏移量及占用的空间大小。

--------------------

好了，关于 FastDFS分布式文件系统内部架构及原理解析 就写到这儿了，如果还有什么疑问或遇到什么问题欢迎扫码提问，也可以给我留言哦，我会一一详细的解答的。   
歇后语：“ 共同学习，共同进步 ”，也希望大家多多关注CSND的IT社区。

--------------------

<table> 
 <tbody> 
  <tr> 
   <td>作&nbsp; &nbsp; &nbsp; &nbsp;者：</td> 
   <td>华 &nbsp; &nbsp;仔</td> 
  </tr> 
  <tr> 
   <td>联系作者：</td> 
   <td>who.seek.me@java98k.vip</td> 
  </tr> 
  <tr> 
   <td>来&nbsp; &nbsp; &nbsp; &nbsp; 源：</td> 
   <td>CSDN (Chinese Software Developer Network)</td> 
  </tr> 
  <tr> 
   <td>原&nbsp; &nbsp; &nbsp; &nbsp; 文：</td> 
   <td><a href="https://blog.csdn.net/Hello_World_QWP/article/details/94336641" rel="nofollow">https://blog.csdn.net/Hello_World_QWP/article/details/94336641</a></td> 
  </tr> 
  <tr> 
   <td>版权声明：</td> 
   <td>本文为博主原创文章，请在转载时务必注明博文出处！</td> 
  </tr> 
 </tbody> 
</table>

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hlbGxvX1dvcmxkX1FXUA_size_16_color_FFFFFF_t_70]: /images/20211219/80427b27a39b46a4abff264dbbd41fb5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hlbGxvX1dvcmxkX1FXUA_size_16_color_FFFFFF_t_70 1]: /images/20211219/b9e02ec5d61e43e787c9aa241b6f6b37.png
[20190731145318582.png]: /images/20211219/2011ae4fe36446d582e522c0deec2c5f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hlbGxvX1dvcmxkX1FXUA_size_16_color_FFFFFF_t_70 2]: /images/20211219/68919f9fc4184ce09d3242c758c0956c.png
[API]: https://github.com/happyfish100/fastdfs-client-java
[Link 1]: https://github.com/happyfish100/fastdfs-nginx-module