FastDFS架构和设计理念解读

Posted 2021-08-30 Huazie

FastDFS架构和设计理念解读

本篇文章转载于FastDFS作者 余庆 大佬的 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 Node 或Data Node。Storage server 直接利用OS的文件系统存储文件。FastDFS不会对文件进行分块存储，客户端上传的文件 和 Storage server上的文件一一对应（V3 引入的小文件合并存储除外）。

众所周知，大多数网站都需要存储用户上传的文件，如图片、视频、电子文档等。出于降低带宽和存储成本的考虑，网站通常都会限制用户上传的文件大小，例如图片文件不能超过 5MB、视频文件不能超过 100MB 等。我认为，对于互联网应用，文件分块存储没有多大的必要。它既没有带来多大的好处，又增加了系统的复杂性。FastDFS 不对文件进行分块存储，与支持文件分块存储的 DFS 相比，更加简洁高效，并且完全能满足绝大多数互联网应用的实际需要。

在 FastDFS 中，客户端上传文件时，文件ID 不是由客户端指定，而是由 Storage server 生成后返回给客户端的。文件ID 中包含了组名、文件相对路径和文件名，Storage server 可以根据 文件ID 直接定位到文件。因此 FastDFS 集群不需要存储文件索引信息，这是 FastDFS 比较轻量级的一个例证。而其他文件系统则需要存储文件索引信息，这样的角色通常称作 Name Server或 Meta Server。其中 mogileFS 采用 MySQL 数据库来存储文件索引以及系统相关的信息，其局限性显而易见，MySQL 将成为整个系统的瓶颈。

FastDFS 轻量级的另外一个体现是代码量较小。最新的 V6.01 包括 C客户端API、FastDHT客户端API 和 PHP extension等，代码总行数不到 7.5 万行。

二、分组方式

类Google FS 都支持文件冗余备份，例如 Google FS、TFS 的备份数是 3。一个文件存储到哪几个存储结点，通常采用动态分配的方式。采用这种方式，一个文件存储到的结点是不确定的。举例说明，文件备份数是 3，集群中有 A、B、C、D 四个存储结点。文件1 可能存储在 A、B、C 三个结点，文件2 可能存储在B、C、D 三个结点，文件3 可能存储在 A、B、D 三个结点。

FastDFS 采用了分组存储方式。集群由一个或多个组构成，集群存储总容量为集群中所有组的存储容量之和。一个组由一台或多台存储服务器组成，同组内的多台Storage server 之间是类似 RAID1 的互备关系，同组存储服务器上的文件是完全一致的。文件上传、下载、删除等操作可以在组内任意一台 Storage server上进行。类似木桶短板效应，一个组的存储容量为该组内存储服务器容量最小的那个，由此可见组内存储服务器的软硬件配置最好一致。

采用分组存储方式的好处是灵活、可控性较强。比如上传文件时，可以由客户端直接指定上传到的组。一个分组的存储服务器访问压力较大时，可以在该组增加存储服务器来扩充服务能力（纵向扩容）。当系统容量不足时，可以增加组来扩充存储容量（横向扩容）。采用这样的分组存储方式，可以使用 FastDFS 对文件进行管理，使用主流的Web server 如 apache、nginx 等进行文件下载。

三、对等结构

FastDFS 集群中的 Tracker server 也可以有多台，Tracker server 和 Storage server 均不存在单点问题。Tracker server 之间采用 Leader-Follower 机制，基本是对等关系，组内的 Storage server 之间也是对等关系。传统的 Master-Slave 结构中的 Master 是单点，写操作仅针对 Master。如果 Master 失效，需要将 Slave 提升为 Master，实现逻辑会比较复杂。和 Master-Slave 结构相比，对等结构中所有结点的地位是相同的，每个结点都可以作为 Master，不存在单点问题。

看了上面的介绍，你是否认为 FastDFS 比较简洁高效呢？8年前一位原雅虎同事，他是一位相当资深的系统架构师，听完 FastDFS 介绍后，作出这样的评价：“FastDFS 是穷人的解决方案”。他的意思是说 FastDFS 把简洁和高效做到了极致，非常节约资源，中小网站完全用得起，这是对FastDFS的极大认可和褒奖。

再次贴下 FastDFS 架构图印证一下上述观点：

FastDFS 从 2008年7月 发布 V1.00 到现在的 V6.01，已推出 70 多个版本，后续完善和优化工作正在持续进行中。目前已有很多公司在生产环境中使用 FastDFS，相信通过我们的不懈努力，FastDFS 一定会越来越好！