0%

Programmatic-FastDFS

FastDfs介绍

  • FastDFS是由国人余庆所开发,其项目地址:FastDFS。FastDfs是一个轻量级的开源分布式文件系统,主要解决了大容量的文件存储和高并发访问的问题,文件存取时实现了负载均衡。文件存取时实现了负载均衡FastDFS实现了软件方式的RAID,可以使用廉价的IDE硬盘进行存储支持存储服务器在线扩容支持相同内容的文件只保存一份,节约磁盘空间。

  • FastDFS只能通过Client API访问,不支持POSIX访问方式。

  • FastDFS特别适合大中型网站使用,用来存储资源文件(如:图片、文档、音频、视频等等)。

  • 它用纯C语言实现,支持Linux、FreeBSD、AIX等UNIX系统。它只能通过专有API对文件进行存取访问,不支持POSIX接口方式,不能mount使用。准确地讲,Google FS、HDFS、TFS(这三个都是底层上的实现,在文件系统上处理的是数据块)以及FastDFS、mogileFS(这两个是文件级上的实现,处理的是文件)等类Google FS都不是系统级的分布式文件系统,而是应用级的分布式文件存储服务。

  • 特性

    • 1、分组存储,灵活简洁、对等结构,不存在单点。
      2、文件ID由FastDFS生成,作为文件访问凭证。FastDFS不需要传统的name server(去重机制在服务端,导致不能达到秒传。)。
      3、和流行的web server无缝衔接,FastDFS已提供apache和nginx扩展模块。
      4、大、中、小文件均可以很好支持,支持海量小文件存储(实际上不建议存储超大文件(大于500M))。
      5、支持多块磁盘,支持单盘数据恢复(理论上,实际出现Storage合并丢操作失数据)。
      6、支持相同文件内容只保存一份,节省存储空间。
      7、存储服务器上可以保存文件附加属性。
      8、下载文件支持多线程方式,支持断点续传。
      

系统架构

架构示意图

  • fastdfs架构图

架构角色

  • Tracker和Storage两个角色,其中绝大多数功能都是在Storage中实现,包括网络处理、文件上传、下载、同步、磁盘恢复等众多功能
  • Tracker cluster中各个tracker server相互独立,不进行相互通信。
  • Storage cluster中各个storage组(Volume1,Volume2…)相互独立,不进行相互通信,也就是说各个组之间保存的数据是不相同的。但是各个组中的storage server之间是属于互相备份的关系,也就是说storage server之间保存相同的数据。
  • 每个storage server会启动一个单独的线程主动向Tracker cluster中每个tracker server报告其状态信息,包括磁盘使用情况,文件同步情况及文件上传下载次数统计等信息。

上传文件流程图

  • 上传流程描述
    1. client询问tracker上传到的storage,不需要附加参数。
    2. tracker返回一台可用的storage。
    3. client直接和storage通讯完成文件上传。
    4. 上传完成,Storage server返回Client一个文件ID,文件上传结束。

下载文件流程图

  • 下载流程描述
    1. client询问tracker下载文件的storage,参数为文件标识(组名和文件名)。
    2. tracker返回一台可用的storage。
    3. client直接和storage通讯完成文件下载。

相关术语

  • Tracker Server:跟踪服务器,主要做调度工作,在访问上起负载均衡的作用。记录storage server的状态,是连接Client和Storage server的枢纽。
  • Storage Server:存储服务器,文件和meta data都保存到存储服务器上。
  • client 客户端:业务请求发起方,通过专用接口基于TCP协议与tracker以及storage server进行交互 。
  • group:组,也可称为卷。同组内服务器上的文件是完全相同的 文件标识:包括两部分:组名和文件名(包含路径) 。
  • meta data:文件相关属性,键值对(Key Value Pair)方式,如:width=1024,heigth=768。
  • fid:文件标识。

同步机制

  • 同一组内的storage server之间是对等的,文件上传、删除等操作可以在任意一台storage server上进行。
  • 文件同步只在同组内的storage server之间进行,采用push方式,即源服务器同步给目标服务器。
  • 源头数据才需要同步,备份数据不需要再次同步,否则就构成环路了。
  • 上述第二条规则有个例外,就是新增加一台storage server时,由已有的一台storage server将已有的所有数据(包括源头数据和备份数据)同步给该新增服务器。

去重机制

  • Hash
    • 去重机制也就是hash了,一个是自己实现的hash,另外一个是MD5。
  • MD5
    • 需安装FastDHT(分布式哈希系统 ):使用 Berkeley DB 做数据存储,使用 libevent 做网络IO处理,提供 Java 版的客户端接口包。适合用来存储用户在线、会话等小数据量信息。
      通过hash->文件路径来标识文件,后面上传的文件,如果已经存在相同内容的文件,则采用符号连接的方式,指向原始文件。
  • 缺陷
    • FastDFS采用服务端去重的机制,相比网盘的秒传机制效率低。

通信协议

  • 协议包由两部分组成:header和body

  • header共10字节,格式如下:

    • 8 byte body length
    • 1 byte command
    • 1 byte status
  • body数据包格式由取决于具体的命令,body可以为空

  • FDFS协议头

    • 描述 名称 长度
      报文内容 contentLength 1-7位
      报文类型 cmd 8位
      处理状态 status 9位

报文cmd(类型)参照表

常量 描述
82 客户端关闭连接命令
111 连接状态检查命令
100 服务端正确返回报文状态
91
92
93 获取文件源服务器
101
102
103
104
105
106
107
11 上传文件
12 删除文件
13 设置文件元数据
14 下载文件
15 获取文件元数据
21
22 获取文件信息
23 创建一个支持断点续传的文件
24 对文件断点续传(附加在原来为上传完全的文件后面)
34 修改支持断点续传的文件
36 清空支持断点的文件

协议异常(状态码)参照表

常量 描述
0 成功
2 找不到节点或文件
5 服务端发生io异常
16 服务端忙
22 无效的参数
28 没有足够的存储空间
61 服务端拒绝连接
114 文件已经存在?

状态码待续。。。