FastDFS是用C语言编写的一款开源的轻量级分布式文件系统。它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。
FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。
Hadoop也是一个分布式文件系统，hadoop是处理大数据的，什么是大数据呢？就是海量数据。海量数据你一块磁盘估计存不下，那么就需要把数据存到多个磁盘上，还得统一管理，这时就需要一个分布式文件系统来管理。FastDFS同样也是这么一个意思，图片我们有很多，但容量有上限，所以我们要把这些所有的图片存储到多台服务器上，还要进行统一管理，那么就需要一个分布式文件系统，很显然那就是FastDFS了，FastDFS适合于存取图片（建议范围：4KB < file_size <500MB）。
FastDFS其实很早开始使用，但这次要作内训，因此下面借鉴网友的部份内容结合实践作总结，有些出处可能忘了 请多担待。
FastDFS架构下面来看一张FastDFS的架构图，如下图所示。
FastDFS架构包括Tracker server和Storage server。
客户端请求Tracker server进行文件上传、下载，通过Tracker server调度最终由Storage server完成文件上传和下载。Tracker server的作用是负载均衡和调度，通过Tracker server在文件上传时可以根据一些策略找到Storage server提供文件上传服务，可以将tracker称为追踪服务器或调度服务器。Tracker server跟踪器和存储节点都可以由一台或多台服务器构成，跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务，其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。Tracker负责管理所有的Storage和group，每个storage在启动后会连接Tracker，告知自己所属的group等信息，并保持周期性的心跳，tracker根据storage的心跳信息，建立group==>[storage server list]的映射表，Tracker需要管理的元信息很少，会全部存储在内存中；另外tracker上的元信息都是由storage汇报的信息生成的，本身不需要持久化任何数据，这样使得tracker非常容易扩展，直接增加tracker机器即可扩展为tracker cluster来服务，cluster里每个tracker之间是完全对等的，所有的tracker都接受stroage的心跳信息，生成元数据信息来提供读写服务。
Storage server作用是文件存储，客户端上传的文件最终存储在Storage服务器上，Storage server没有实现自己的文件系统而是利用操作系统的文件系统来管理文件，可以将storage称为存储服务器。存储系统由一个或多个组组成，组与组之间的文件是相互独立的，所有组的文件容量累加就是整个存储系统中的文件容量。一个卷[Volume]（组[group]）可以由一台或多台存储服务器组成，一个组中的存储服务器中的文件都是相同的，组中的多台存储服务器起到了冗余备份和负载均衡的作用，数据互为备份，存储空间以group内容量最小的storage为准，所以建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。
我们从上图还能看到，Client端可以有多个，也就是同时支持多个客户端对FastDFS集群服务进行访问，Tracker是跟踪器，负责协调Client与Storage之间的交互，为了实现高可用性，需要用多个Tracker来作为跟踪器。Storage是专门用来存储东西的，而且是分组进行存储的，每一组可以有多台设备，这几台设备存储的内容完全一致，这样做也是为了高可用性，当现有分组容量不够时，我们可以水平扩容，即增加分组来达到扩容的目的。另外需要注意的一点是，如果一组中的设备容量大小不一致，比如设备A容量是80G，设备B的容量是100G，那么这两台设备所在的组的容量会以小的容量为准，也就是说，当存储的东西大小超过80G时，我们将无法存储到该组中了。Client端在与Storage进行交互的时候也与Tracker cluster进行交互，说的通俗点就是Storage向Tracker cluster进行汇报登记，告诉Tracker现在自己哪些位置还空闲，剩余空间是多大。
文件上传的流程现给出一张文件上传的时序图，如下图所示：