FastDFS专题】fastdfs使用实战（概念篇）

古城热线

　　出处：http://josh-persistence.iteye.com/blog/2065510
　　开源分布式文件系统FastDFS和MogileFS对比(1)http://os.运维网.com/art/201210/359861.htm
　　1、FastDFS是什么
　　FastDFS是一个开源的轻量级分布式文件系统，纯C实现，支持Linux、FreeBSD等UNIX系统，FastDFS可以看做是基于文件的key value pair存储系统。
　　FastDFS有两个角色：跟踪器(tracker)和存储节点(storage)。跟踪器主要做调度工作，在访问上起负载均衡的作用。存储节点存储文件，完成文件管理的所有功能：存储、同步和提供存取接口，同时对文件的metadata进行管理。所谓文件的meta data就是文件的相关属性，以键值对（key valuepair）方式表示，如：width=1024，其中的key为width，value为1024。文件metadata是文件属性列表，可以包含多个键值对。
　　2、FastDFS的特点
　　分组存储，灵活简洁
　　对等结构，不存在单点
　　文件ID由FastDFS生成，作为文件访问凭证。
　　FastDFS不需要传统的name server
　　和流行的web server无缝衔接，FastDFS已提供apache和nginx扩展模块
　　大、中、小文件均可以很好支持，支持海量小文件存储
　　支持相同文件内容只保存一份，节省存储空间
　　存储服务器上可以保存文件附加属性
　　支持多块磁盘，支持单盘数据恢复
　　3、FastDFS架构如下：
　　跟踪器和存储节点都可以由一台或多台服务器构成。跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。
　　为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。
　　FastDFS中的文件标识分为两个部分：卷名和文件名，二者缺一不可。
　　4、FastDFS实现过程
　　上传文件交互过程：
　　1. Client询问Tracker server上传到的Storage server；
　　2. Tracker server返回一台可用的Storage server，返回的数据为该Storage server的IP地址和端口；
　　3. Client直接和该Storage server建立连接，进行文件上传，Storage server返回新生成的文件ID，文件上传结束。
　　下载文件交互过程：
　　1. Client询问Tracker server可以下载指定文件的Storage server，参数为文件ID（包含组名和文件名）；
　　2. Tracker server返回一台可用的Storage server；
　　3. Client直接和该Storage server建立连接，完成文件下载。
　　5、同步机制
　　同一组内的storage server之间是对等的，文件上传、删除等操作可以在任意一台storage server上进行；
　　文件同步只在同组内的storage server之间进行，采用push方式，即源服务器同步给目标服务器；
　　源头数据才需要同步，备份数据不需要再次同步，否则就构成环路了；
　　上述第二条规则有个例外，就是新增加一台storage server时，由已有的一台storage server将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。
　　下面内容是整理别人的博文，对加深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 足够多，数据流量是足够分散的。
　　FastDFS 还有一个特点，就是适用于小文件存储，因为 FastDFS 不会对文件进行分块。因为文件比较小（比如普通级别的图片类应用，文件最大就在几个MB的量级），一来没有必要分块，二来分块会加重服务器的工作量。但是，如果把 FastDFS 应用于大文件存储的场景，可能这一特点就会变成缺点。