一、FastDFS简单介绍
FastDFS是一款开源的、分布式文件系统（Distributed File System），由淘宝开发平台部资深架构师余庆开发。作为一个分布式文件系统，它对文件进行管理。功能包括：文件存储、文件同步、文件訪问（文件上传、文件下载）等，攻克了大容量存储和负载均衡的问题，特别适合中小文件（建议范围：4KB < file_size <500MB），对以文件为载体的在线服务，如相冊站点、视频站点等等具有显著的效果。
二、FastDFS架构
FastDFS由client，跟踪服务器和存储服务器构成，基本架构例如以下图所看到的。
Storage Server
Storage server（后简称storage）以组（卷，group或volume）为单位组织，一个group内包括多台storage机器，数据互为备份，存储空间以group内容量最小的storage为准，所以建议group内的多个storage尽量配置同样，以免造成存储空间的浪费。
以group为单位组织存储能方便的进行应用隔离、负载均衡、副本数定制（group内storage server数量即为该group的副本数），比方将不同应用数据存到不同的group就能隔离应用数据，同一时候还可依据应用的訪问特性来将应用分配到不同的group来做负载均衡；缺点是group的容量受单机存储容量的限制，同一时候当group内有机器坏掉时，数据恢复仅仅能依赖group内地其它机器，使得恢复时间会非常长。
group内每一个storage的存储依赖于本地文件系统，storage可配置多个数据存储文件夹。比方有10块磁盘，分别挂载在/data/disk1-/data/disk10，则可将这10个文件夹都配置为storage的数据存储文件夹。
storage接受到写文件请求时。会依据配置好的规则（后面会介绍），选择当中一个存储文件夹来存储文件。
为了避免单个文件夹下的文件数太多，在storage第一次启动时。会在每一个数据存储文件夹里创建2级子文件夹，每级256个，总共65536个文件，新写的文件会以hash的方式被路由到当中某个子文件夹下，然后将文件数据直接作为一个本地文件存储到该文件夹中。
Tracker Server
Tracker是FastDFS的协调者，负责管理全部的storage server和group。每一个storage在启动后会连接Tracker，告知自己所属的group等信息，并保持周期性的心跳。tracker依据storage的心跳信息，建立group==>[storage serverlist]的映射表。
Tracker须要管理的元信息非常少，会全部存储在内存中；另外tracker上的元信息都是由storage汇报的信息生成的，本身不须要持久化不论什么数据，这样使得tracker非常easy扩展，直接添加tracker机器就可以扩展为tracker cluster来服务，cluster里每一个tracker之间是全然对等的，全部的tracker都接受stroage的心跳信息，生成元数据信息来提供读写服务。
Client
client，作为业务请求的发起方，通过专有接口，使用TCP/IP协议与跟踪器服务器或存储节点进行数据交互。
三、FastDFS的存储策略
为了支持大容量，存储节点（服务器）採用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成。卷与卷之间的文件是相互独立的，全部卷的文件容量累加就是整个存储系统中的文件容量。一个卷能够由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是同样的。卷中的多台存储服务器起到了冗余备份和负载均衡的作用。
在卷中添加服务器时，同步已有的文件由系统自己主动完毕，同步完毕后。系统自己主动将新增服务器切换到线上提供服务。
当存储空间不足或即将耗尽时，能够动态加入卷。仅仅须要添加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。
四、FastDFS的上传过程
FastDFS向使用者提供基本文件訪问接口，比方upload、download、append、delete等，以client库的方式提供给用户使用。
依据前边的解说。我们知道Storage Server会定期的向Tracker Server发送自己的存储信息。当Tracker Server Cluster中的Tracker Server不止一个时，各个Tracker之间的关系是对等的，所以client上传时能够选择随意一个Tracker。
当Tracker收到client上传文件的请求时，会为该文件分配一个能够存储文件的group。当选定了group后就要决定给client分配group中的哪一个storage server。当分配好storage server后，client向storage发送写文件请求，storage将会为文件分配一个数据存储文件夹。然后为文件分配一个fileid。最后依据以上的信息生成文件名称存储文件。文件名称的格式例如以下： 
五、FastDFS的文件同步
写文件时。client将文件写至group内一个storage server即觉得写文件成功，storage server写完文件后，会由后台线程将文件同步至同group内其它的storage server。
每一个storage写文件后，同一时候会写一份binlog，binlog里不包括文件数据，仅仅包括文件名称等元信息，这份binlog用于后台同步，storage会记录向group内其它storage同步的进度。以便重新启动后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内全部server的时钟保持同步。
storage的同步进度会作为元数据的一部分汇报到tracker上。tracke在选择读storage的时候会以同步进度作为參考。
比方一个group内有A、B、C三个storage server，A向C同步到进度为T1 (T1曾经写的文件都已经同步到B上了），B向C同步到时间戳为T2（T2 > T1)，tracker接收到这些同步进度信息时，就会进行整理。将最小的那个做为C的同步时间戳。本例中T1即为C的同步时间戳为T1（即全部T1曾经写的数据都已经同步到C上了）；同理，依据上述规则，tracker会为A、B生成一个同步时间戳。
六、FastDFS的文件下载
clientuploadfile成功后，会拿到一个storage生成的文件名称，接下来client依据这个文件名称就可以訪问到该文件。
跟upload file一样。在downloadfile时client能够选择随意tracker server。tracker发送download请求给某个tracker，必须带上文件名称信息。tracke从文件名称中解析出文件的group、大小、创建时间等信息，然后为该请求选择一个storage用来服务读请求。
本文是在阅读某大神的文章时进行的整理和摘录，同一时候加入了自己的一些思考，以下附上大神的链接：http://blog.yunnotes.net/index.php/fastdfs_design/