前言
FastDFS主要解决互联网中小文件存储存储问题，例如图片，短视频，提供上传和下载功能，轻量级的设计，结构非常简单，主要包含三个角色客户端，Tracer服务，Storage服务。Tracer服务提供了对客户端请求负载均衡和路由作用，Storage服务提供真正的上传下载，数据同步，冗余备份作用。
系统部署时，首先将几个Storage服务编为一个组，每个组内的Storage服务内保存的文件数据完全相同，相互之间进行数据同步。Tracer服务与所有的Storage服务，Storage服务启动时会连接所有的Tracer服务，并将Storage信息汇总给Tracer服务，主要是同步信息，磁盘空间信息，很少的数据量，所有的数据均在内存中，Tracer并不会成为瓶颈。
上传文件
客户端上传文件时，首先客户端向Tracer发送请求上传文件，Tracer会返回一个Storage地址给客户端，客户端重新连接Storage服务，Storage接收到客户端传送的文件数据，根据文件名生成一个fid索引，并选择合适的位置保存文件数据。Storage服务为了避免同一个目录下的文件数量过多，将磁盘分为两级目录，每级目录下保存256个文件。数据文件保存成功之后，返回生成的fid索引给客户端，并告知文件存储成功。后面Storage会有单独的线程将上传的文件数据同步给同一个组内其他的Storage服务，如果在未同步之前Storage数据损坏了，则用户上传的数据会永久丢失。Storage服务每次同步成功一个文件都会记录一个binlog，保存针对组内所有的Storage服务的同步进度，保证服务重启后能够继续上次未完成的同步进度。客户端收到上传的fid索引后，以后访问文件需要通过fid索引进行访问，fid索引需要应用自行保存，一般可以保存到mysql中，以原始文件名对应fid索引。
下载文件
客户端下载文件时，根据原始文件名找到fid索引，然后发送请求到Tracer服务，Tracer会根据fid索引中的组名，返回给客户端组内Storage服务一个地址，客户端根据此地址连接相应的Storage服务下载对应的文件。如果我们刚上传的文件到一个Storage服务，而它还未将数据同步到其他的Storage服务，则客户端有可能获取不到数据，为了避免这种情况，fid索引中会保存有文件创建时间和上传到Storage服务的源地址，如果当前时间戳小于某个值，则Tracer会返回源地址供客户端下载。
fid索引
fid索引设计很巧妙，依次保存组名，磁盘号，一级目录，二级目录，文件名，此处的文件名添加了其他信息生成的，原始文件名需要应用自行保存。下面是结构示例。
group1/M00/00/0C/SAAAKkdlDKDKlslDSSdks.h
尾声
FastDFS轻巧方便使用，搭建简单，但是也存在一些问题，比如上面说的刚上传文件的Storage服务如果数据损坏，则会导致数据永久丢失，Storage服务中如果有磁盘损坏，则需要手动copy数据进行还原，对于运维来说太不方便。
参考资料
http://tech.uc.cn/?p=221
http://blog.yunnotes.net/index.php/fastdfs_design/
http://history.programmer.com.cn/4380/