前言
在分布式微服务的架构中，我们都会遇到一个问题，那就是文件的存储，而这个文件还不能单独存储在某一台应用服务器上，如果存储在某一台单独的应用服务器上，在分布式环境下或者当前应用服务器需要横向扩展的时候，就会大大的增加其运行维护的复杂度，和维护成本，所以这里就需要文件的存储抽取出来，作为一个单独服务器-文件服务器，这样不论应用服务器如何的扩展，都不会影响，而且如果文件服务器压力打，还可以单独的优化。
关于文件服务器，市面上流行的有很多，例如：FastDFS、HDFS、Lustre、MogileFs、MooseFS、GlusterFS、TFS 等等，各有优点，在项目中具体使用那个文件服务器，就需要项目的Leader根据各项因素去衡量了，那本篇文件主要对FastDFS进行介绍，通过本篇文章学习，你将深入的认识FastDFS分布式文件系统，并了解其架构原理、以及基于FastDFS的上传/下载流程等内容。
FastDFS分布式文件系统内部架构及其原理解析
1、关于FastDFS
FastDFS 是用 C 语言编写的一款轻量级的开源的分布式文件系统，主要解决了在实际应用中一些大文件存储和高并发访问的问题。FastDFS 为互联网应用量身定制，适合中大型网站应用，其主要用作资源的存/取服务器（例如：图片、文档、音频、视频等等），且充分考虑了冗余备份（高可用）、负载均衡（高并发量）、线性扩容（添加服务器或者磁盘）等机制，并注重高可用、高性能等指标，使用 FastDFS 很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。
FastDFS 由三个核心部分组成：客户端（Client）、跟踪服务器（Tracker Server）、存储服务器（Storage Server）
版本演变：
- 2008年4月项目启动，7月发布第一个版本V1.00，两年的时间内持续升级到V1.29；
- 2010年8月推出V2.00。V2.x最新版本是V2.13；
- 2011年6月推出V3.00。当前最新版本是V3.06。V3.x后续会一直进行维护和升级；
- V1和V2系列后续不再维护和升级；
- 2014年9月退出V5.00。最近一次发布迭代版本是在2017年6月，主要对一些客户端进行优化；
版本历史：
- V1.x：采用传统的一个请求一个线程服务的模式，系统资源消耗较大，支持的并发连接数在1K左右；
- V2.x：采用libevent异步IO模型，磁盘读写采用专门的线程，比V1.x的工作模型更加先进和高效。支持的并发连接数可以达到10K；
- V3.x：支持小文件合并存储，解决海量小文件的存储问题；
- V4.x:
- V5.x:
特点：
- 分组存储，灵活简洁，对等结构，不存在单点；
- 文件ID由FastDFS生成，作为文件访问凭证。FastDFS不需要传统的name server和流行的web server无缝衔接，FastDFS已提供apache和nginx扩展模块的支持；
- 大、中、小文件均可以很好支持，支持海量小文件存储（V3.x加入的）；
- 支持多块磁盘，支持单盘数据恢复；
- 支持相同文件内容只保存一份，节省存储空间；
- 存储服务器上可以保存文件附加属性；
- 下载文件支持多线程方式，且支持断点续传；
2、FastDFS架构
FastDFS 只有两个角色，即 Tracker server 和 Storage server。其服务器上所有文件的索引信息无需存储，所有服务器都是对等的，不存在 Master-Slave 关系，存储服务器采用分组存储的方式，同组内存储服务器上的文件完全相同（RAID 1），不同组的 storage server 之间是不会相互通信的，所有 storage server 主动向 tracker server 报告自身的状态信息，tracker server 之间通常不会相互通信。
客户端请求 Tracker server 进行文件上传、下载，通过 Tracker server 调度最终由 Storage server 来完成文件上传和下载。
Tracker server：作用是实现负载均衡和调度的，通过 Tracker server 在文件上传时可以根据一些策略找到相应的 Storage server 来提供文件上传服务。可以将 Tracker server 称为追踪服务器或调度服务器。
Storage server：作用是实现文件存储的，在客户端上传的文件最终都将存储在 Storage server 上，Storage server 没有实现自己的文件系统而是利用操作系统的文件系统来管理文件。可以将 Storage server 称为存储服务器。
1）、Tracker Cluster
FastDFS 集群中的 Tracker server 可以有多台，Tracker server 之间是相互平等关系同时提供服务，Tracker server 不存在单点故障。客户端请求 Tracker server 默认采用轮询方式，如果当前请求的tracker无法提供服务则切换到另一个tracker。
2）、Storage Cluster
Storage Cluster 采用了分组存储方式。Storage 集群由一个或多个组构成，集群存储总容量为集群中所有组的存储容量之和。一个组由一台或多台存储服务器组成，组内的Storage server之间是平等关系，不同组的Storage server之间不会相互通信，但是在同一组内的Storage server之间会相互连接进行文件同步的，从而保证同组内每个Storage Server 上的文件完全一致的。一个组的存储容量为该组内所有Storage Server 容量最小的那个基准，由此可见组内存储服务器的软硬件配置最好是一致的，否则会浪费不必要的资源。
3）、关于Storage Cluster的分组存储
FastDFS 之所以采用分组存储方式，其带来的好处是灵活、可控性较强。比如在上传文件时，可以由客户端直接指定上传到的组也可以由tracker进行调度选择。一个分组的存储服务器访问压力较大时，可以在该组增加存储服务器来扩充服务能力（纵向扩容）。当系统容量不足时，可以增加组来扩充存储容量（横向扩容）。
4）、Storage Server 状态上传
Storage server 会连接集群中所有的 Tracker server，并定时向 Tracker server 上传自己的状态信息，包括磁盘剩余空间、文件同步情况、文件上传下载次数等信息。
5）、FastDFS同步机制
FastDFS 采用了 binlog 文件记录文件上传、删除等操作，根据 binlog 进行文件同步，binlog 中只记录文件名，不会记录文件内容，通过增量同步的方式，记录已同步的位置到 “ .mark ” 文件中。
在同一个组内的 storage_server 之间是对等的，文件上传、删除等操作可以在任意一台 storage_server 上进行，文件的同步只在同组内的 storage_server 之间进行，采用 push 的方式，即源头服务器同步给目标服务器。
3、FastDFS 的文件上传流程
Client 上传文件后Storage Server 会将 File_ID 返回给客户端，此File_ID主要用于在以后访问该文件时的唯一索引信息。文件索引信息包括：组名、虚拟磁盘路径、数据两级目录、文件名、文件对应的后缀。
- 组名：文件上传后所在的 storage 组名称，在文件上传成功后由 Storage Server 返回，客户端成功接收后自行保存。
- 虚拟磁盘路径：storage 配置的虚拟路径，与磁盘选项 store_path* 对应。如果配置了store_path0则是M00，如果配置了 store_path1 则是M01，以此类推。
- 数据两级目录：storage 服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件。
- 文件名：与文件上传时不同。是由Storage Server根据特定信息生成的，文件名包含：源存储服务器IP地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。
- 后缀名：上传时的文件后缀名，列如图片的有：JPG、PNG、JPEG等，文件的有：PDF、EXCEL、WORD等。
4、FastDFS 的文件下载流程
Tracker 根据请求的File_ID 来快速定位访问的文件。
- 通过组名Tracker能够很快的定位到客户端需要访问的Storage Server 组是 group1，并选择合适的Storage Server来提供客户端服务。
- 存储服务器根据 “文件存储虚拟磁盘路径” 和 “数据文件两级目录” 可以很快定位到文件所在目录，并根据文件名和后缀找到客户端需要访问的目标文件。
如上文件下载流程图，关于如何选择 storag 的策略
首先 client 会询问 tracker 有哪些 storage 可以下载指定文件时，tracker 会返回满足如下四个条件之一的 storage：
- 文件创建时间戳 < storage 被同步到的时间戳
- (当前时间 -文件创建时间戳) > 同步延迟阀值
- 文件创建时间戳 == storage 被同步到的时间戳且(当前时间 -文件创建时间戳) > 文件同步最大时间
- 该文件上传到的源头 storage
一般缺省采用 HTTP 方式下载文件：
FastDFS 分组存储方式，为 HTTP 方式下载提供了便利，FastDFS 支持 HTTP 方式下载文件，不建议使用内置 web server，推荐使用外部 web server，如果apache或nginx，因为需要解决文件同步延迟的问题，因此，在 apache 或者 nginx 上需要使用基于 FastDFS 扩展模块。尤其是在 V3.x 版本引入小文件合并存储后，必须使用扩展模块来读取文件的方式。
5、其它补充说明
1）、FastDFS的扩展模块（可以使用Apache 或 Nginx，目前最佳实践为Nginx->fastdfs-nginx-module）
特性：
- 仅支持HTTP HEAD和GET
- 支持指定保存的缺省文件名，URL参数名为filename
- 支持断点续传
- 支持token方式的防盗链（缺省是关闭的）->ts：生成token的时间（unix元年的时间戳）； token：32位的token字符串（md5签名）
要点：
- 如果请求的文件在当前storage上不存在，通过文件ID反解析出源storage，直接请求源storage;
- 在每台storage_server上部署web server，直接对外提供HTTP服务;
- FastDFS扩展模块不依赖于FastDFS server，可以独立存在;
- tracker_server上不需要部署web_server;
- 使用扩展模块来解决文件同步延迟问题;
- 目前已提供apache和nginx扩展模块;
2）、FastDFS的常用配置
配置最大并发连接数：
参数名：max_connections
缺省值：256
说明：FastDFS 采用预先分配好 buffer 队列的做法，分配的内存大小为：max_connections * buff_size，因此配置的连接数越大，消耗的内存越多。所以连接数不建议配置得过大，以避免无谓的内存开销。
配置工作线程数：
参数名： work_threads
缺省值：4
说明：为了避免CPU上下文切换的开销，以及不必要的资源消耗，不建议将本参数设置得过大。为了发挥出多个CPU的效能，系统中的线程数总和，应等于CPU总数。
对于 tracker server，公式为：
work_threads + 1 = CPU数
对于storage，公式为：
work_threads + 1 + (disk_reader_threads + disk_writer_threads) * store_path_count = CPU数
配置 storage_server 目录数：
参数名：subdir_count_per_path
缺省值：256
说明：FastDFS采用二级目录的做法，目录会在FastDFS初始化时自动创建。存储海量小文件，打开了trunk存储方式的情况下，建议将本参数适当改小，比如设置32，此时存放文件的目录数为 32 * 32 = 1024。假如trunk文件大小采用缺省值64MB，磁盘空间为2TB，那么每个目
录下存放的trunk文件数均值为：2TB / (1024 * 64MB) = 32个
配置 storage_server 磁盘读写线程：
disk_reader_threads：单个磁盘读线程数
disk_writer_threads：单个磁盘写线程数
disk_rw_separated：磁盘读写是否分离
如果磁盘读写混合，单个磁盘读写线程数为读线程数和写线程数之后
对于单盘挂载方式，磁盘读写线程分别设置为1即可
如果磁盘做了RAID，那么需要酌情加大读写线程数，这样才能最大程度地发挥磁盘性能
配置 storage_server 同步延迟相关：
sync_binlog_buff_interval：将binlog buffer写入磁盘的时间间隔，取值大于0，缺省值为60s
sync_interval：同步完一个文件后，休眠的毫秒数，缺省值为0
为了缩短文件同步时间，可以将上述3个参数适当调小即可
3）、FastDFS 部署方案：
文件上传和删除等操作：使用FastDFS client API，目前提供了 C、PHP extension 和 Java 的 client API【API连接】
文件下载采用 HTTP 方式：使用 nginx 或者 apache 扩展模块，不推荐使用 FastDFS 内置的 web server【扩展模块连接】
不要做RAID，通过直接挂载单盘的方式，每个硬盘作为一个 mount point
4）、关于FastDFS常见的面试题
FastDFS 是如何解决同步延迟问题的 ？
storage 生成的文件名中，包含源头 storage IP 地址和文件创建时间戳，源头 storage 会定时向 tracker 报告同步情况，包括向目标服务器同步到的文件时间戳，tracker 收到 storage 的同步报告后，找出该组内每台 storage 被同步到的时间戳（取最小值），作为 storage 属性保存到内存中。
FastDFS 是如何做到无索引服务器的 ？
上传文件时，其文件 ID 由 storage server 生成并返回给 client 端进行存储，文件 ID 包含了组名和文件名，storage server 可以直接根据该文件名定位到文件。
一般一个标准的文件 ID 示例如下图：
文件名中包含的信息：
采用Base64编码，包含的字段包括：源storage server IP地址、文件创建时间、文件大小、文件CRC32校验码及随机数。
合并存储文件ID格式：
- 在文件名后面，增加了16个字节的字符
- 合并存储文件ID采用 Base64 编码，包含的字段包括：存放的 trunk file ID、文件偏移量及占用的空间大小。
好了，关于 FastDFS分布式文件系统内部架构及原理解析 就写到这儿了，如果还有什么疑问或遇到什么问题欢迎扫码提问，也可以给我留言哦，我会一一详细的解答的。
歇后语：“ 共同学习，共同进步 ”，也希望大家多多关注CSND的IT社区。
| 作 者： | 华 仔 |
| 联系作者： | [email protected] |
| 来 源： | CSDN (Chinese Software Developer Network) |
| 原 文： | https://blog.csdn.net/Hello_World_QWP/article/details/94336641 |
| 版权声明： | 本文为博主原创文章，请在转载时务必注明博文出处！ |
