分布式存储-fastdfs

fastdfs是什么

FastDFS是一个开源的轻量级分布式文件系统。它解决了大数据量存储和负载均衡等问题。

FastDFS主要的功能包括：⽂件存储，同步和访问，设计基于⾼可⽤和负载均衡。FastDFS⾮常适⽤于基于⽂件服务的站点。

FastDFS由跟踪服务器（tracker server）、存储服务器（storage server）和客户端（client）三个部分组成，特别适合以中⼩⽂件（建议范围：4KB < file_size < 500MB）为载体的在线服务，例如图⽚分享和视频分享⽹站。
 

fastdfs 架构

Storage server：

以组（卷，group或volume）为单位组织，⼀个group内包含多台storage机器，数据互为备份，存储空间以group内容量最⼩的storage为准，建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。

优点：⽅便的进⾏应⽤数据隔离、根据应用特性负载均衡、副本数定制（group内storage server数量即为该group的副本数）；

缺点：group的容量受单机存储容量的限制，同时当group内有机器坏掉时，数据恢复只能依赖group内地其他机器，使得恢复时间会很⻓。

group内每个storage的存储依赖于本地⽂件系统，storage可配置多个数据存储⽬录，⽐如有10块磁盘，分别挂载在/data/disk1-/data/disk10，则可将这10个⽬录都配置为storage的数据存储⽬录。
storage接受到写⽂件请求时，会根据配置好的规则，选择其中⼀个存储⽬录来存储⽂件。为了避免单个⽬录下的⽂件数太多，在storage第⼀次启动时，会在每个数据存储⽬录⾥创建2级⼦⽬录，每级256个，总共65536个⽂件，新写的⽂件会以hash的⽅式被路由到其中某个⼦⽬录下，然后将⽂件数据直接作为⼀个本地⽂件存储到该⽬录中。

Tracker server

Tracker是FastDFS负责跟踪管理所有的storage 和group，每个storage在启动后会连接Tracker，告知⾃⼰所属的group等信息，并保持周期性的⼼跳，tracker根据storage的⼼跳信息，建⽴
group->[storage server list]的映射表。
Tracker需要管理的元信息很少，会全部存储在内存中；另外tracker上的元信息都是由storage汇报的信息⽣成的，本身不需要持久化任何数据，这样使得tracker⾮常容易扩展，直接增加tracker机器即可扩展为tracker cluster来服务，cluster⾥每个tracker之间是完全对等的，所有的tracker都接受stroage的⼼跳信息，⽣成元数据信息来提供读写服务

client 

FastDFS向使⽤者提供基本⽂件访问接⼝，⽐如monitor、upload、download、append、delete等，以客户端库的⽅式提供给⽤户使⽤。

fastdfs的上传文件的逻辑

 

 

客户端连接tracker：可以任选多个tracker中的一个，traker之间完全对等

traker 的工作

一、选择分配group规则：

1. Round robin，所有的group间轮询
2. Specified group，指定某⼀个确定的group
3. Load balance，选择最⼤剩余空 间的组上传⽂件
二、选择分配storage的规则
1. Round robin，在group内的所有storage间轮询
2. First server ordered by ip，按ip排序
3. First server ordered by priority，按优先级排序（优先级在storage上配置）

三、选择storage path规则

分配数据存储目录，遵循以下的原则

1. Round robin，多个存储⽬录间轮询
2. 剩余存储空间最多的优先
四、生成field

选定存储⽬录之后，storage会为⽂件⽣⼀个Fileid，由：storage server ip、⽂件创建时间、⽂件⼤⼩、⽂件crc32和⼀个随机数拼接⽽成，然后将这个⼆进制串进⾏base64编码，转换为可打印的字符串。

五、生成子目录

根据field进行hash，路由到对应的子目录，然后文件以field文件名存储到子目录。

六、⽣成⽂件名
当⽂件存储到某个⼦⽬录后，即认为该⽂件存储成功，接下来会为该⽂件⽣成⼀个⽂件名，⽂件名由：group、存储⽬录、两级⼦⽬录、fileid、⽂件后缀名（由客户端指定，主要⽤于区分⽂件类型）拼接⽽成。

fastdfs的下载文件的逻辑

 

tracke从⽂件名中解析出⽂件的group、⼤⼩、创建时间等信息，然后为该请求选择⼀个storage⽤来服务读请求。group内的storage的同步时弱一致性，为避免访问到未同步storage，规则如下

 1. 该⽂件上传到的源头storage - 源头storage只要存活着，肯定包含这个⽂件，源头的地址被编码在⽂件名中。
2. ⽂件创建时间戳==storage被同步到的时间戳 且(当前时间-⽂件创建时间戳) > ⽂件同步最⼤时间（如5分钟) - ⽂件创建后，认为经过最⼤同步时间后，肯定已经同步到其他storage了。
3. ⽂件创建时间戳 < storage被同步到的时间戳。 - 同步时间戳之前的⽂件确定已经同步了
4. (当前时间-⽂件创建时间戳) > 同步延迟阀值（如⼀天）。 - 经过同步延迟阈值时间，认为⽂件肯定已经同步了