当前位置:   article > 正文

FastDFS学习--2.FastDFS系统架构和功能原理_fastdfs 1主2从的

fastdfs 1主2从的

架构详解

在这里插入图片描述

  • 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安装模块
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小蓝xlanll/article/detail/170060
推荐阅读
相关标签
  

闽ICP备14008679号