FastDFS分布式文件系统概述

FastDFS分布式文件系统概述

• 一、概述

  • FastDFS是一个轻量级的开源分布式文件系统
  • FastDFS主要解决了大容量的文件存储和高并发访问的问题，文件存取时实现了负载均衡
  • FastDFS实现了软件方式的RAID(冗余独立磁盘阵列)，可以使用廉价的IDE硬盘进行存储
  • 支持存储服务器在线扩容
  • 支持相同内容的文件只保存一份，节约磁盘空间
  • FastDFS只能通过Client API访问，不支持POSIX访问方式
  • FastDFS特别适合大中型网站使用，用来存储资源文件（如：图片、文档、音频、视频等等）

• 二、FastDFS与集中存储方案的对比

• 三、FastDFS架构原理

  • 1、客户端（Client)
    • 客户端指的是访问FastDFS分布式存储的客户端设备，通常是应用服务器
  • 2、访问服务器（TrackerServer)
    • 2.1、TrackerServer是访问（或者翻译为跟踪）服务器，是Client访问StorageServer的入口。
      TrackerServer起到几个作用:
      • 【服务注册】管理StorageServer存储集群，StorageServer启动时，会把自己注册到TrackerServer上，并且定期报告自身状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息
      • 【服务发现】Client访问StorageServer之前，必须先访问TrackerServer，动态获取到StorageServer的连接信息存储服务器（StorageServer)
    • 2.2、TrackerServer高可用
      • 为了保证高可用，一个FastDFS集群当中可以有多个TrackerServer节点，由集群自动选举一个leader节点。
  • 3、存储服务器（StorageServer）
    • 3.1、StorageServer是数据存储服务器，文件和meta data都保存到存储服务器上。
      • 可采用高可用的方式进行数据存储
      • FastDFS集群当中StorageServer按组(Group/volume)提供服务，不同组的StorageServer之间不会相互通信，同组内的StorageServer之间会相互连接进行文件同步
      • Storage server采用binlog文件记录文件上传、删除等更新操作。binlog中只记录文件名，不记录文件内容
      • 文件同步只在同组内的Storage server之间进行，采用push方式，即源头服务器同步给目标服务器
        

• 四、FastDFS文件上传原理

  • 原理图
    

    • 1.client询问tracker可以上传到哪一个storage,或者指定获取某个组的storage
    • 2.tracker返回一台可用的storage
    • 3.client直接和storage通讯完成文件上传
    • 4.storage保存文件以后给client返回组名(volume)和文件名称

  • 文件上传服务端内部处理的详细机制

    • 1.选择tracker
      • 当集群中有多个tracker时，由于tracker之间是完全对等的关系，因此客户端在upload文件时可以任意选择一个trakcer
    • 2.选择group
      • 当客户端没有指定group时，由服务端tracker自动指定。当tracker接收到upload file的请求时，会为该文件分配一个可以存储该文件的group，支持如下选择group的规则：
        • 1. Round robin，所有的group间轮询
        • 2. Specified group，指定某一个确定的group
        • 3. Load balance，剩余存储空间多多group优先
    • 3.选择storage
      • 当选定group后，tracker会在group内选择一个storage节点给客户端，支持如下选择storage的规则：
        • 1. Round robin，在group内的所有storage间轮询
        • 2. First server ordered by ip，按ip排序
        • 3. First server ordered by priority，按优先级排序（优先级在storage上配置）
    • 4.选择storage path
    • 当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录，支持如下规则：
      • 1. Round robin，多个存储目录间轮询
      • 2. 剩余存储空间最多的优先
    • 5.生成Fileid
      • 选定存储目录之后，storage会为文件生一个Fileid:
        • 1. storage server ip（32位整数）
        • 2. 文件创建时间（unix时间戳，32位整数）
        • 3. 文件大小
        • 4. 文件crc32校验码
        • 5. 随机数（这个字段用来避免文件重名）
      • Fileid由上述部分拼接而成，然后将这个二进制串进行base64编码，转换为可打印的字符串
    • 6.选择文件子目录
      • 当选定存储目录之后，storage会为文件分配一个fileid，每个存储目录下有两级256*256的子目录，storage会按文件fileid进行两次hash，路由到其中一个子目录，然后将文件以fileid为文件名存储到该子目录下
    • 7.生成文件名返回客户端
      • 当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名返回客户端，文件名由下述几个部分构成
        文件名：/group1/M00/00/16/rBiX52LCP9eAc03PAAV5vXZGKJI59.docx
        • 1. group name-文件上传后所在的存储组名称
        • 2. 存储目录 - 存储服务器配置的虚拟路径，与磁盘选项store_path*对应。如果配置了store_path0则是M00，如果配置了store_path1则是M01，以此类推
        • 3. 数据两级目录 - 存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件
        • 4. fileid
        • 5. 文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成
      • 生成的文件名需返回到客户端，需要由客户端进行保存。

• FastDFS文件下载原理

  • 原理图
    

    • 1.client询问tracker下载文件的storage，参数为文件标识（组名和文件名）
    • 2.tracker返回一台可用的storage
    • 3.client直接和storage通讯完成文件下载

  • 由于storage有多个存储节点，存储节点间的文件同步是在后台异步进行的，所以有可能出现在读的时候，文件还没有同步到某些storage server上，为了尽量避免访问到这样的storage，tracker按照如下规则选择group内可读的storage：

    • 1.该文件上传到的源storage - 由于源头的地址被编码在文件名中，只要源头storage存活，优先返回
    • 2.文件创建时间戳==storage被同步到的时间戳 且(当前时间-文件创建时间戳) > 文件同步最大时间（如5分钟) - 文件创建后，认为经过最大同步时间后，肯定已经同步到其他storage了
    • 3.文件创建时间戳 < storage被同步到的时间戳。 - 同步时间戳之前的文件确定已经同步了
    • 4.(当前时间-文件创建时间戳) > 同步延迟阀值（如一天）。 - 经过同步延迟阈值时间，认为文件肯定已经同步了

• FastDFS文件同步原理

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

• FastDFS文件目录

  • TrackerServer
    

  • StorageServer