版權宣告：本文為博主原創文章，未經博主允許不得轉載。合作請聯絡微信 sinosuperman。 https://blog.csdn.net/Poechant/article/details/6977407
轉載請註明來自：詩商·柳驚鴻CSDN部落格，原文連結：FastDFS的配置、部署與API使用解讀（1）入門使用教程

1、背景

FastDFS是一款開源的、分散式檔案系統（Distributed File System），由淘寶開發平臺部資深架構師餘慶開發。該開源專案的主頁是 http://code.google.com/p/fastdfs 。可以通過fastdfs.sourceforge.net 下載。FastDFS論壇是

2、上傳流程

我們可以通過 FastDFS 對檔案的上傳過程，來初步瞭解 FastDFS 的基本架構。首先客戶端 client 發起對 FastDFS 的檔案傳輸動作，是通過連線到某一臺 Tracker Server 的指定埠來實現的，Tracker Server 根據目前已掌握的資訊，來決定選擇哪一臺 Storage Server ，然後將這個Storage Server 的地址等資訊返回給 client，然後 client 再通過這些資訊連線到這臺 Storage Server，將要上傳的檔案傳送到給 Storage Server上。

3、架構簡析

以上這段粗糙簡單的描述，基本理清了 FastDFS 的上傳過程。我們可以知道，FastDFS 是包括一組 Tracker Server 和 Storage Server 的。Tracker Server 與 Storage Server 之間不直接通訊，其基本的資訊由配置檔案在系統啟動載入時獲知。多臺 Tracker Server 之間保證了 Tracker 的分散式，Tracker Server 之間是對等的，防止了單點故障。 Storage Server 是分成多個 Group，每個 Group 中的Storage 都是互相備份的，也就是說，如果 Group1 有 Storage1、Storage2、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 進行傳輸的。

4、總結

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

5、三篇入門博文

FastDFS 還有一個特點，就是適用於小檔案儲存，因為 FastDFS 不回對檔案進行分塊。因為檔案比較小（比如普通級別的圖片類應用，檔案最大就在幾個MB的量級），一來沒有必要分塊，二來分塊會加重伺服器的工作量。但是，如果把 FastDFS 應用於大檔案儲存的場景，可能這一特點就會變成缺點。

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

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

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

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

轉載請註明來自：詩商·柳驚鴻CSDN部落格，原文連結：FastDFS的配置、部署與API使用解讀（1）入門使用教程