1、Fast DFS 上传交互过程
Fast DFS向使用者提供基本文件访问接口,比如upload、download、append、delete等,以客户端库的方式提供给用户使用。
![](https://i-blog.csdnimg.cn/blog_migrate/9006123c4424870bfa4e881840d166a8.jpeg)
1. client询问tracker上传到的storage,不需要附加参数;
2. tracker返回一台可用的storage,并返回storage的相关信息;
3. client直接和storage通讯完成文件上传(包括生成file ID ,存储磁盘);
4. Fast DFS file downloa
d或 者 预览
返回FILE ID文件名的格式如下:
![](https://i-blog.csdnimg.cn/blog_migrate/aae6a47255804d4fecc490a871ec4ad8.jpeg)
2、Fast DFS 下载交付过程
客户端upload file成功后,会拿到一个storage生成的文件名,接下来客户端根据这个文件名即可访问到该文件;
1. client询问tracker下载文件的storage,参数为文件标识(卷名和文件名);
2. tracker返回一台可用的storage;
3. client直接和storage通讯完成文件下载。
需要说明的是,client为使用FastDFS服务的调用方,client也应该是一台服务器,它对tracker和storage的调用均为服务器间的调用。
3、Fast DFS 同步原理
写文件时,客户端将文件写至group内一个storage server即认为写文件成功,storage server写完文件后,会由后台线程将文件同步至同group内其他的storage server。
每个storage写文件后,同时会写一份bin log,bin log里不包含文件数据,只包含文件名等元信息,这份bin log用于后台同步,storage会记录向group内其他storage同步的进度,以便重启后能接上次的进度继续同步;进度以时间戳的方式进行记录,所以最好能保证集群内所有server的时钟保持同步。
storage的同步进度会作为元数据的一部分汇报到tracker上,tracker在选择读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生成一个同步时间戳。
4、Fast DFS 特性说明
1)在上述介绍中Tracker服务器是整个系统的核心枢纽,其完成了访问调度(负载均衡),监控管理Storage服务器
,
由此可见Tracker的作用至关重要,也就增加了系统的单点故障,为此Fast DFS支持多个备用的Tracker,虽然实际测试发现备用Tracker运行不是非常完美,但还是能保证系统可用。
2)在文件同步上,只有同组的Storage才做同步,由文件所在的源Storage服务器push至其它Storage服务器,目前同步是采用Bin log方式实现,由于目前底层对同步后的文件不做正确性校验,因此这种同步方式仅适用单个集群点的局部内部网络,如果在公网上使用,肯定会出现损坏文件的情况,需要自行添加文件校验机制。
3)支持主从文件,非常适合存在关联关系的图片,在存储方式上,Fast DFS在主从文件ID上做取巧,完成了关联关系的存储
5、Fast DFS 优势、缺点、使用场景
5.1、优势
1
)系统无需支持POSIX(可移植操作系统),降低了系统的复杂度,处理效率更高
2)支持在线扩容机制,增强系统的可扩展性
3)实现了软RAID,增强系统的并发处理能力及数据容错恢复能力
4)支持主从文件,支持自定义扩展名
5)主备Tracker服务,增强系统的可用性
5.2、缺点
1)不支持断点续传,对大文件将是噩梦(Fast DFS不适合大文件存储)
2)不支持POSIX通用接口访问,通用性较低
3)对跨公网的文件同步,存在较大延迟,需要应用做相应的容错策略
4)同步机制不支持文件正确性校验,降低了系统的可用性
5)通过API下载,存在单点的性能瓶颈
5.3、使用场景
Fast DFS是一款类似Google FS的开源分布式文件系统,是纯C语言开发的。
Fast DFS是一个开源的轻量级分布式文件系统,它对文件进行管理,功能包括:文件存储、文件同步、文件访问(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务,如相册网站、视频网站等等。
6、思考
《问题分析》:
从Fast DFS的整个设计看,基本上都已简单为原则。比如以机器为单位备份数据,简化了tracker的管理工作;storage直接借助本地文件系统原样存储文件,简化了storage的管理工作;文件写单份到storage即为成功、然后后台同步,简化了写文件流程。但简单的方案能解决的问题通常也有限,Fast DFS目前尚存在如下问题:
1、数据安全性:
写一份即成功:从源storage写完文件至同步到组内其他storage的时间窗口内,一旦源storage出现故障,就可能导致用户数据丢失,而数据的丢失对存储系统来说通常是不可接受的。
缺乏自动化恢复机制:当storage的某块磁盘故障时,只能换存磁盘,然后手动恢复数据;由于按机器备份,似乎也不可能有自动化恢复机制,除非有预先准备好的热备磁盘,缺乏自动化恢复机制会增加系统运维工作。
数据恢复效率低:恢复数据时,只能从group内其他的storage读取,同时由于小文件的访问效率本身较低,按文件恢复的效率也会很低,低的恢复效率也就意味着数据处于不安全状态的时间更长。
缺乏多机房容灾支持:目前要做多机房容灾,只能额外使用工具来将数据同步到备份的集群,无自动化机制。
2、存储空间利用率:
单机存储的文件数受限于inode数量
每个文件对应一个storage本地文件系统的文件,平均每个文件会存在block_size/2的存储空间浪费。
文件合并存储能有效解决上述两个问题,但由于合并存储没有空间回收机制,删除文件的空间不保证一定能复用,也存在空间浪费的问题
3、负载均衡:
group机制本身可用来做负载均衡,但这只是一种静态的负载均衡机制,需要预先知道应用的访问特性;同时group机制也导致不可能在group之间迁移数据来做动态负载均衡