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——————