01_FastDFS分散式檔案系統

實際開發中的問題

在實際專案開發中我們一般希望檔案系統能幫我們解決以下問題，如：1.超大資料儲存；2.資料高可用（冗餘備份）；3.讀/寫高效能；4.海量資料計算。最好還得支援多平臺多語言，支援高併發。

由於單臺伺服器無法滿足以上要求，這就迫使開發者不得不考慮使用其他方式解決此類問題。分散式檔案系統就在這樣迫切的需求下孕育而生。

什麼是FastDFS

FastDFS是一個開源的輕量級分散式檔案系統。它解決了大資料量儲存和負載均衡等問題。特別適合以中小檔案（建議範圍：4KB < file_size <500MB）為載體的線上服務，如相簿網站、視訊網站等等。在UC上就有基於FastDFS開發向使用者提供了：網盤，社群，廣告和應用下載等業務的儲存服務。

FastDFS架構

FastDFS服務端有三個角色：跟蹤伺服器（tracker server）、儲存伺服器（storage server）和客戶端（client）

• tracker server：跟蹤伺服器，主要做排程工作，起負載均衡的作用。在記憶體中記錄叢集中所有儲存組和儲存伺服器的狀態資訊，是客戶端和資料伺服器互動的樞紐。相比GFS中的master更為精簡，不記錄檔案索引資訊，佔用的記憶體量很少。

• storage server：儲存伺服器（又稱：儲存節點或資料伺服器），檔案和檔案屬性（meta data）都儲存到儲存伺服器上。Storage server直接利用OS的檔案系統呼叫管理檔案。

• client：客戶端，作為業務請求的發起方，通過專有介面，使用TCP/IP協議與跟蹤器伺服器或儲存節點進行資料互動。
  

  

  FastDFS架構

• 這樣的架構具有以下特點：

1. 輕量級（相比GFS簡化了master角色，不再管理meta資料資訊）。
2. 對等結構。
3. 分組方式。

FastDFS協議

FastDFS角色間是基於TCP/IP協議進行通訊，協議包格式為：header + body。具體結構如圖：

FastDFS協議

上傳機制

上傳機制

下載機制

下載機制

同步時間管理：

• 當一個檔案上傳成功後，客戶端馬上發起對該檔案下載請求（或刪除請求）時，tracker是如何選定一個適用的儲存伺服器呢？

• 其實每個儲存伺服器都需要定時將自身的資訊上報給tracker，這些資訊就包括了本地同步時間（即，同步到的最新檔案的時間戳）。而tracker根據各個儲存伺服器的上報情況，就能夠知道剛剛上傳的檔案，在該儲存組中是否已完成了同步。同步資訊上報如下圖：

  
  
  

  同步資訊上報

精巧的FID

說到下載就不得不提檔案索引（又稱：FID）的精巧設計了。檔案索引結構如下圖，是客戶端上傳檔案後儲存伺服器返回給客戶端，用於以後訪問該檔案的索引資訊。檔案索引資訊包括：組名，虛擬磁碟路徑，資料兩級目錄，檔名。

檔案FID

• 組名：檔案上傳後所在的儲存組名稱，在檔案上傳成功後有儲存伺服器返回，需要客戶端自行儲存。
• 虛擬磁碟路徑：儲存伺服器配置的虛擬路徑，與磁碟選項store_path*對應。
• 資料兩級目錄：儲存伺服器在每個虛擬磁碟路徑下建立的兩級目錄，用於儲存資料檔案。
• 檔名：與檔案上傳時不同。是由儲存伺服器根據特定資訊生成，檔名包含：源儲存伺服器IP地址、檔案建立時間戳、檔案大小、隨機數和檔案擴充名等資訊。

快速定位檔案：

知道FastDFS FID的組成後，我們來看看FastDFS是如何通過這個精巧的FID定位到需要訪問的檔案。

• 通過組名tracker能夠很快的定位到客戶端需要訪問的儲存伺服器組，並將選擇合適的儲存伺服器提供客戶端訪問；

• 儲存伺服器根據“檔案儲存虛擬磁碟路徑”和“資料檔案兩級目錄”可以很快定位到檔案所在目錄，並根據檔名找到客戶端需要訪問的檔案。

  
  
  

  定位檔案

主要內容包含：FastDFS各角色的任務分工/協作，檔案索引的原理設計以及檔案上傳/下載操作的流程。通過此次學習我們對FastDFS有了初步的瞭解，如：

• FastDFS只有三個角色；且跟蹤伺服器和儲存伺服器均不存在單點。
• 跟蹤伺服器被動的接收儲存伺服器彙報，對儲存伺服器進行分組管理；併為客戶端選定適用的儲存伺服器。同一儲存伺服器可以同時向多臺跟蹤伺服器彙報狀態資訊。
• 儲存伺服器組內所有儲存伺服器是對等關係，儲存的資料一一對應且相同；所有的儲存伺服器均是同時線上服務，極大的提高的伺服器的使用率，分擔了資料訪問壓力。

參考:
taotao商城專案中FastDFS中安裝配置
Java程式設計師眼中的Linux

下一篇

• 02_在Linux上搭建FastDFS