什么是 FastDFS
很多以文件为载体的在线服务，如相册网站、视频网站等，都须要对文件进行治理，包含文件的存储、同步、拜访（文件上传、文件下载）等，同时必定会随同着大容量存储和负载平衡的问题。
在日常的一些我的项目中，比方做用户的 KYC 认证等，也须要存储文件、图片、视频等。此时能够抉择应用 OSS 云服务，也能够本人构建绝对业余的文件管理系统。
FastDFS 是一个开源的轻量级分布式文件系统，用于解决大数据量存储和负载平衡等问题，并须要通过专有 API 进行拜访。满足大容量文件存储问题，并保障高性能和高扩展性。它可能很好的解决上述提到的业务场景。
FastDFS 的个性
FastDFS 为互联网量身定制，充分考虑了冗余备份、负载平衡、线性扩容等机制，并重视高可用、高性能等指标，应用 FastDFS 很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。
长处：
- 文件不分块存储，文件和零碎中的文件一一对应。
- 对文件内容做 hash 解决，避免出现反复文件，节约磁盘空间。
- 下载文件反对 HTTP 协定，可基于内置 Web Server 或内部 Web Server。
- 反对在线扩容，动静增加卷。
- 反对文件冗余备份和负载平衡。
- 存储服务器上能够保留文件属性（meta-data）V2.0 网络通信采纳 libevent，反对大并发拜访，整体性能更好。
毛病：
- 间接按文件存储，可间接查看文件内容，不足文件安全性。
- 数据同步无校验，存在静默 IO 问题，升高零碎可用性。
- 单线程数据同步，仅适宜存储小文件（4KB 到 500MB 之间）。
- 备份数依据存储分卷（分组）决定，不足文件备份数设置灵活性。
- 单个挂载点异样会导致整个存储节点下线。
- 不足多机房容灾反对。
- 动态的负载平衡机制。
长处与毛病并存，但针对中小型零碎曾经齐全足够应用了。
FastDFS 的角色
首次接触或部署 FastDFS 的敌人往往会有些纳闷，为什么要部署那么多服务能力应用 FastDFS。这是由 FastDFS 的角色形成决定的。
FastDFS 零碎有三个角色：跟踪服务器 (Tracker Server)、存储服务器(Storage Server) 和客户端(Client)。
如果通过 Http 拜访，通常状况下，还须要部署 Nginx 服务。
Tracker Server：跟踪服务器，次要做调度工作，起到平衡的作用；负责管理所有的 storage server 和 group，每个 storage 在启动后会连贯 Tracker，同步本人所属 group 等信息，并放弃周期性心跳。它是客户端和数据服务器交互的枢纽。
Storage Server：存储服务器，次要提供容量和备份服务；以 group 为单位，每个 group 内能够有多台 storage server，数据互为备份。文件及属性（Meta Data）都保留在该服务器上。
Client：客户端，上传下载数据申请的发起方，通过专有接口，应用 TCP/IP 协定与跟踪器服务器或存储节点进行数据交互。
上面通过一张图来看看 FastDFS 的不同角色在整个流转过程中的作用。
上图中 Tracker 相当于一个调度核心，上传和下载都通过它来进行调配指定。
下面咱们提到 Nginx，客户端通常会应用 Ngnix 等动态服务器来调用或者做一部分的缓存。前面搭建环境时便是基于 Nginx。
Storage cluster 局部，由 Volume1、Volume2……VolumeK 组成，它们称为卷（或者叫做组），卷与卷之间是平行的关系，能够依据资源的应用状况随时减少，卷内服务器文件互相同步备份，以达到容灾的目标。
上传过程
当服务启动之后，Storage Server 会定期的向 Tracker Server 发送存储信息。如果 Tracker Server 是集群模式，则每个 Tracker 之间的关系是对等的，客户端上传时抉择任意一个 Tracker 即可。
整体流程：当客户端申请 Tracker 进行上传操作时，会获取存储服务器相干信息，次要包含 IP 和端口。依据返回信息上传文件，通过存储服务器写入磁盘，并返回给客户端 file_id、门路信息、文件名等信息。
对应流程图如下：
其中，当 Tracker 收到客户端上传文件的申请时，会为该文件调配一个能够存储文件的 group，入选定了 group 后就要决定给客户端调配 group 中的哪一个 storage server。
当调配好 storage server 后，客户端向 storage 发送写文件申请，storage 将会为文件调配一个数据存储目录。而后为文件调配一个 fileid，最初依据以上的信息生成文件名存储文件。
生成的文件名根本格局如下：
下载过程
跟上传一样，在下载时客户端能够抉择任意 Tracker server。
客户端带文件名信息申请 Tracker，Tracker 从文件名中解析出文件的 group、大小、创立工夫等信息，而后抉择一个 storage 用来服务解决申请，返回对应文件。
对应流程图如下：
如果是基于 Web 的 http 申请，此处的 Client 能够是 Nginx 代理服务。上面这张图更加形象的形容了相干的流程。
小结
对于 FastDFS 的根本个性和原理曾经介绍结束，重点关注三个角色和两个流程，以及将三个角色融入到两个流程中进行剖析。明确了这个大的方向之后，至于执行的细节局部就能够逐渐理解和把握。
下一篇文章咱们未来介绍基于 Docker 如何部署 FastDFS。关注微信公众号【程序新视界】取得继续更新内容。
<center>程序新视界：精彩和成长都不容错过 </center>