FastDfs (一) 理论总结

- 日理万妓 2022-08-19 11:18 127阅读 0赞

1.  简单概述  
    FastDFS是一款类Google FS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等 UNIX系统。它只能通过专有API对文件进行存取访问，只能作为应用级的文件系统。  
    FastDFS是为互联网应用量身定做的分布式文件系统，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标。
2.  关键点  
    2.1 整个文件系统有两个角色：tracker和storage  
    tracker：负责存储文件、下载文件的调度和负载均衡。  
    storage：负责存储文件。  
    storage端会配置相应的tracker的信息，tracker端并不会配置storage的信息，因此两者之间的通信方式是storage主动向tracker报告自己的信息（作为一个良好的习惯应该首先启动tracker服务，然后再启动相应的storage服务），tracker并不会主动向storage发送任何数据或者命令，当客户端访问文件系统时，首先访问tracker，tracker会根据storage的报告返回给客户端一个可用的storage（主机和端口），然后客户端直接访问storage（上传或者下载文件）。  
    ![上传文件][20160116175422856]
    
        上传文件
    
    ![下载文件][20160116175530787]
    
        下载文件
    
    2.2 文件上传的ID（文件名）并不是由用户决定的，也就是说不管你上传的文件原来叫什么名字，  
    FastDfs会生成一个新的名字，具体来说是由storage生成的并返回给客户端。  
    文件名由group、存储目录、两级子目录、fileid、文件后缀名（由客户端指定，主要用于区分文件  
    类型）拼接而成。  
    ![这里写图片描述][20160116180054344]  
    文件名组成
    
        众所周知，linux的文件系统的存储方式（此处不表），索引节点（inode）的数量是有限的，如果存储大量的小文件，很有可能会在存储空间未用尽的前提下，由于inode用尽而不能继续存储文件，因此从3.0开始FastDfs引入了小文件合并的机制。可将多个小文件存储到一个大的文件（trunk file），为了支持这个机制，FastDFS生成的文件fileid需要额外增加16个字节。
    
    1) trunk file id  
    2) 文件在trunk file内部的offset  
    3) 文件占用的存储空间大小 （字节对齐及删除空间复用，文件占用存储空间>=文件大小）  
    每个trunk file由一个id唯一标识，trunk file由group内的trunk server负责创建（trunk server是tracker选出来的），并同步到group内其他的storage，文件存储合并存储到trunk file后，根据其offset就能从trunk file读取到文件。
    
    文件在trunk file内的offset编码到文件名，决定了其在trunk file内的位置是不能更改的，也就不能通过compact的方式回收trunk file内删除文件的空间。但当trunk file内有文件删除时，其删除的空间是可以被复用的，比如一个100KB的文件被删除，接下来存储一个99KB的文件就可以直接复用这片删除的存储空间。
3.  文件同步  
    写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage server写完文件后，会由后台线程将文件同步至同group内其他的storage server（**只有同组内的storage server会互相同步数据**）。每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有server的时钟保持同步。 **storage的同步进度会作为元数据的一部分汇报到tracker上，tracke在选择读storage的时候会以同步进度作为参考。**
    
    比如一个group内有A、B、C三个storage server，A向C同步到进度为T1 (T1以前写的文件都已经同步到B上了），B向C同步到时间戳为T2（T2 > T1)，tracker接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳为T1（即所有T1以前写的数据都已经同步到C上了）；同理，根据上述规则，tracker会为A、B生成一个同步时间戳。  
    因为不同的storage server之间需要同步数据，这就必然会产生同步延迟的问题，那访问上传到FastDfs的文件数据是，怎么样避免因同步延迟造成的访问异常呢？比如文件不存在(还未同步或者文件被访问时还未被同步完成）因为下载文件是访问的storage不一定是上传时的那台storage server。FastDfs定义了如下规则来规避同步延迟带来的访问异常：
    
        A. 当Client询问Tracker server有哪些Storage server可以下载指定文件时，Tracker server返回满 
               足如下四个条件之一的Storage server;
            B. 该文件上传到的源Storage server，文件直接上传到该服务器上的；
            C. 文件创建时间戳 < Storage server被同步到的文件时间戳，这意味着当前文件已经被同步过来
               了；
            D. 文件创建时间戳=Storage server被同步到的文件时间戳，且（当前时间—文件创建时间戳） > 
               一个文件同步完成需要的最大时间（如5分钟）；
            E.（当前时间—文件创建时间戳） > 文件同步延迟阈值，比如我们把阈值设置为1天，表示文件同步
               在一天内肯定可以完成。
4.  待续

[20160116175422856]: /images/20220731/b51f2c88cf1248efa55fe499308367e4.png
[20160116175530787]: /images/20220731/47e3a68313184725b56ed42b9778ba0b.png
[20160116180054344]: /images/20220731/1eaed6c983704cc3853d22048c81ce70.png