一、FastDFS简介

FastDFS（Fast Distributed File System）是一个开源的分布式文件系统，旨在提供高性能、高可靠性及可扩展性的文件存储解决方案，专门应对海量数据存储的挑战。其核心功能涵盖文件存储、同步及访问，尤其适用于中小型文件（推荐范围：4KB < 文件大小 < 500MB）作为载体的在线服务场景，如图片分享平台和视频分享网站。

应用场景示例：
假设您运营一个大型网站，用户可以上传和下载大量图片及视频文件。如果所有文件集中存储在单一服务器上，可能导致服务器负载过高、存储空间不足及访问速度缓慢等问题。此时，采用分布式存储将文件分散至多台服务器，可以显著提升系统的整体性能与可靠性。

FastDFS正是为解决此类问题而设计。它通过将大文件切分为小块，并分散存储在多台服务器上，实现文件的分布式存储。此外，FastDFS还提供了文件上传、下载、删除等操作接口，便于开发人员高效地管理分布式文件。

FastDFS开源地址：
FastDFS GitHub 仓库

二、FastDFS系统架构

FastDFS主要由跟踪服务器（Tracker Server）、**存储服务器（Storage Server）和客户端（Client）**三部分构成。

1. 跟踪服务器（Tracker Server）

跟踪服务器在FastDFS中充当调度和负载均衡的角色。它在内存中维护集群内所有存储组及存储服务器的状态信息，作为客户端与存储服务器交互的核心枢纽。

主要职责：

• 协调管理：负责管理所有Storage Server和Group。
• 心跳机制：每个Storage Server启动后会连接Tracker，报告所属Group信息并定期发送心跳。Tracker依据心跳信息建立Group与Storage Server列表的映射。
• 动态分配：客户端在访问Storage Server前，需先联系Tracker获取可用的Storage Server信息，从而实现动态负载均衡。
• 高扩展性：Tracker仅管理少量元数据，全部存储于内存中，无需持久化数据。通过增加Tracker实例，可以轻松扩展为集群模式，提升系统的可扩展性与容错能力。

2. 存储服务器（Storage Server）

Storage Server按照**组（Group）**进行组织，每个Group包含多台Storage Server，数据在组内实现互为备份。存储空间以Group内最小容量的Storage Server为基准，建议组内所有Storage配置相同，避免存储空间浪费。

组管理优势：

1. 应用隔离：不同应用的数据存储于不同的Group，实现数据隔离。
2. 负载均衡：根据应用访问特性，将不同应用分配至不同Group，实现负载均衡。
3. 副本定制：Group内Storage Server数量即为数据副本数，可根据需求定制副本数量。

存储机制：

• 多存储目录配置：Storage Server可配置多个数据存储目录，如配置10块磁盘分别挂载至/data/disk1至/data/disk10，并将这些目录配置为Storage的数据存储路径。
• 文件存储策略：接收到写文件请求后，Storage根据配置规则选择存储目录。为避免单目录文件过多，Storage启动时会在每个存储目录下创建两级子目录，每级256个，总计65536个子目录。新文件通过哈希方式路由至某个子目录，并作为本地文件存储，从而加快文件索引速度。
  

缺点：

• 容量限制：Group容量受单台Storage Server存储容量限制。
• 恢复延时：组内Storage Server故障时，数据恢复需依赖其他Storage Server，可能导致较长的恢复时间。

3. 客户端（Client）

FastDFS客户端提供基本的文件访问接口，如monitor、upload、download、append、delete等，通过客户端库供用户使用，简化分布式文件操作。

三、FastDFS功能逻辑分析

1. 文件上传（Upload File）原理

上传文件过程涉及以下步骤：

步骤一：选择Tracker Server

• 在集群中存在多个Tracker Server时，客户端可任意选择一个进行文件上传。

步骤二：选择存储Group

• Tracker接收到上传请求后，依据以下规则分配合适的Group：
  1. 轮询（Round Robin）：在所有Group间轮流选择。
  2. 指定Group（Specified Group）：指定特定的Group。
  3. 负载均衡（Load Balance）：选择剩余空间最大的Group进行上传。

步骤三：选择Storage Server

• 确定Group后，Tracker在该Group内选择一个Storage Server，依据以下规则：
  1. 轮询（Round Robin）：在Group内Storage Server间轮流选择。
  2. 按IP排序：选择IP排序后的首个服务器。
  3. 按优先级排序：依据配置的优先级选择首个服务器。

步骤四：选择存储路径

• 客户端向选定的Storage Server发送写文件请求，Storage根据以下规则分配数据存储目录：
  1. 轮询（Round Robin）：在多个存储目录间轮流选择。
  2. 剩余空间最大优先：优先选择剩余存储空间最多的目录。

步骤五：生成Fileid

• Storage根据文件信息生成Fileid，包含Storage Server的IP、文件创建时间、文件大小、CRC32校验码及随机数，通过Base64编码转换为可打印字符串。

步骤六：选择两级目录

• Storage依据Fileid将文件路由至存储目录下的两级子目录（每级256个），确保文件均匀分布。

步骤七：生成文件名

• 文件存储成功后，生成文件名，格式为Group、存储目录、两级子目录、Fileid及文件后缀名（由客户端指定，用于区分文件类型）拼接而成。
  

2. 文件下载（Download File）逻辑

下载文件过程如下：

步骤一：选择Tracker Server

• 客户端在下载文件时，可选择任意Tracker Server。

步骤二：发送下载请求

• 客户端将文件名信息发送至选定的Tracker Server，Tracker解析文件名中的Group、文件大小、创建时间等信息，并选择一个Storage Server提供读取服务。

一致性问题处理：
FastDFS采用弱一致性，即先返回存储结果，再进行数据同步，提升速度但可能导致部分Storage Server数据未同步。

避免访问未同步Storage的策略：

1. 源头Storage优先：源头Storage始终存有文件副本，Tracker优先选择源头Storage进行读取。
2. 时间戳机制：Tracker基于同步时间点，选择已同步完毕的Storage Server，确保读取的数据一致性。

---

参考：
0voice · GitHub