FastDFS学习--2.FastDFS系统架构和功能原理

架构详解

• storage server：存储服务器，文件和文件属性都保存在存储服务器，Storage Server直接利用OS文件系统调用管理文件
  • Storage Server以组（group）为单位，一个group包含多台storage机器，数据互相备份，存储空间取决于最小的机器，所以配置上最好配置相同，避免浪费
  • 以组为单位存储能方便应用的隔离、负载均衡、副本数量定制等
• tracker server：跟踪服务器，主要做调度工作，起负载均衡作用
  • 在内存中记录集群中所有存储组和存储服务器的状态信息，是客户端和数据服务器交互的枢纽。因为不记录文件索引信息，所以占用的内存量很少
• client：客户端
  • FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete等，以客户端库的方式提供给用户使用

设计理念

• 轻量级
  • Fast DFS服务端只有两个角色：Tracker Server和Storage Server
  • Tracker Server在内存中记录分组和Storage Server状态信息，不记录文件索引信息，占用内存少
  • Storage Server直接利用OS的文件系统存储，不对文件分块存储。与分块存储相比更加简洁高效（一般的大文件的不多，很多时候没必要分块）
  • FastDFS没有维护命名系统，客户端上传文件之后，文件ID是由Storage Server生成后返回客户端的，客户端直接拿文件ID就能查询，Fast DFS不需要维护nameserver来存储文件索引信息，所以这个也比较轻量
  • FastDFS代码量小
• 分组存储
  • 集群是有一个或多个组构成，集群存储总容量等于所有组存储容量之和，组容量等于组内最小机器的容量
  • 一个组由一台或者多台存储服务器构成，同组内的多台storage server之间是对等的互备关系。文件上传、下载等操作可在组内任一台storage server处理
  • 纵向扩容：一个组内存储服务器访问压力较大时，通过在组内增加服务器来扩充服务能力
  • 横向扩容：整个集群容量不足时，可以增加组来扩充存储容量
• 对等结构
  • FastDFS总Tracker Server和Storage Server均是可以有多台，且是对等关系，不存在单点问题
  • 存在单点问题就是像传统的1主多从结构中，Master是单点，如果Master失效，需要将Slave选出一个提升为Master，实现逻辑比较复杂

文件上传

• 文件上传流程
  

• 文件上传内部原理

  • 1.选择tracker server和group
    • 利用Nginx负载均衡从tracker server集群找到一个tracker server
    • 选group是利用tracker.conf配置文件中的store_lookup选择group的规则，默认是2
      • 0：round robin，所有的group间轮询
      • 1：specified group，指定某一个确定的group
      • 2：load balance，剩余存储空间多的group优先
  • 2.选择storage server
    • 选定group后，tracker会在group内选择一个storage server给客户端，使用store_server选择storage，默认值为0
      • 0：round robin，在group内所有的storage轮询
      • 1：the first server order by ip address，按IP排序
      • 2：the first server order by priority ，按优先级排序
  • 3.选择storage path
    • 当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录，storage server可以有多个存放文件的存储路径（可以理解为多个磁盘），store_path支持如下规则：
      • 0:Round Robin，多个存储目录间轮询
      • 2:剩余存储空间最多的优先
  • 4.生成文件名
    • 文件名是由storage server、文件创建时间、文件大小、文件crc32和一个随机数拼接，之后base64编码生成的
  • 5.返回文件id
    • 由group、存储目录、两级子目录、文件名、文件后缀拼接而成，例如之前演示返回的group1/M00/00/00/wKg4eF8qZ8aAMt5TAAIxAbCC66s414.png

文件下载

• 文件下载流程
  • 跟上传文件一样，在download_file时，客户端可以选择任意tracker server
• 客户端发送download请求给某个tracker，必须带上文件名信息，tracker从文件名中解析出文件的group、大小、创建时间等信息，然后为该请求选择一个storage用来服务读请求
• 具体选择哪个storage server取决于tracker.conf文件中的download_server配置项
  • 0:轮询方式
  • 1:哪个为源storage server就用哪个
• 由于group内的文件同步是在后台异步进行的，所以有可能出现读的时候，文件还没有同步到你读的这个storage上，为了尽量避免反问到这样的storage，会有相应的文件同步规则

文件同步

• 文件同步原理
  • 写文件时，将文件写到一个storage就认为写成功了，然后会有后台线程将文件同步到group内的其他storage server上
  • 每个storage写文件后，会记一份binlog，binlog不包含文件数据，只有文件名等元信息，这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便下次重启能接上上次的进度继续同步（进度以时间戳记录，所以要保证集群内所有的server时钟同步）
  • storage的同步进度会作为元数据的一部分 汇报到tracker上，tracker在选择storage的时候会以同步进度作为参考。

  比如一个group内有A、B、C是那个storage，A向C同步到进度为T1，B向C同步到时间戳为T2，T2>T1，tracker接收到这些同步进度信息整理，将最小的T1作为C的同步时间戳（即所有T1以前写的数据都已经同步到C上了）

• tracker选择group内可用的storage的规则
  1. 该文件上传到的源头storage
     • 源头文件都在，肯定包含这个文件，可以根据文件名获取这个
  2. 文件创建时间戳 == storage被同步到时间戳 && （当前时间 - 创建时间）> 文件同步最大时间
     • 文件创建后，认为经过最大同步时间后，肯定已经同步到其他storage了
  3. 文件创建时间 < storage被同步到的时间戳
     • 同步时间戳之前的文件确定已经同步了？？（不太理解）
  4. （当前时间 - 文件创建的时间戳）> 同步延迟阀值
     • 超过延迟阀值，认为文件肯定已经同步了

文件删除

• 文件删除与文件下载类似
  1. 客户端询问tracker server可以删除指定文件的storage server，参数为文件ID
  2. tracker server返回一台可用的storage server
  3. 客户端直接和storage server建立连接，完成文件删除
  4. 文件删除API：delete_file

断点续传

提供appender file支持，通过upload_appender_file接口完成，appender file允许在创建后，对该文件进行append操作。
实际上appender file与普通文件的存储方式是相同的，不同的是，appender file不能被合并存储到trunk file。续传涉及到的文件大小MD5不会改变。
续传流程与文件上传类似，先定位到源storage，完成完整或部分上传，再通过binlog进行同组内server文件同步

文件http访问支持

Fast DFS的tracker和storage都内置了http协议的支持，客户端可以通过http协议来下载文件，tracker在接收到请求时，通过http的redirect机制将请求重定向到文件所在的storage上。除了内置的http协议，FastDFS还提供了apache/nginx下载文件的支持。

• 具体操作可以参考上一篇中的Linux下FastDFS安装模块