分布式文件系统 FastDFS

FastDFS 是什么

FastDFS 是一款开源的轻量级分布式文件系统：

• 纯 C 实现，支持 Linux、FreeBSD 等 UNIX 系统

• 类 google FS，不是通用的文件系统，只能通过专有 API 访问，目前提供了 C、Java 和 PHP API

• 为互联网应用量身定做，解决大容量文件存储问题，追求高性能和高扩展性

• FastDFS 可以看做是基于文件的 key value pair 存储系统，称作分布式文件存储服务更为合适

FastDFS 提供的功能

upload：上传普通文件，包括主文件

upload_appender：上传 appender 文件，后续可以对其进行 append 操作

upload_slave：上传从文件

download：下载文件

delete：删除文件

append：在已有文件后追加内容

set_metadata：设置文件附加属性

get_metadata：获取文件附加属性

FastDFS 的特点

分组存储，灵活简洁

对等结构，不存在单点

文件 ID 由 FastDFS 生成，作为文件访问凭证。FastDFS 不需要传统的 name server

和流行的 web server 无缝衔接，FastDFS 已提供 apache 和 nginx 扩展模块

大、中、小文件均可以很好支持，支持海量小文件存储

支持相同文件内容只保存一份，节省存储空间

存储服务器上可以保存文件附加属性

支持多块磁盘，支持单盘数据恢复

FastDFS 架构

FastDFS 架构示意图

Tracker Server：跟踪服务器，主要做调度工作，在访问上起负载均衡的作用。在内存中记录集群中 group 和 storage server 的状态信息，是连接 Client 和 Storage server 的枢纽。 因为相关信息全部在内存中，Tracker server 的性能非常高，一个较大的集群（比如上百个 group）中有 3 台就足够了。

Storage Server：存储服务器，文件和文件属性（meta data）都保存到存储服务器上。

只有两个角色，tracker server 和 storage server，不需要存储文件索引信息

所有服务器都是对等的，不存在 Master-Slave 关系

存储服务器采用分组方式，同组内存储服务器上的文件完全相同（RAID 1）

不同组的 storage server 之间不会相互通信

由 storage server 主动向 tracker server 报告状态信息，tracker server 之间通常不会相互通信

FastDFS 上传文件流程图 FastDFS 上传文件流程图

1. client 询问 tracker 上传到的 storage；

2. tracker 返回一台可用的 storage；

3. client 直接和 storage 通信完成文件上传，storage 返回文件 ID。

FastDFS 下载文件流程图

1. client 询问 tracker 可以下载指定文件的 storage，参数为文件 ID（组名和文件名）；

2. tracker 返回一台可用的 storage；

3. client 直接和 storage 通信完成文件下载。

以 HTTP 方式下载文件

FastDFS 分组存储方式，为 HTTP 方式下载提供了便利

FastDFS 支持 HTTP 方式下载文件，不建议使用内置 web server，推荐使用外部 web server，如果 apache 或 nginx

因为需要解决文件同步延迟的问题，因此在 apache 和 nginx 上需要使用 FastDFS 扩展模块。尤其是 V3.x 引入小文件合并存储后，必须使用扩展模块来读取文件

下面仅介绍扩展模块方式：

• 使用扩展模块来解决文件同步延迟问题

• 在每台 storage server 上部署 web server，直接对外提供 HTTP 服务

• tracker server 上不需要部署 web server

• 如果请求文件在当前 storage 上不存在，通过文件 ID 反解出源 storage，直接请求源 storage

• 目前已提供 apache 和 nginx 扩展模块

• FastDFS 扩展模块不依赖于 FastDFS server，可以独立存在！

• 仅支持 HTTP HEAD 和 GET

• 支持 token 方式的防盗链（缺省是关闭的）

• ts：生成 token 的时间（unix 时间戳）

• token：32 位的 token 字符串（md5 签名）

• 支持指定保存的缺省文件名，URL 参数名为 filename

• 支持断点续传

FastDFS 扩展模块注意事项

• 配置文件/etc/fdfs/mod_fastdfs.conf

• url_have_group_name：URL 中是否包含了 group name。这个参数必须正确设置，否则文件不能被下载到

• response_mode：当文件在本地不存在时，采用何种方式返回文件内容。有如下两种方式：

• 跳转方式（redirect）

• 代理方式（proxy）

• nginx 下需要将 http.conf 中的参数 http. need_find_content_type 设置为 true

HTTP 下载文件 redirect 模式 HTTP 下载文件 redirect 模式

HTTP 下载文件 proxy 模式

FastDFS 如何做到无索引服务器？

• 上传文件时，文件 ID 由 storage server 生成并返回给 client

• 文件 ID 包含了组名和文件名，storage server 可以直接根据该文件名定位到文件

• 一个文件 ID 示例：

FastDFS 同步机制

• 采用 binlog 文件记录文件上传、删除等操作，根据 binlog 进行文件同步

• binlog 中只记录文件名，不记录文件内容

• 增量同步方式，记录已同步的位置到.mark 文件中

• 同组内的 storage server 之间是对等的，文件上传、删除等操作可以在任意一台 storage server 上进行

• 文件同步只在同组内的 storage server 之间进行，采用 push 方式，即源头服务器同步给目标服务器

FastDFS 如何解决同步延迟问题？

• storage 生成的文件名中，包含源头 storage IP 地址和文件创建时间戳

• 源头 storage 定时向 tracker 报告同步情况，包括向目标服务器同步到的文件时间戳

• tracker 收到 storage 的同步报告后，找出该组内每台 storage 被同步到的时间戳（取最小值），作为 storage 属性保存到内存中

下载文件选择 storage 的方法

client 询问 tracker 有哪些 storage 可以下载指定文件时，tracker 返回满足如下四个条件之一的 storage：

• (当前时间 -文件创建时间戳) > 同步延迟阀值（如一天）

• 文件创建时间戳 < Storage 被同步到的时间戳

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

• 该文件上传到的源头 storage

FastDFS 通信协议

二进制通信协议

协议包由两部分组成：header 和 body

header 共 10 字节，格式如下：

• 8 bytes body length

• 1 byte command

• 1 byte status

body 数据包格式由取决于具体的命令， body 可以为空