2024年6月5日发(作者：)

FastDFS一个高效的分布式文件系统

FastDFS是一款类Google FS的开源分布式文件系统，它用纯C语言实现，支持Linux、

FreeBSD、AIX等UNIX系统。它只能通过专有API对文件进行存取访问，不支持POSIX

接口方式，不能mount使用。准确地讲，Google FS以及FastDFS、mogileFS、HDFS、

TFS等类Google FS都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。

FastDFS的设计理念

FastDFS是为互联网应用量身定做的分布式文件系统，充分考虑了冗余备份、负载均

衡、线性扩容等机制，并注重高可用、高性能等指标。和现有的类Google FS分布式文件

系统相比，FastDFS的架构和设计理念有其独到之处，主要体现在轻量级、分组方式和对

等结构三个方面。

轻量级

FastDFS只有两个角色：Tracker server和Storage server。Tracker server作为中

心结点，其主要作用是负载均衡和调度。Tracker server在内存中记录分组和

Storage server的状态等信息，不记录文件索引信息，占用的内存量很少。另外，客户端

（应用）和Storage server访问Tracker server时，Tracker server扫描内存中的分组和

Storage server信息，然后给出应答。由此可以看出Tracker server非常轻量化，不会成

为系统瓶颈。

FastDFS中的Storage server在其他文件系统中通常称作Trunk server或

Data server。Storage server直接利用OS的文件系统存储文件。FastDFS不会对文件进

行分块存储，客户端上传的文件和Storage server上的文件一一对应。

众所周知，大多数网站都需要存储用户上传的文件，如图片、视频、电子文档等。出

于降低带宽和存储成本的考虑，网站通常都会限制用户上传的文件大小，例如图片文件不

能超过5MB、视频文件不能超过100MB等。我认为，对于互联网应用，文件分块存储没

有多大的必要。它既没有带来多大的好处，又增加了系统的复杂性。FastDFS不对文件进

行分块存储，与支持文件分块存储的DFS相比，更加简洁高效，并且完全能满足绝大多数

互联网应用的实际需要。

在FastDFS中，客户端上传文件时，文件ID不是由客户端指定，而是由Storage server

生成后返回给客户端的。文件ID中包含了组名、文件相对路径和文件名，Storage server

可以根据文件ID直接定位到文件。因此FastDFS集群中根本不需要存储文件索引信息，

这是FastDFS比较轻量级的一个例证。而其他文件系统则需要存储文件索引信息，这样的

角色通常称作NameServer。其中mogileFS采用MySQL数据库来存储文件索引以及系

统相关的信息，其局限性显而易见，MySQL将成为整个系统的瓶颈。

FastDFS轻量级的另外一个体现是代码量较小。最新的V2.0包括了C客户端API、

FastDHT客户端API和PHP extension等，代码行数不到5.2万行。

分组方式

类Google FS都支持文件冗余备份，例如Google FS、TFS的备份数是3。一个文件

存储到哪几个存储结点，通常采用动态分配的方式。采用这种方式，一个文件存储到的结

点是不确定的。举例说明，文件备份数是3，集群中有A、B、C、D四个存储结点。文件

1可能存储在A、B、C三个结点，文件2可能存储在B、C、D三个结点，文件3可能存