fastdfs --详解

1. 为什么会有这个东西？
2. 这个东西怎么实现的？
3. 这个东西怎么用的？

1. 为什么会存在 fastdfs

参考链接–了解为什么有分布式
参考链接–分布式文件系统详解

FastDFS 是一个开源的轻量级分布式文件系统，主要解决了海量数据存储问题，特别适合以中小文件（建议范围：4 KB < file_size < 500 MB）为载体的在线服务。

2. fastdfs 的实现

参考链接–简书

2.1 结构组成

由跟踪服务器（tracker server）、**存储服务器（storage server）和客户端（client）**三个部分组成。

1. Tracker Server 跟踪服务器
   主要做调度工作，起到均衡的作用；
   负责管理所有的 Storage server 和 group，每个 storage 在启动后会连接 Tracker，告知自己所属 group 等信息，并保持周期性心跳。
   tracker 上的元信息都是由 storage 汇报的信息生成的，本身不需要持久化任何数据，这样使得 tracker 非常容易扩展，直接增加 tracker 机器即可扩展为 tracker cluster 来服务，cluster 里每个 tracker 之间是完全对等的，所有的 tracker 都接受 stroage 的心跳信息，生成元数据信息来提供读写服务，tracker 根据 storage 的心跳信息，建立 group==>[storage server list] 的映射表。

2. Storage Server 存储服务器
   主要提供容量和备份服务；
   以 group 为单位，每个 group 内部可以有多台 storage server，数据互为备份。
   客户端上传的文件最终存储在 storage 服务器上，Storage server 没有实现自己的文件系统，而是利用操作系统的文件系统来管理文件，可以将storage 称为存储服务器。storage 可配置多个数据存储目录，比如有10块磁盘，分别挂载在 /data/disk1-/data/disk10，则可将这 10 个目录都配置为 storage 的数据存储目录。

3. Client 客户端
   上传下载数据的服务器，也就是我们自己的项目所部署在的服务器。FastDFS 向使用者提供基本文件访问接口，比如 upload、download、append、delete 等，以客户端库的方式提供给用户使用。

fastdfs 结构图示如下：

• 跟踪服务器和存储节点都可以由一台或多台服务器构成
• 跟踪服务器和存储节点均可以随时增加或者下线不会影响线上服务，
  其中跟踪服务器中所有服务器是对等，可以根据服务器压力情况随时增加或减少

2.2 工作流程

参考链接–RAID
client 请求 Tracker server 进行文件上传、下载，通过 Tracker server 调度最终由 Storage server 完成文件上传和下载，在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个 Storage，从而实现软 RAID 10。

2.2.1 文件上传流程

• Storage server 会连接集群中所有的 Tracker server，定时向他们报告自己的状态，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。
• 上传的内部机制如下：
  1. 选择 tracker server
     当集群中不止一个 tracker server 时，由于 tracker 之间是完全对等无状态的关系，当集群中不止一个 tracker server 时，由于 tracker 之间是完全对等的关系，客户端在 upload 文件时可以任意选择一个 trakcer。 选择存储的 group 当 tracker 接收到 upload file 的请求时，会为该文件分配一个可以存储该文件的 group，支持如下选择 group 的规则：
     1. Round robin，所有的 group 间轮询
     2. Specified group，指定某一个确定的 group
     3. Load balance，剩余存储空间更多 group 优先

2. 选择storage server
   当选定 group 后，tracker 会在 group 内选择一个 storage server 给客户端，支持如下选择 storage 的规则：

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

3. storage path
   当分配好 storage server 后，客户端将向 storage 发送写文件请求，storage 将会为文件分配一个数据存储目录，支持如下规则：

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

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

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

2.2.2 文件下载流程

跟 upload file 一样，在 download file 时客户端可以选择任意 tracker server。tracker 发送 download 请求给某个 tracker，必须带上文件名信息，tracke 从文件名中解析出文件的 group、大小、创建时间等关键信息返回给 client，最后 client 拿着关键信息组成的请求去选择一个 storage 用来服务读请求。

定位文件 客户端上传文件后存储服务器将文件 ID 返回给客户端，此文件 ID 用于以后访问该文件的索引信息。文件索引信息包括：组名，虚拟磁盘路径，数据两级目录，文件名。

• 组名
  文件上传后所在的 storage 组名称，在文件上传成功后有 storage 服务器返回，需要客户端自行保存。
• 虚拟磁盘路径
  storage 配置的虚拟路径，与磁盘选项store_path* 对应。如果配置了store_path0 则是 M00，如果配置了 store_path1 则是 M01，以此类推。
• 数据两级目录
  storage 服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件。
• 文件名
  与文件上传时不同。是由存储服务器根据特定信息生成，文件名包含：源存储服务器IP地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。
  
  知道 FastDFS FID 的组成后，我们来看看 FastDFS 是如何通过这个精巧的 FID 定位到需要访问的文件：
  1. 通过组名 tracker 能够很快的定位到客户端需要访问的存储服务器组，并将选择合适的存储服务器提供客户端访问
  2. 存储服务器根据 “文件存储虚拟磁盘路径” 和 “数据文件两级目录” 可以很快定位到文件所在目录，并根据文件名找到客户端需要访问的文件

3. 文章没写完，因为网上跟原理相关的资料很少，直接看代码来的更快点。

gitee