上一篇我们讲解了文件的存储机制，有单机存储、共享存储和分布式存储，那么我们的主角---FastDFS就是一个分布式存储机制的文件系统，本篇为大家介绍一下FastDFS的基本信息和架构。
一、FastDFS介绍
FastDFS阿里巴巴开源的一套轻量级分布式文件系统，是由纯C语言编写的，作者是余庆(happyfish100)，github地址
https://github.com/happyfish100。它支持Linux、FastBSD等UNIX系统。
它类google FS，不是通用的文件系统，只能通过专用API访问，目前提供了C、Java和PHP API。
FastDFS是专为互联网应用量身定做，目的是追求高性能和高拓展性。它可以看做是基于文件的key value pair存储系统，称作分布式文件存储服务更为合适。
FastDFS适合的存储范围为4KB至500M之间，它更倾向于存储中小型文件，如图片网站、短视频网站、文档、app下载站等。
FastDFS的用户有支付宝、京东、赶集网、58同城、UC、51CTO和一些网盘公司，可以说目前用到FastDFS的公司特别多，因为移动互联网的兴起，一些短视频、电子书、小音频和一些app，都在十几兆或者一两百兆左右，使用FastDFS十分合适。
二、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以及存储位置存放在客户端中，等待以后的下载。
说白了，上述行为中，追踪服务器在中间起到了帮客户端去寻找合适的存储服务器，并返回给客户端去发送文件，从而可以保证上传的性能是最佳的。
而后面客户端也是直接和存储服务器进行通信的，无需再通过追踪服务器。