FastDFS的配置、部署與API使用解讀 （1）

一、背景

FastDFS是一款開源的、分佈式文件系統（Distributed File System），由淘寶開發平臺部資深架構師餘慶開發。該開源項目的主頁是 http://code.google.com/p/fastdfs 。能夠經過fastdfs.sourceforge.net 下載。FastDFS論壇是 http://www.csource.org ，目前是指向 ChinaUnix 開源項目孵化平臺的一個板塊 FastDFS，網址爲 bbs.chinaunix.net/forum-240-1.html 。

二、上傳流程

咱們能夠經過 FastDFS 對文件的上傳過程，來初步瞭解 FastDFS 的基本架構。首先客戶端 client 發起對 FastDFS 的文件傳輸動做，是經過鏈接到某一臺 Tracker Server 的指定端口來實現的，Tracker Server 根據目前已掌握的信息，來決定選擇哪一臺 Storage Server ，而後將這個Storage Server 的地址等信息返回給 client，而後 client 再經過這些信息鏈接到這臺 Storage Server，將要上傳的文件傳送到給 Storage Server上。

三、架構簡析

以上這段粗糙簡單的描述，基本理清了 FastDFS 的上傳過程。咱們能夠知道，FastDFS 是包括一組 Tracker Server 和 Storage Server 的。Tracker Server 與 Storage Server 之間不直接通訊，其基本的信息由配置文件在系統啓動加載時獲知。多臺 Tracker Server 之間保證了 Tracker 的分佈式，Tracker Server 之間是對等的，防止了單點故障。 Storage Server 是分紅多個 Group，每一個 Group 中的Storage 都是互相備份的，也就是說，若是 Group1 有 Storage一、Storage二、Storage3，其容量分別是100GB、100GB、100GB，那麼 Group1 的存儲能力是 100GB，而不是 300GB，這就是互相備份的意思。進一步說，整個 Group 的存儲能力由該組中該儲能力最小的 Storage 決定。多個 Group 之間的存儲方式，能夠採用 round robin（輪訓）、load balanced（負載均衡）或指定 Group 的方式。另外一點相對於MS（Master-Slave）模式的優點，就是 Tracker Server 與 Master 是決然不一樣的，不只 master 有上面可能提到的單點故障問題，並且 client 與 master 之間可能會出現瓶頸。但 FastDFS 架構中，Tracker Server 不會稱爲系統瓶頸，數據最終是與一個 available 的 Storage Server 進行傳輸的。

四、總結

簡單總結一下，FastDFS的特色包括（1）高可靠性：無單點故障；（2）高吞吐量：只要 Group 足夠多，數據流量是足夠分散的。

五、三篇入門博文

FastDFS 還有一個特色，就是適用於小文件存儲，由於 FastDFS 不回對文件進行分塊。由於文件比較小（好比普通級別的圖片類應用，文件最大就在幾個MB的量級），一來沒有必要分塊，二來分塊會加劇服務器的工做量。可是，若是把 FastDFS 應用於大文件存儲的場景，可能這一特色就會變成缺點。

如下這三篇是ITeye的一位博友關於 FastDFS 的部署、配置與測試的博文，寫得簡明扼要，我就再也不冗餘地寫一篇了。

部署篇：http://soartju.iteye.com/blog/803477

配置篇：http://soartju.iteye.com/blog/803524

測試篇：http://soartju.iteye.com/blog/803548