FastDFS 海量小文件存储解决之道

FastDFS是一个C语言实现的开源轻量级分布式文件系统 。

支持 Linux、FreeBSD、AID 等Unix系统，解决了大容量的文件存储和高并发访问问题，文件存取实现了负载均衡，适合存储 4KB~500MB 之间的小文件，特别适合以文件为载体的在线服务，如图片、视频、文档等等。

FastDFS 由三个部分构成：

2.1 Tracker Server (跟踪服务器)

Tracker Server (跟踪服务器) 主要是做调度工作，起到负载均衡的作用。

（1）【服务注册】管理StorageServer存储集群，StorageServer启动时，会把自己注册到TrackerServer上，并且定期报告自身状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。

（2）【服务发现】Client访问StorageServer之前，必须先访问TrackerServer，动态获取到StorageServer的连接信息，最终数据是和一个可用的StorageServer进行传输。

（3）【负载均衡】

2.2 Storage Server (存储服务器)

Tracker Server (跟踪服务器) 主要提供容量和备份服务。

【分组管理】以Group为单位，每个Group包含多台Storage Server，数据互为备份，存储容量以Group内容量最小的 storage 为准，已 Group 为单位组织存储方便应用隔离、负载均衡和副本数据定制。

缺点：Group容量受单机存储容量的限制，数据恢复只能依赖Group其他机器重新同步。

【数据同步】文件同步只能在 Group 内的Storage Server之间进行，采用push方式，即源服务器同步给目标服务器。源服务器读取 binlog 文件，将文件内容解析后，按操作命令发送给目标服务器，有目标服务按命令进行操作。

3.1 上传流程解析

3.1.1 选择Tracker Server

集群中的 tracker 之间都是对等的，客户端在上传文件时可任意选择一个 tracker 即可。

3.1.2 分配Group、Stroage Server 和storage path（磁盘或者挂载点）

tracker 接收到上传请求时会先给该文件分配一个可以存储的 Group ，然后在Group中分配一个Storage Server给客户端，最后在接收到客户端写文件请求时，Storage Server 会分配一个数据存储目录并写入。

（该过程中的分配策略详见：【负载均衡】）

3.1.3 生成file_id写入并返回

Storage 会生成一个 file_id 来作为当前文件名，file_id 采用 base64 编码，包含：源 storage server ip、文件创建时间、文件大小、文件CRC32校验码 和 随机数。每个存储目录下 有两个256*256个子目录。

Storage 会根据 file_id 进行两次 hash 路由到其中一个子目录中。

最后以file_id为文件名存储文件到该子目录下并返回文件路径给客户端。

最终文件存储路径：

3.2  下载流程解析

3.2.1 解析路径并路由

tracker 接收 client 发送的下载请求时，tracker 从文件名中解析出 Group、大小、创建时间等信息，然后根据Group 选择一个 storage server 返回。

3.2.2 校验读取并返回

客户端和 Storage Server 建立链接，校验文件是否存在，最终返回文件数据。

缺点：Group之间文件同步是异步进行的，可能上传的文件还未同步到当前访问的 Storage Server 这台机器上或者延迟原因，将导致下载文件出现404。所以引入nginx_fastdfs_module 可以很好的解决同步和延迟问题。

3.3 引入fastdfs_nginx_module组件后的下载架构

FastDFS Nginx Module功能介绍

（1）【防盗链检查】

利用 FastDFS nginx 扩展功能动态生成token，设置http.conf 配置。

• 开启防盗链功能

  http.default_content_type =

  application/octet-stream

  http.mime_types_filename=mime.types

• 开启token防盗链功能
  

  http.anti_steal.check_token=true

• token过期时间
  

  http.anti_steal.token_ttl=900

• 密钥
  

  http.anti_steal.secret_key=xxx

• token 过期后返回的内容
  

  http.anti_steal.token_check_fail=/etc/fdfs/anti-steal.jpg

【token 生成算法】：md5(fileid_without_group + privKey + ts) 同时ts没有超过 ttl 范围。

（2）【文件元数据解析】

根据 file_id 获取元数据信息, 包括：源storage ip，文件路径，名称，大小 等。

（3）【文件访问路由】

因文件的file_Id 包含了上传文件时的源 Storage Server IP ，所以在获取不到本机下的文件时（未同步或者延迟情况下）FastDFS 扩展组件，会根据源服务器IP 来重定向或者代理方式获取文件。

• 重定向模式
  

  配置项response_mode = redirect，服务器返回302，重定向url

  http://源storage ip:port/文件路径?redirect=1

• 代理模式

  配置项response_mode = proxy，使用源storage 地址作为代理proxy的host，其他部分不变

4.1 同步规则

同步只发生在本组的 Storage Server 之间。

源头数据才需要同步，备份数据不需要再次同步。

