FastDFS介绍及架构流程

FastDFS

介绍

• 技术论坛：http://bbs.chinaunix.net/forum-240-1.html
• FAQ：http://bbs.chinaunix.net/thread-1920470-1-1.html
• 资源地址：https://sourceforge.net/projects/fastdfs/
• 源码资源：https://github.com/happyfish100

FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理。功能包括：文件存储、文件同步、文件访问(文件上传、文件下载)等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等。

FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

FastDFS服务端有两个角色：跟踪器(tracker)和存储节点(storage)：

• 跟踪器(tracker)主要做调度工作，在访问上起负载均衡的作用。
• 存储节点(storage)存储文件，完成文件管理的所有功能。

就是这样的存储、同步和提供存取接口，FastDFS同时对文件的metadata进行管理。所谓文件的metadata就是文件的相关属性(元数据)，以键值对(key value)方式表示，如：width=1024，其中key为width，value为1024。文件metadata是文件属性列表，可以包含多个键值对。

跟踪器和存储节点都可以由一台或多台服务器构成。跟踪器和存储节点中的服务器均可以随时增加或下线而不会影响线上服务。其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。

为了支持大容量，存储节点(storage)采用了分卷(或分组)的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。
一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。

在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。

当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。

FastDFS中的文件标识分为两部分：卷名和文件名，二者缺一不可。

架构

• Track server：

  • 主节点，跟踪服务器，主要做调度工作，在访问上起负载均衡的作用。
  • 记录storage server 的状态，是连接Client 和 Storage server 的枢纽。
  • FastDFS集群中的Tracker server可以有多台，Tracker server之间是相互平等关系同时提供服务。
  • Tracker server不存在单点故障。客户端请求Tracker server采用轮询方式，如果请求的Tracker无法提供服务，则换另一个Tracker。

• Storage Server:

  • 存储服务器，文件和metadata都保存到存储服务器上。
  • storage集群由一个或多个组构成，集群存储总容量为集群中所有组的存储容量之和。
  • 一个组由一台或多台存储服务器组成，组内storage server之间是平等关系。
  • 不同组的storage server之间不会相互通信，同组内的storage server之间会相互连接进行文件同步，从而保证同组内每个storage上的文件完全一致。
  • 一个组的存储容量为该组内存储服务器容量最小的那个，由此可见组内存储服务器的软硬件配置最好是一致的。（在有多个同组的情况下）
  • storage server会连接集群中所有的Tracker server，定时向他们报告自己的状态，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。

• group：组，也称为卷。同组内服务器上的文件是完全相同的。

• 文件标识：包括两部分：组名和文件名(包含路径)

• metadata：(元数据)，文件相关属性，键值对(Key Value Pair)方式，如：width=1024，height=768

上传流程

• client询问Tracker上传到的storage，不需要附加参数；
• Tracker返回一台可用的storage；
• client直接和storage通讯完成文件上传。(client直接和Tracker返回的storage打交道，上传文件过程不再与Tracker交互)。

内部机制如下：

1. 当集群中不止一个Tracker server时，由于Tracker之间是完全对等的关系，客户端在upload文件时可以任意选择一个Tracker。选择存储的group，当Tracker接收到upload file的请求时，会为该文件分配一个可以存储该文件的group，支持如下选择的group的规则：
   1. Round robin，所有的group间轮询。
   2. Specified group，指定某一个确定的group。
   3. Load balance，剩余存储空间多group优先。
2. 选择storage server。当选定group后，Tracker会在group内选择一个storage server给客户端，支持如下选择storage的规则：
   1. Round robin，在group内的所有storage间轮询。
   2. First server ordered by ip，按ip排序。
   3. First server ordered by priority，按优先级排序(优先级在storage上配置)。
3. 选择storage path。当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录，支持如下规则：
   1. Round robin，多个存储目录间轮询。
   2. 剩余存储空间最多的优先。
4. 生成Fileid。选定存储目录之后，storage会为文件生成一个Fileid，由storage server ip、文件创建时间、文件大小、文件crc32和一个随机数拼接而成，然后将这个二进制串进行base64编码，转换为可打印的字符串。选择两级目录，当选定存储目录之后，storage会为文件分配一个fileid，每个存储目录下有两级256*256的子目录，storage会按文件fileid进行两次hash(猜测)，路由到其中一个子目录，然后局将文件以fileid为文件名存储到该子目录下。
5. 生成文件名。当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名，文件名由group、存储目录、两级子目录、fileid、文件后缀名(由客户端指定，主要用于区分文件类型)拼接而成。

下载流程

• client询问Tracker下载文件的storage，参数为文件标识(组名和文件名)；
• Tracker返回一台可用的storage；
• client直接和storage通讯完成文件下载。

binlog

每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步。storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有server的时钟保持同步。

FastDFS和其他文件存储的简单对比

指标	FastDFS	NFS	集中存储设置 如NetApp** 、 NAS**
线性扩容性	高	差	差
文件高并发访问性能	高	差	一般
文件访问方式	专有API	POSIX	支持POSIX
硬件成本	较低	中等	高

指标	FastDFS	mogileFS
系统简洁性	简洁，只有两个角色：Tracker和storage	一般有三个角色：Tracker、storage和存储文件信息的mysql db
系统性能	很高，没有使用数据库，文件同步直接点对点，不经过tracker中转	高（使用mysql来存储文件索引等信息，文件同步通过tracker调度和中转）
系统稳定性	高（C语言开发，可以支持高并发和高负载）	一般（Perl语言开发，高并发和高负载支持一般）
软RAID方式	分组（组内冗余），灵活性较大	动态冗余，灵活性一般
通信协议	专有协议 下载文件支持HTTP	HTTP
技术文档	较详细	较少
文件附加属性(metadata)	支持	不支持
相同内容文件保存一份	支持	不支持
下载文件时支持文件偏移量	支持	不支持
相同内容文件只保存一份	支持	不支持

Fastdfs的安装使用请看另一篇文章FastDFS单机安装及Java API