分布式文件系统FastDFS架构剖析

文/余庆

FastDFS是一款类GoogleFS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等UNIX系统。它只能通过专有API对文件进行存取访问，不支持POSIX接口方式，不能mount使用。准确地讲，GoogleFS以及FastDFS、mogileFS、HDFS、TFS等类GoogleFS都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。

FastDFS的设计理念

FastDFS是为互联网应用量身定做的分布式文件系统，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标。和现有的类GoogleFS分布式文件系统相比，FastDFS的架构和设计理念有其独到之处，主要体现在轻量级、分组方式和对等结构三个方面。

轻量级

FastDFS只有两个角色：Trackerserver和Storageserver。Trackerserver作为中心结点，其主要作用是负载均衡和调度。Trackerserver在内存中记录分组和Storageserver的状态等信息，不记录文件索引信息，占用的内存量很少。另外，客户端（应用）和Storageserver访问Trackerserver时，Trackerserver扫描内存中的分组和Storageserver信息，然后给出应答。由此可以看出Trackerserver非常轻量化，不会成为系统瓶颈。

FastDFS中的Storageserver在其他文件系统中通常称作Trunkserver或Dataserver。Storageserver直接利用OS的文件系统存储文件。FastDFS不会对文件进行分块存储，客户端上传的文件和Storageserver上的文件一一对应。

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

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

FastDFS轻量级的另外一个体现是代码量较小。最新的V2.0包括了C客户端API、FastDHT客户端API和PHPextension等，代码行数不到5.2万行。

分组方式

类GoogleFS都支持文件冗余备份，例如GoogleFS、TFS的备份数是3。一个文件存储到哪几个存储结点，通常采用动态分配的方式。采用这种方式，一个文件存储到的结点是不确定的。举例说明，文件备份数是3，集群中有A、B、C、D四个存储结点。文件1可能存储在A、B、C三个结点，文件2可能存储在B、C、D三个结点，文件3可能存储在A、B、D三个结点。（与其他FS留作对比思考。同时水平扩展量巨大以后，怎么部分迁移到其他种类存储，数据以组为整体单位）

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

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

对等结构

FastDFS集群中的Trackerserver也可以有多台，Trackerserver和Storageserver均不存在单点问题。Trackerserver之间是对等关系，组内的Storageserver之间也是对等关系。传统的Master-Slave结构中的Master是单点，写操作仅针对Master。如果Master失效，需要将Slave提升为Master，实现逻辑会比较复杂。和Master-Slave结构相比，对等结构中所有结点的地位是相同的，每个结点都是Master（由Storageserver上升为Trackerserver内部动作），不存在单点问题。

FastDFS的架构

图1展示的是FastDFS的系统架构。

图1 FastDFS的系统架构

从图1可以看出，Trackerserver之间相互独立，不存在直接联系。

客户端和Storageserver主动连接Trackerserver。Storageserver主动向Trackerserver报告其状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。Storageserver会连接集群中所有的Trackerserver，向他们报告自己的状态。Storageserver启动一个单独的线程来完成对一台Trackerserver的连接和定时报告。需要说明的是，一个组包含的Storageserver不是通过配置文件设定的，而是通过Trackerserver获取到的。

不同组的Storageserver之间不会相互通信，同组内的Storageserver之间会相互连接进行文件同步。

Storageserver采用binlog文件记录文件上传、删除等更新操作。binlog中只记录文件名，不记录文件内容。

文件同步只在同组内的Storageserver之间进行，采用push方式，即源头服务器同步给目标服务器。只有源头数据才需要同步，备份数据并不需要再次同步，否则就构成环路了。有个例外，就是新增加一台Storageserver时，由已有的一台Storageserver将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。

Storageserver中由专门的线程根据binlog进行文件同步。为了最大程度地避免相互影响以及出于系统简洁性考虑，Storageserver对组内除自己以外的每台服务器都会启动一个线程来进行文件同步。

