FastDFS 分布式文件系统详解

1.概述

分布式文件系统：Distributed file system, DFS，又叫做网络文件系统：Network File System。一种允许文件通过网络在多台主机上分享的文件系统，可让多机器上的多用户分享文件和存储空间。

FastDFS 是用 c 语言编写的一款开源的分布式文件系统，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合中小文件（建议范围：4KB < file_size < 500MB），对以文件为载体的在线服务，如相册网站、视频网站等。

FastDFS 特性：

• 文件不分块存储，上传的文件和 OS 文件系统中的文件一一对应
• 支持相同内容的文件只保存一份，节约磁盘空间
• 下载文件支持 HTTP 协议，可以使用内置 Web Server，也可以和其他 Web Server 配合使用
• 支持在线扩容
• 支持主从文件
• 存储服务器上可以保存文件属性（meta-data）V2.0 网络通信采用 libevent，支持大并发访问，整体性能更好

2.FastDFS 架构

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

追踪服务器 Tracker Server：

主要做调度工作，起到均衡的作用；负责管理所有的 storage server 和 group，每个 storage 在启动后会连接 Tracker，告知自己所属 group 等信息，并保持周期性心跳。tracker 根据 storage 的心跳信息，建立 group==>[storage serverlist]的映射表。

Tracker 需要管理的元信息很少，会全部存储在内存中；另外 tracker 上的元信息都是由 storage 汇报的信息生成的，本身不需要持久化任何数据，这样使得 tracker 非常容易扩展，直接增加 tracker 机器即可扩展为 tracker cluster 来服务，cluster 里每个 tracker 之间是完全对等的，所有的 tracker 都接受 stroage 的心跳信息，生成元数据信息来提供读写服务。

存储服务器 Storage Server：

主要提供容量和备份服务；以 group 为单位，每个 group 内可以有多台 storage server，数据互为备份。以 group 为单位组织存储能方便的进行应用隔离、负载均衡、副本数定制（group 内 storage server 数量即为该 group 的副本数），比如将不同应用数据存到不同的 group 就能隔离应用数据，同时还可根据应用的访问特性来将应用分配到不同的 group 来做负载均衡；缺点是 group 的容量受单机存储容量的限制，同时当 group 内有机器坏掉时，数据恢复只能依赖 group 内地其他机器，使得恢复时间会很长。

group 内每个 storage 的存储依赖于本地文件系统，storage 可配置多个数据存储目录，比如有 10 块磁盘，分别挂载在/data/disk1-/data/disk10，则可将这 10 个目录都配置为 storage 的数据存储目录。storage 接受到写文件请求时，会根据配置好的规则选择其中一个存储目录来存储文件。为了避免单个目录下的文件数太多，在 storage 第一次启动时，会在每个数据存储目录里创建 2 级子目录，每级 256 个，总共 65536 个文件，新写的文件会以 hash 的方式被路由到其中某个子目录下，然后将文件数据作为本地文件存储到该目录中。

FastDFS 的存储策略：

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

在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。

2.1 FastDFS 的上传过程：

FastDFS 向使用者提供基本文件访问接口，比如 upload、download、append、delete 等，以客户端库的方式提供给用户使用。

Storage Server 会定期的向 Tracker Server 发送自己的存储信息。当 Tracker Server Cluster 中的 Tracker Server 不止一个时，各个 Tracker 之间的关系是对等的，所以客户端上传时可以选择任意一个 Tracker。

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

内部机制如下：

选择 tracker server

当集群中不止一个 tracker server 时，由于 tracker 之间是完全对等的关系，客户端在 upload 文件时可以任意选择一个 trakcer。选择存储的 group 当 tracker 接收到 upload file 的请求时，会为该文件分配一个可以存储该文件的 group，支持如下选择 group 的规则：

• 1、Round robin，所有的 group 间轮询
• 2、Specified group，指定某一个确定的 group
• 3、Load balance，剩余存储空间多多 group 优先

选择 storage server

当选定 group 后，tracker 会在 group 内选择一个 storage server 给客户端，支持如下选择 storage 的规则：

• 1、Round robin，在 group 内的所有 storage 间轮询
• 2、First server ordered by ip，按 ip 排序
• 3、First server ordered by priority，按优先级排序（优先级在 storage 上配置）

选择 storage path

当分配好 storage server 后，客户端将向 storage 发送写文件请求，storage 将会为文件分配一个数据存储目录，支持如下规则：

• 1、Round robin，多个存储目录间轮询
• 2、剩余存储空间最多的优先

生成 Fileid

选定存储目录之后，storage 会为文件生一个 Fileid，由 storage server ip、文件创建时间、文件大小、文件 crc32 和一个随机数拼接而成，然后将这个二进制串进行 base64 编码，转换为可打印的字符串。

选择两级目录

当选定存储目录之后，storage 会为文件分配一个 fileid，每个存储目录下有两级 256*256 的子目录，storage 会按文件 fileid 进行两次 hash（猜测），路由到其中一个子目录，然后将文件以 fileid 为文件名存储到该子目录下。

生成文件名

当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名，文件名由 group、存储目录、两级子目录、fileid、文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成。

2.2 FastDFS 的文件同步：

当一个文件上传成功后，客户端马上发起对该文件下载请求（或删除请求）时，tracker 是如何选定一个适用的存储服务器呢？ 其实每个存储服务器都需要定时将自身的信息上报给 tracker，这些信息就包括了本地同步时间（即，同步到的最新文件的时间戳）。而 tracker 根据各个存储服务器的上报情况，就能够知道刚刚上传的文件，在该存储组中是否已完成了同步。同步信息上报如下图：

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

每个 storage 写文件后，同时会写一份 binlog，binlog 里不包含文件数据，只包含文件名等元信息，这份 binlog 用于后台同步，storage 会记录向 group 内其他 storage 同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有 server 的时钟保持同步。

storage 的同步进度会作为元数据的一部分汇报到 tracker 上，tracke 在选择读 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 生成一个同步时间戳。

2.3 FastDFS 的文件下载

客户端 uploadfile 成功后，会拿到一个 storage 生成的文件名，接下来客户端根据这个文件名即可访问到该文件。

跟 upload file 一样，在 downloadfile 时客户端可以选择任意 tracker server。tracker 发送 download 请求给某个 tracker，必须带上文件名信息，tracke 从文件名中解析出文件的 group、大小、创建时间等信息，然后为该请求选择一个 storage 用来服务读请求。

说到下载就不得不提文件索引（又称：FID）的精巧设计了。文件索引结构如下图，是客户端上传文件后存储服务器返回给客户端，用于以后访问该文件的索引信息。文件索引信息包括：组名，虚拟磁盘路径，数据两级目录，文件名。

• 组名：文件上传后所在的存储组名称，在文件上传成功后有存储服务器返回，需要客户端自行保存。
• 虚拟磁盘路径：存储服务器配置的虚拟路径，与磁盘选项 store_path*对应。
• 数据两级目录：存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件。
• 文件名：与文件上传时不同。是由存储服务器根据特定信息生成，文件名包含：源存储服务器 IP 地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。

快速定位文件

• 1、通过组名 tracker 能够很快的定位到客户端需要访问的存储服务器组，并将选择合适的存储服务器提供客户端访问；
• 2、存储服务器根据“文件存储虚拟磁盘路径”和“数据文件两级目录”可以很快定位到文件所在目录，并根据文件名找到客户端需要访问的文件。

文中图片均来源于网络

参考：

官方网站
配置文档
参考资料
架构之路搭建 FastDFS 分布式文件系统