概述

最近搭建的系统文件服务是用fastdfs来做的，所以顺便整理了下这块内容。

FastDFS阿里巴巴开源的一套轻量级分布式文件系统，是由纯C语言编写的。它支持Linux、FastBSD等UNIX系统。

FastDFS是专为互联网应用量身定做，目的是追求高性能和高拓展性。它可以看做是基于文件的key value pair存储系统，称作分布式文件存储服务更为合适。

FastDFS系统架构

FastDFS的系统架构图如下：

在FastDFS有三种角色，第一种是Client客户端，第二种是Tracker追踪服务器，第三种就是Storage存储服务器。其中Client客户端就是官方提供的C、Java和PHP的调用API。

关于存储服务器，是采用分组的方式，同一个组内的服务器的文件是完全相同的(利用同步线程进行同步)，组和组之间是不通信的。而存储服务器会主动定期向追踪服务器报告目前的状态，追踪服务器可以有多个，多个之间是对等的，不存在主从。

关于客户端，是不需要存储有关存储服务器的任何信息的。一般用户的请求不是直接请求存储服务器，而是会请求追踪服务器。例如一个客户端需要上传文件，此时追踪服务器就会从存储服务器中找出一个组分配给客户端，供其上传文件，此时客户端拿到组的信息后，开始直接和存储服务器的这个组进行交互，无需再通过追踪服务器进行中转。

Tracker Servre：

追踪服务器，主要做调度工作，在访问中起负载均衡的作用。在内存中记录集群中group和storage server的状态信息，是连接Client和Storage的枢纽。因为相关信息全部在内存中，Tracker server的性能非常高，一个比较大的集群(比如上百个group)中有三台就足够了。

Storage Server：

存储服务器，文件和文件属性(meta data)都保存在存储服务器上。

FastDFS上传下载机制

下图是FastDFS的上传机制流程

步骤1，存储服务器在定时的向追踪服务器上传存储状态。

步骤2，客户端设置追踪服务器的地址，并向追踪服务器发送上传的连接请求。

步骤3，追踪服务器进行一个调度，来查询当前可用的存储。

步骤4，追踪服务器向客户端返回一个可用的存储服务器组的ip和端口。

步骤5，客户端获取到存储服务器组的ip和端口后，向存储服务器上传文件，其中包括文件的内容信息和metadata。

步骤6，存储服务器接收到文件传输的请求后，会生成一个文件的file_id。

步骤7，存储服务器将刚才的文件内容写入存储服务器的本地硬盘。

步骤8，存储服务器将刚才存储的文件的file_id以及存储的路径和文件名返回给客户端。

步骤9，客户端将文件的file_id以及存储位置存放在客户端中，等待以后的下载。

同理，下载机制如下：

客户端带上文件名信息请求Tracker服务获取到存储服务器的ip地址和端口，然后客户端根据返回的IP地址和端口号请求下载文件，存储服务器接收到请求后返回文件给客户端。

总之，追踪服务器在中间起到了帮客户端去寻找合适的存储服务器，并返回给客户端去发送文件，从而可以保证上传的性能是最佳的。而后面客户端也是直接和存储服务器进行通信的，无需再通过追踪服务器。

篇幅有限，今天主要是对这块概念做个简单介绍，大家感兴趣可以深入研究下。后面会分享搭建的整体过程，感兴趣的朋友走一波关注哩~