关于FastDFS的简单

首先阅读：https://blog.csdn.net/lanwilliam/article/details/80075727

其次了解：https://blog.csdn.net/lanwilliam/article/details/80075757

第一篇是转的FastDFS的介绍，对FastDFS总体有个了解。

第二篇是PHP语言的FastDFS的操作示例，对如何具体编码有个了解。

总得来说FastDFS就是一个便于管理的分布式文件存储系统。有tracker ，storage，client三部分组成。

Tracker可以理解为一个管理端服务器，storage就是负责存储的服务器，client就是业务调度服务器了。

client，也就是我们实际的业务系统，通过访问Tracker进行文件的读写操作。Tracker会根据配置，将受到的读写命令具体分解到对应的storage上去。换句话说，client不需要关注文件到底写在哪里，只需要把文件丢给tracker，tracker就会自动根据策略写入对应storage服务器上去，并返回写入地址给client。client可以根据写入地址读取文件。

写入地址有规则：组名/路径/文件名

这样的好处是，首先，解决了文件存储服务器的动态扩展问题。

很多业务，需要存储大量图片或各类文件。如果直接存web服务器，那么服务器磁盘满了怎么办？加磁盘？存储也存在同样问题。如果需要迁移，那么之前的图片路径都需要更新一次，存在极大风险，一个不注意，很可能图片全找不回来了（虽然文件都在，但是不认识啊！？）。那么这时候，在平台构建初期，搭设一个可扩展的文件存储就很有必要了。

DFS就是干这个的，FastDFS让这件事情更简单。

初期，你可以只使用一台Storage，甚至吧Tracker放到web server上去。并不浪费多少成本。（强烈不建议将storage放到web 上，后期签出去麻烦），但是后期用户数起来以后，你可以首先吧tracker迁移到独立服务器，然后再加一台storage。再过几年，你可以多加两台tracker和多组storage。并且你数据库中存储的图片地址不需要改。提供了良好的扩展性。

同时，由于文件是独立存储，对于磁盘IO有一定的改善。毕竟可用磁盘数多了，io效率成倍增加。

同时对于缓存优化有很大帮助。

例如通过给storage指定独立的二级域名，例如一堆的img*.xxx.com这样，对于常用页面的图片，浏览器层面就实现了缓存，甚至不会提交到服务端来。当然，对于CDN也是有用的。毕竟CDN都不会缓存带cookie的请求内容。但是我们的业务图片，往往都是需要用到session，会用到cookie。同理哪些http服务加速框架一样。 例如varnish。

当然，fastdfs只是将过去我们通过自己定义webservice实现的存储调度产品化了。原始实现：https://www.cnblogs.com/mfc-itblog/p/5232279.html

如果想要进一步优化性能，可以考虑用到zimg框架的思路。

现在第二篇文章中的php的实现中，还存在一个问题，就是浏览器提交的文件，需要先存储到web服务器上，然后再提交到fastDFS上去存储。存在两次IO。ZImg提供了一种思路，自己扩展了php的文件上传实现，拦截了图片文件，在内存中获取提交图片，直接存储到fastDFS上去，这样进一步减少了一次IO操作。对于脸书微博这类应用，性能提升应该还是很高的。当然复杂度也高。笔者这里没有实践过，仅提供思路。有需要的自行尝试吧。

总之，如果你能够遇见系统需要大量文件存储，那么在构架前期规划上FastDFS是很有必要的。