在生產中我們一般希望文件系統能幫我們解決以下問題,如:1.超大數據存儲;2.數據高可用(冗餘備份);3.讀/寫高性能;4.海量數據計算。最好還得支持多平臺多語言,支持高併發。
由於單臺服務器無法滿足以上要求,這就迫使開發者不得不考慮使用其他方式解決此類問題。分佈式文件系統就在這樣迫切的需求下孕育而生。
今天爲什麼把標題定爲“分佈式文件系統”呢?是因爲我想通過此次分享(FastDFS原理介紹),和大家去做更多關於分佈式文件系統的研究和分享。我想這項研究應該會是一個“系列”性的專題。在本文之後還計劃分享“FastDFS源碼分析”,“FastDFS擴容及資源優化”。
——————————————————>我是分隔線<——————————————————————-
什麼是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協議與跟蹤器服務器或存儲節點進行數據交互。
ps:這樣的架構具有以下特點:1.輕量級(相比GFS簡化了master角色,不再管理meta數據信息)。2.對等結構。3.分組方式。
FastDFS協議:
FastDFS角色間是基於TCP/IP協議進行通信,協議包格式爲:header + body。具體結構如圖:
上傳機制:
同步時間管理:
當一個文件上傳成功後,客戶端馬上發起對該文件下載請求(或刪除請求)時,tracker是如何選定一個適用的存儲服務器呢?
其實每個存儲服務器都需要定時將自身的信息上報給tracker,這些信息就包括了本地同步時間(即,同步到的最新文件的時間戳)。而tracker根據各個存儲服務器的上報情況,就能夠知道剛剛上傳的文件,在該存儲組中是否已完成了同步。同步信息上報如下圖:
下載機制:
精巧的FID:
說到下載就不得不提文件索引(又稱:FID)的精巧設計了。文件索引結構如下圖,是客戶端上傳文件後存儲服務器返回給客戶端,用於以後訪問該文件的索引信息。文件索引信息包括:組名,虛擬磁盤路徑,數據兩級目錄,文件名。
ps:
組名:文件上傳後所在的存儲組名稱,在文件上傳成功後有存儲服務器返回,需要客戶端自行保存。
虛擬磁盤路徑:存儲服務器配置的虛擬路徑,與磁盤選項store_path*對應。
數據兩級目錄:存儲服務器在每個虛擬磁盤路徑下創建的兩級目錄,用於存儲數據文件。
文件名:與文件上傳時不同。是由存儲服務器根據特定信息生成,文件名包含:源存儲服務器IP地址、文件創建時間戳、文件大小、隨機數和文件拓展名等信息。
快速定位文件:
知道FastDFS FID的組成後,我們來看看FastDFS是如何通過這個精巧的FID定位到需要訪問的文件。
通過組名tracker能夠很快的定位到客戶端需要訪問的存儲服務器組,並將選擇合適的存儲服務器提供客戶端訪問;
存儲服務器根據“文件存儲虛擬磁盤路徑”和“數據文件兩級目錄”可以很快定位到文件所在目錄,並根據文件名找到客戶端需要訪問的文件。
本次分享的主要內容包含:FastDFS各角色的任務分工/協作,文件索引的原理設計以及文件上傳/下載操作的流程。通過此次學習我們對FastDFS有了初步的瞭解,如:
FastDFS只有三個角色;且跟蹤服務器和存儲服務器均不存在單點。
跟蹤服務器被動的接收存儲服務器彙報,對存儲服務器進行分組管理;併爲客戶端選定適用的存儲服務器。同一存儲服務器可以同時向多臺跟蹤服務器彙報狀態信息。
存儲服務器組內所有存儲服務器是對等關係,存儲的數據一一對應且相同;所有的存儲服務器均是同時在線服務,極大的提高的服務器的使用率,分擔了數據訪問壓力。
轉自:http://tech.uc.cn/?p=221