分布式文件系统FastDFS实践

最近，需要为业务团队提供图片及文件存储服务，早前，接触过的一些存储方案大概有：利用Linux系统级别的NFS文件服务，即在NFS Server和NFS Client之间进行文件同步，但NFS不太容易实现集群，从而避免单点问题，而且维护起来也比较麻烦，需要同步在接收上传的机器上建立NFS Client；也有利用Nginx+Lua+ImageMagick的方案，但在文件备份等需要借助一些其他手段才能达到。当然也有一些专门的分布式文件系统，如HDFS，GlusterFS等，但主要是针对大文件存储。最近接触到一个轻量的分布式文件系统--FastDFS，是由国人开发，比较遗憾的是关于FastDFS的文档都比较零散，在这个站点上要稍微集中一些。本文将对FastDFS进行一番探究实践。

FastDFS特性

FastDFS是一款类Google FS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等UNIX系统。它只能通过专有API对文件进行存取访问，不支持POSIX接口方式，不能mount使用。准确地讲，Google FS以及FastDFS、MogileFS、HDFS、TFS等类Google FS都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。

轻量级设计

FastDFS中只有两个角色：Tracker和Storage。Tracker作为中心结点，其主要作用是维护Storage信息，负载均衡和调度等。Tracker会在内存和临时文件中记录Storage分组和Storage的状态等信息，不记录文件索引信息，占用的内存量很少。而重要的文件索引信息将附属在Storage生成的文件ID中，这无疑去掉文件索引这一步，也提高了文件检索的性能。

分组存储

FastDFS采用了分组存储方式来保存文件的多个备份。存储集群由一个或多个逻辑组构成，集群存储总容量为集群中所有组的存储容量(一个存储组的容量由该组中容量最小的Storage决定)之和。一个组由一台或多台Storage组成，同组内的多台Storage之间是互备关系，同组内的存储服务器上的文件是完全一致的。文件上传、下载、删除等操作可以在组内任意一台Storage上进行。

节点对等

FastDFS集群中的Tracker也可以有多台，Tracker和Storage均不存在单点问题。Tracker之间是对等关系，存储组内的Storage之间也是对等关系。传统的Master-Slave架构中的Master是单点，写操作仅针对Master。如果Master失效，需要将Slave提升为Master，实现逻辑会比较复杂。和Master-Slave架构相比，对等结构中所有结点的地位是相同的，每个结点都是Master，不存在单点问题。