在介紹本文之前，我向大家介紹下一個非常棒的分布式文件系統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軟件本身之后再看這篇文章也許會更有益。