文件同步采用增量同步方式，系统记录已同步的位置（binlog文件偏移量）到标识文件中。标识文件名格式：{deststorageIP}_{port}.mark，例如：192.168.1.14_23000.mark。

文件上传和下载的交互过程

接下来我们一起看一下文件上传和下载的交互过程。文件上传和下载流程分别如图2、图3所示。文件上传流程的步骤如下：

图2 文件上传流程

图3 文件下载流程

1.Client询问Trackerserver上传到的Storageserver；

2.Trackerserver返回一台可用的Storageserver，返回的数据为该Storageserver的IP地址和端口；

3.Client直接和该Storageserver建立连接，进行文件上传，Storageserver返回新生成的文件ID，文件上传结束。

文件下载流程的步骤如下：

1.Client询问Trackerserver可以下载指定文件的Storageserver，参数为文件ID（包含组名和文件名）；

2.Trackerserver返回一台可用的Storageserver；

3.Client直接和该Storageserver建立连接，完成文件下载。

文件同步延迟问题的提出

客户端将一个文件上传到一台Storageserver后，文件上传工作就结束了。由该Storageserver根据binlog中的上传记录将这个文件同步到同组的其他Storageserver。这样的文件同步方式是异步方式，异步方式带来了文件同步延迟的问题。新上传文件后，在尚未被同步过去的Storageserver上访问该文件，会出现找不到文件的现象。FastDFS是如何解决文件同步延迟这个问题的呢？

文件的访问分为两种情况：文件更新和文件下载。文件更新包括设置文件附加属性和删除文件。文件的附加属性包括文件大小、图片宽度、图片高度等。FastDFS中，文件更新操作都会优先选择源Storageserver，也就是该文件被上传到的那台Storageserver。这样的做法不仅避免了文件同步延迟的问题，而且有效地避免了在多台Storageserver上更新同一文件可能引起的时序错乱的问题。

那么文件下载是如何解决文件同步延迟这个问题的呢？

要回答这个问题，需要先了解文件名中包含了什么样的信息。Storageserver生成的文件名中，包含了源Storageserver的IP地址和文件创建时间等字段。文件创建时间为UNIX时间戳，后面称为文件时间戳。从文件名或文件ID中，可以反解出这两个字段。

然后我们再来看一下，Trackerserver是如何准确地知道一个文件已被同步到一台Storageserver上的。前面已经讲过，文件同步采用主动推送的方式。另外，每台storageserver都会定时向trackerserver报告它向同组的其他storageserver同步到的文件时间戳。当trackerserver收到一台storageserver的文件同步报告后，它会依次找出该组内各个storageserver（后称作为S）被同步到的文件时间戳最小值，作为S的一个属性记录到内存中。

FastDFS对文件同步延迟问题的解决方案

下面我们来看一下FastDFS采取的解决方法。

一个最简单的解决办法，和文件更新一样，优先选择源Storageserver下载文件即可。这可以在Trackerserver的配置文件中设置，对应的参数名为download_server。

另外一种选择Storageserver的方法是轮流选择（round-robin）。当Client询问Trackerserver有哪些Storageserver可以下载指定文件时，Trackerserver返回满足如下四个条件之一的Storageserver：

• 该文件上传到的源Storageserver，文件直接上传到该服务器上的；
• 文件创建时间戳<Storageserver被同步到的文件时间戳，这意味着当前文件已经被同步过来了；
• 文件创建时间戳=Storageserver被同步到的文件时间戳，且（当前时间—文件创建时间戳）>一个文件同步完成需要的最大时间（如5分钟）；
• （当前时间—文件创建时间戳）>文件同步延迟阈值，比如我们把阈值设置为1天，表示文件同步在一天内肯定可以完成。

结束语

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

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

作者简介：

余庆，现在淘宝网Java中间件团队从事Java基础平台研发工作，有10年互联网开发和架构经历，曾担任新浪网开发工程师、雅虎中国架构师。开源分布式文件系统FastDFS和分布式哈希系统FastDHT的作者，对分布式数据存储架构有比较深入的研究。