FastDFS分布式系统文件下载及其他相关内容

文章来源于刘小绪记录的刘欣大神课堂笔记

下面是FastDFS下载文件的时序图,首先由client发送下载连接请求,请求的东西本质上就是Group1/M00/00/0C/wKjGgVgbV2-ABdo-AAAAHw.jpg(见上篇文章);tracker将查询到的可用storage server(按下文的四个原则进行选择)的ip和端口发送给client;现在client有本地保存的文件信息,也有服务器的地址和端口,那么直接访问对应的服务器下载文件即可。

如何选择一个可供下载的storage server

共下面四个原则,从上到小条件越来越宽松

该文件上传到的源storage(文件直接上传到该服务器上)

文件创建时间戳

文件创建时间戳 = storage被同步到的文件时间戳,并且(当前时间-文件创建时间戳)> 一个文件同步完场需要的最大时间(5分钟)

(当前时间 - 文件创建时间)> 文件同步延迟阀值,比如我们把阀值设置为1天,表示文件同步在一天内肯定可以完成

FastDFS的使用

用户通过浏览器或者手机端访问web服务器,web服务器把请求转发给应用服务器,应用服务器收到请求后,通过fastDFS API和FastDFS文件系统进行交互。但是这么设计会造成应用服务器的压力,因为上传和下载都经过应用服务器。

为了避免应用服务器压力过大,可以让客户端直接使用Http访问,不通过应用服务器。

FastDFS其他内容

防止盗链

为了防止辛辛苦苦上传的文件被别人盗去,可以通过给URL设置token来解决。FastDFS的防止盗链配置如下:

#是否做tokrn检查,缺省值为false

http.anti_steal.check_token=true

#生成token的有效时长/秒

http.anti_steal.token_ttl=900

#生成token的密钥,尽量设置长一些

http.anti_steal.secret_key=@#$%*+*&!~

FastDFS生成token策略为:token = md5(文件名,密钥,时间戳)

合并存储

海量小文件的缺点

元数据管理低效,磁盘文件系统中,目录项、索引节点(inode)和数据(data)保存在介质不同的位置上

数据存储分散

磁盘的大量随机访问降低效率(小文件有可能这个在这个磁道,那个在那个磁道,就会造成大量的随机访问,大量小文件对I/O是非常不友好的)

FastDFS提供的合并存储功能

默认大文件64M

每个文件空间称为slot(256bytes

也就是说对于小文件,FastDFS会采用把多个小文件合并为一个大文件的方式来存储,默认建一个大小为64M的大文件,然后再分成多个槽,最小的槽是256bytes,因此如果一个文件小于256bytes,那么它也会占256bytes的大小。就好像我们在医院见到的中药柜子一样,每个抽屉里面再分成多个小格子,根据药材包的大小来选择不同大小的格子。

没有合并时的文件ID

合并时的文件ID

此处不再深入探讨存储合并的机制,因为它带来了一系列新的问题,比如同步时不仅需要记录大文件的名称,还需要进入小文件的名称,一下子变得麻烦多了;原来空闲空间管理直接通过操作系统就能计算出来,但是现在不行了,因为是创建了一个64M的块,这个块里面还有空闲空间,计算起来就很麻烦了。

总结

FastDFS是穷人的解决方案

FastDFS把简洁和高效做到了极致,非常节约资源,中小型网站完全用得起

——————END——————

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180308G1EZ2S00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励