轻量级分布式文件系统FastDFS(二)架构及原理

轻量级分布式文件系统FastDFS(二)架构及原理

公众号：第二范式
CSDN：第二范式

1.1 架构详解

storage server：存储服务器（又称存储节点或数据服务器），文件和文件属性（meta data）都保存到存储服务器上。Storage server直接利用OS的文件系统调用管理文件。

Storage server（后简称storage）以组（卷，group或volume）为单位组织，一个group内包含多台storage机器，数据互为备份，存储空间以group内容量最小的storage为准，所以建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。

以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的方式被路由到其中某个子目录下，然后将文件数据 直接作为一个本地文件存储到该目录中。

group ：组， 也可称为卷。 同组内服务器上的文件是完全相同的 ，同一组内的storage server之间是对等的， 文件上传、删除等操作可以在任意一台storage server上进行 。

meta data ：文件相关属性，键值对（ Key Value Pair） 方式，如：width: 1118。

tracker server：跟踪服务器，主要做调度工作，起负载均衡的作用。在内存中记录集群中所有存储组和存储服务器的状态信息，是客户端和数据服务器交互的枢纽。因为不记录文件索引信息，所以占用的 内存量很少。

Tracker是FastDFS的协调者，负责管理所有的storage server和group，每个storage在启动后会连接Tracker，告知自己所属的group等信息，并保持周期性的心跳，tracker根据storage的心跳信息，建立group==>[storage server list]的映射表。

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

client：客户端，作为业务请求的发起方，通过专有接口，使用TCP/IP协议与跟踪器服务器或存储节点 进行数据交互。FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete 等，以客户端库的方式提供给用户使用。

1.2 设计理念

轻量级

FastDFS 服务端只有两个角色： Tracker server 和 Storage server。

Tracker server 在内存中记录 分组 和 Storage server 的状态等信息，不记录文件索引信息，占用 的内存量很少。另外，客户端（应用）和 Storage server 访问 Tracker server 时， Tracker server 扫描内存中的分组和 Storage server 状态信息，然后给出应答。由此可以看出 Tracker server 非常轻量化，不会成为系统瓶颈。

FastDFS 中的 Storage server 直接利用 OS 的文件系统存储文件。 FastDFS 不会对文件进行分块存 储，客户端上传的文件和 Storage server 上的文件一一对应。对于互联网应用，文件分块存储没有多 大的必要。它既没有带来多大的好处，又增加了系统的复杂性。 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 万行。

分组存储

FastDFS 采用了分组存储方式。集群由一个或多个组构成，集群存储总容量为集群中所有组的存储容量之和。一个组由一台或多台存储服务器组成，同组内的多台 Storage server 之间是对等的互备关系。文件上传、下载、删除等操作可以在组内任意一台 Storage server 上进行。类似木桶短板效应，一个组的存储容量为该组内存储服务器容量最小的那个，由此可见组内存储服务器的软硬件配置最好是一致的。用分组存储方式的好处是灵活、可控性较强。比如上传文件时，可以由客户端直接指定上传到的组。一个分组的存储服务器访问压力较大时，可以在该组增加存储服务器来扩充服务能力（纵向扩容）。当系统容量不足时，可以增加组来扩充存储容量（横向扩容）。采用这样的分组存储方式，可以使用 FastDFS 对文件进行管理，使用主流的 Web server 如 Apache、nginx 等进行文件下载。

对等结构

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

1.3 FastDFS 功能原理

1.3.1 文件上传

文件上传流程

文件上传内部原理

1、选择tracker server和group

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

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

2、选择storage server

当选定group后，tracker会在group内选择一个storage server给客户端，使用store_server选择 storage的规则：

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

3、选择storage path

当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录 storage server可以有多个存放文件的存储路径（可以理解为多个磁盘），store_path支持如下规则：

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

4、生成文件名

选定存储目录之后，storage会为文件生一个文件名，由storage server ip、文件创建时间、文件大小、 文件crc32和一个随机数拼接而成，然后将这个二进制串进行base64编码，转换为可打印的字符串。 选 择两级目录 当选定存储目录之后，storage会为文件分配一个文件名，每个存储目录下有两级256*256 的子目录，storage会按文件fileid进行两次hash，路由到其中一个子目录，然后将文件以这个文件标示 为文件名存储到该子目录下。

5、返回文件id

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

group1/M00/00/00/wKjTiF7iGy6AMefcAACGZa9JdFo097.png
复制代码

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

1.3.2 文件下载

客户端带上文件名信息请求Tracker服务获取到存储服务器的ip地址和端口，然后客户端根据返回的IP地 址和端口号请求下载文件，存储服务器接收到请求后返回文件给客户端。

跟upload_file一样，在download_file时客户端可以选择任意tracker server。

客户端发送download请求给某个tracker，必须带上文件名信息，tracke从文件名中解析出文件的

group、大小、创建时间等信息，然后为该请求选择一个storage用来服务读请求。

选择哪个 storage server 作为下载服务器 使用download_server 规则如下:

• 0: 轮询方式，可以下载当前文件的任意一个 storage server进行轮询
• 1: 哪个为源storage server 就用哪个

由于group内的文件同步时在后台异步进行的，所以有可能出现在读到时候，文件还没有同步到某些

storage server ,为了尽量避免访问到这样的storage，会有相应的文件同步规则。

1.3.3 文件同步

文件同步原理

写文件时，客户端将文件写至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 ，B向C同步到时间戳为T2（T2 > T1)，tracker接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳（即所有T1以前写的数据都已经同步到C上了）。同理，根据上述规则，tracker会为A、B生成一个同步时间戳。

tracker选择group内可用的storage的规则

1. 该文件上传到的源头storage

- 源头storage只要存活着，肯定包含这个文件，源头的地址被编码在文件名中。

2. 文件创建时间戳==storage被同步到的时间戳 且(当前时间-文件创建时间戳) > 文件同步最大时间（如5分钟)

- 文件创建后，认为经过最大同步时间后，肯定已经同步到其他storage了。

3. 文件创建时间戳 < storage被同步到的时间戳

- 同步时间戳之前的文件确定已经同步了

4. (当前时间 - 文件创建时间戳) > 同步延迟阀值

- 经过同步延迟阈值时间，认为文件肯定已经同步了。

1.3.4 文件删除

删除处理流程与文件下载类似：

1. Client询问Tracker server可以删除指定文件的Storage server，参数为文件ID（包含组名和文件名）。

2. Tracker server返回一台可用的Storage server。

3. Client直接和该Storage server建立连接，完成文件删除。

文件删除API：delete_file

1.3.5 断点续传

提供appender file的支持，通过upload_appender_file接口完成，appender file允许在创建后，对该 文件进行append操作。实际上，appender file与普通文件的存储方式是相同的，不同的是， appender file不能被合并存储到trunk file。续传涉及到的文件大小MD5不会改变。续传流程与文件上 传类似，先定位到源storage，完成完整或部分上传，再通过binlog进行同group内server文件同步。

断点续传的API:upload_appender_file

1.3.6 文件HTTP访问支持

FastDFS的tracker和storage都内置了http协议的支持，客户端可以通过http协议来下载文件，tracker 在接收到请求时，通过http的redirect机制将请求重定向至文件所在的storage上。除了内置的http协议 外，FastDFS还提供了通过apache或nginx扩展模块下载文件的支持。