FastDFS基础概述与系统架构详解
目录
- 一、FastDFS简介
- 二、FastDFS系统架构
- 1. 跟踪服务器（Tracker Server）
- 2. 存储服务器（Storage Server）
- 3. 客户端（Client）
- 三、FastDFS功能逻辑分析
- 1. 文件上传（Upload File）原理
- 2. 文件下载（Download File）逻辑
一、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配置相同，避免存储空间浪费。
组管理优势：
- 应用隔离：不同应用的数据存储于不同的Group，实现数据隔离。
- 负载均衡：根据应用访问特性，将不同应用分配至不同Group，实现负载均衡。
- 副本定制：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：
- 轮询（Round Robin）：在所有Group间轮流选择。
- 指定Group（Specified Group）：指定特定的Group。
- 负载均衡（Load Balance）：选择剩余空间最大的Group进行上传。
步骤三：选择Storage Server
- 确定Group后，Tracker在该Group内选择一个Storage Server，依据以下规则：
- 轮询（Round Robin）：在Group内Storage Server间轮流选择。
- 按IP排序：选择IP排序后的首个服务器。
- 按优先级排序：依据配置的优先级选择首个服务器。
步骤四：选择存储路径
- 客户端向选定的Storage Server发送写文件请求，Storage根据以下规则分配数据存储目录：
- 轮询（Round Robin）：在多个存储目录间轮流选择。
- 剩余空间最大优先：优先选择剩余存储空间最多的目录。
步骤五：生成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的策略：
- 源头Storage优先：源头Storage始终存有文件副本，Tracker优先选择源头Storage进行读取。
- 时间戳机制：Tracker基于同步时间点，选择已同步完毕的Storage Server，确保读取的数据一致性。
参考：
0voice · GitHub