新增 Storage Server 时，会由已有一台 Storage Server 将已有的所有数据（源头数据和备份数据）同步给新增服务器。

4.2 Binlog 复制

FastDFS 文件同步采用binlog异步复制方式，Storage Server 使用binlog文件记录文件上传、删除等操作，根据Binlog进行文件同步。Binlog中只记录文件ID和操作，不记录文件内容 .binlog 格式如下：

操作类型（部分）：

• C表示源创建、c表示副本创建

• A表示源追加、a表示副本追加

• D表示源删除、d表示副本删除

• . . . . . . .

4.3 同步流程

新增 Storage Server 后，组内其他 Storage Server 服务器会启动同步线程，在 tracker的协调下向新增服务器发起全量和增量同步操作。

（1）Storage C启动后向tracker 上报所属group、ip、port、版本号、存储目录数、子目录数、启动时间、老数据是否同步完成，当前状态等信息。

（2）tracker 收到Storage C 加入申请请求后，更新本地storage list，返回给C，并适时同步给A、B。

（3）storage C向tracker 申请同步请求，响应后变更自身状态为WAIT_SYNC。

（3）storage A 和B 在心跳周期内从同步到的新storage list 发现没有C，则启动同步线程，先向tracker发起同步申请

（TRACKER_PROTO_CMD_STORAGE_SYNC_SRC_REQ）,tracker会把同步源IP级同步时间戳返回给A和B,如果源IP和自己本地IP一致，则标记自己作为同步源用来做老数据同步（全量同步源），如果不一致，则标记自己作为增量同步源（只有在C节点状态为Active时才同步）。该决策是由tracker 选择产生的，不可A、B同时作为同步源，同时同步给C。

（3）同步源（假设是storage A）以 .mark为后缀的文件记录目标机器同步信息，并上报变更storage C状态为SYNCING。

（4）从/data.sync目录下读取binlog.index 中的，binlog文件Id，binlog.000读取逐行读取，进行解析.(详见上面binlog 内格式) 发送数据给storage C ，C接收并保存。

（5）数据同步过程中 storage C 的状态变更过程OFFLINE->ONLINE->ACTIVE。ACTIVE 是最终状态，表示storage C 已对外提供服务。

5.1 LOSF问题

小文件存储（LOSF）面临的问题：

• 本地文件系统innode梳理优先，存储小文件数量受限。

• 目录层级和目录中文件数量会导致访问文件开销很大（IO次数多）。

• 小文件存储，备份和恢复效率低。

针对小文件存储问题，FastDFS 提供了文件合并解决方案。FastDFS 默认创建大文件为 64M，大文件可以存储很多小文件，容纳一个小文件的空间叫slot，solt 最小256字节，最大16M。小于256字节当256字节存储，超过16M文件单独存储。

5.2 存储方式

（1）【默认存储方式】未开启合并 ，FastDFS生成的file_id 和磁盘上实际存储的文件一一对应。

（2）【合并存储方式】多个file_id对应文件被存储成了一个大文件 。trunk文件名格式：/fastdfs/data/00/000001 文件名从1开始递增。而生成的file_id 更长，会新增16个字节额外内容用来保存偏移量等信息。

如下：

5.4 存储空间管理

（1）【Trunk Server】由tracker leader 在一组Storage Server 选择出来的，并通知给该组内所有Storage Server，负责为该组内所有upload操作分配空间。

（2）【空闲平衡树】trunk server 会为每个store_path构造一个空闲平衡树，相同大小的空闲块保存在链表中，每次上传请求时会到根据上传的文件大小到平衡树中查找获取大于或者接近的空闲块，然后从空闲块中分割出多余的作为新的空闲块，重新加入平衡树。如果找不到则会重建一个新的trunk文件，并加入到平衡树中。该分配过程即是一个维护空闲平衡树的过程。

（3）【Trunk Binlog】开启了合并存储后，Trunk Server 会多出一个TrunkBinlog同步。TrunkBinlog记录了TrunkServer 所有分配与回收的空闲块操作，并由Trunk Server同步给同组中其他storage server。

TrunkBinlog格式如下：

各字段含义如下： 

FastDFS不具备文件去重能力，必须引入FastDHT 来配合完成。FastDHT 是一个键值对的高效分布式hash系统，底层采用Berkeley DB 来做数据库持久化，同步方式使用binlog复制方式。在FastDFS去重场景中，对文件内容做hash，然后判断文件是否一致。

在文件上传成功后，查看 Storage存储对应存储路径，会发现返回的是一个软链接，之后每次重复上传都是返回一个指向第一次上传的文件的软链接。也就保证了文件只保存了一份。

FastDFS 真正意义上只是一个管理文件的系统（应用级文件系统），比如管理上传文件、图片等。并不像系统磁盘文件系统NTFS或者FAT 等这种系统级文件系统。