FastDFS的配置、部署与API使用解读（1）Get Started with FastDFS

1、背景

FastDFS是一款开源的、分布式文件系统（Distributed File System），由淘宝开发平台部资深架构师余庆开发。该开源项目的主页是http://code.google.com/p/fastdfs 。可以通过fastdfs.sourceforge.net 下载。FastDFS论坛是 http://www.csource.org ，目前是指向 ChinaUnix 开源项目孵化平台的一个板块 FastDFS，网址为 bbs.chinaunix.net/forum-240-1.html 。

2、上传流程

我们可以通过FastDFS对文件的上传过程，来初步了解FastDFS的基本架构。首先客户端client发起对FastDFS的文件传输操作，是通过连接到某一台Tracker Server的指定端口来实现的，Tracker Server根据目前已掌握的信息，来决定选择哪一台Storage Server，然后将这个Storage Server的地址等信息返回给client，然后client再通过这些信息连接到这台Storage Server，将要上传的文件传送到给Storage Server上。

3、架构简析

以上这段粗糙简单的描述，基本理清了FastDFS的上传过程。我们可以知道，FastDFS是包括一组Tracker Server 和Storage Server的。Tracker Server与Storage Server之间不直接通信，其基本的信息由配置文件在系统启动加载时获知。多台Tracker Server之间保证了Tracker的分布式，Tracker Server之间是对等的，防止了单点故障。Storage Server是分成了多个Group，每个Group中的Storage都是互相备份的，也就是说，如果Group1有Storage1、Storage2、Storage3，其容量分别是100GB、100GB、100GB，那么Group1的存储能力是100GB，而不是300GB，这就是互相备份的意思。进一步说，整个Group的存储能力由该组中存储能力最小的Storage决定。多个Group之间的存储方式，可以采用round robin（轮训）、load balanced（负载均衡）或指定Group的方式。另一点相对于MS（Master-Slave）模式的优势，就是Tracker Server与Master是决然不同的，不仅master有上面可能提到的单点故障问题，而且client与master之间可能会出现瓶颈。但FastDFS架构中，Tracker Server不会成为系统瓶颈，数据最终是与一个available的Storage Server进行传输的。

4、总结

 简单总结一下，FastDFS的特点包括（1）高可靠性：无单点故障；（2）高吞吐量：只要Group足够多，数据流量是足够分散的。

5、三篇入门博文

FastDFS还有一个特点，就是适用于小文件存储，因为FastDFS不会对文件进行分块。因为文件比较小（比如普通级别的图片类应用，文件最大就在几个MB的量级），一来没有必要分块，二来分块会加重服务器的工作量。但是，如果把FastDFS应用于大文件存储的场景，可能这一特点就会变成缺点。

以下这三篇是ITeye的一位博友关于 FastDFS 的部署、配置与测试的博文，写得简明扼要，我就不再冗余地写一篇了。

部署篇：http://soartju.iteye.com/blog/803477

配置篇：http://soartju.iteye.com/blog/803524

测试篇：http://soartju.iteye.com/blog/803548