在介绍本文之前，我向大家介绍下一个非常棒的分布式文件系统fastdfs，关于她的具体介绍和优点我不做详细介绍了，有关资料可以访问：
http://linux.chinaunix.net/bbs/forum-75-1.html 。
web2.0海量小文件的存储是所有系统架构师必须要面对的一个问题。
这几天一直在忙着给公司部署分布式文件系统。也看了几个大型公司的分布式文件系统的架构：flicker，taobao，拍拍网。深入理解各自应用的场景，弄明白了很多个为什么之后，自己将要为公司部署的分布式文件系统架构也慢慢浮出水面了。
架构随着业务发展而逐步改变的，比如类似淘宝这样的访问量，可能需要cdn来加速静态资源(js,css)和用户上传的业务相关的图片而一般访问量不是特别大的网站可以不用部署cdn，原因肯定很多，硬件成本和维护成本等等。
那么接下来我就分别介绍部署cdn的分布式文件系统架构和普通分布式文件系统架构。
（一）部署cdn的分布式文件系统架构：
涉及到的技术：lvs，haproxy（或nagix），squid，nagix（或apache），fastdfs。
有图有真相，先画个图。
接下来我对每层设置的意义进行解释下。
lvs7层代理：主要通过ip来找到自己合适的下层服务器。
haproxy或nginx4层代理：主要通过url hash找到合适的一台squid。最主要功能就是为了提高squid缓存的命中率。
squid集群：缓存所有用户访问的对象。
文件服务器集群：1、tracker服务器，主要管理文件存储的源storage等一些信息。 2、storage服务器就是实际文件的存储位置。最近fishman（fastdfs的作者）开发了一个apache module解决了延迟问题，那么我们可以不用启用tracker内嵌的服务器来跳转了，直接把http服务器配置在storage服务器上。给我们带来了很多方便。
（二）普通分布式文件系统架构：
（图片引自：
http://linux.chinaunix.net/bbs/thread-1062461-1-1.html）
这个架构没有涉及到cdn的部署，相比起来应该更容易理解了。对于tracker和storage的作用类似于在部署cdn的分布式文件系统架构部分介绍的一样。其中client我觉得有必要要解释下，这里的client有两层含义：1、相对于tracker和storage服务器来说，client是访问这些服务器的客户端。 2、应用程序的服务端。实际开发中，我们可以部署一台图片上传服务器来作为应用程序的服务端，也可以把图片上传服务直接写到应用程序中。
两种架构都是基于fastdfs分布式文件系统。所以你们了解fastdfs软件本身之后再看这篇文章也许会更有益。