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

原文链接：http://blog.csdn.net/poechant/article/details/6977407

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