分佈式文件存儲系統調研

主流分佈式文件存儲系統

分佈式文件系統	適合類型	文件分佈	系統性能	複雜度	備份機制	接口類型	開發語言	使用
FastDFS	4KB~500MB	小文件合併存儲，不分片處理	很高	簡單	組（卷）冗餘存儲	API，HTTP接口	C	支付寶，UC，京東
TFS	小文件	小文件合併，以block組織分片	很高	複雜	Block存儲多份，主從災備	API HTTP	C++	淘寶圖片儲存

FastDFS

FastDFS是阿里巴巴開源的一套輕量級,天生就是分佈式設計的文件系統，是純C語言開發的。
FastDFS是一個開源的輕量級分佈式文件系統，它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問（文件上傳、文件下載）等，解決了大容量存儲和負載均衡的問題。特別適合以文件爲載體的在線服務，如相冊網站、視頻網站等等。
官方論壇 http://bbs.chinaunix.net/forum-240-1.html
FastDfs google Code http://code.google.com/p/fastdfs/
分佈式文件系統FastDFS架構剖析 http://www.programmer.com.cn/4380/

TFS

是一個高可擴展、高可用、高性能、面向互聯網服務的分佈式文件系統，主要針對海量的非結構化數據，它構築在普通的Linux機器集羣上，可爲外部提供高可靠和高併發的存儲訪問。TFS爲淘寶提供海量小文件存儲，通常文件大小不超過1M。它採用了HA架構和平滑擴容，保證了整個文件系統的可用性和擴展性。同時扁平化的數據組織結構，可將文件名映射到文件的物理地址，簡化了文件的訪問流程，一定程度上爲TFS提供了良好的讀寫性能。

FastDFS作者簡介

FastDFS的作者是餘慶(happyfish100)，github地址https://github.com/happyfish100

FastDFS主要特性

爲互聯網量身定製，海量數據文件存儲。
高可用(同組備份機制)FastDFS可以看作是基於key/value pair存儲系統，也許稱爲分佈式文件存儲服務更合適。
文件不分塊存儲，上傳的文件和OS文件系統中的文件一一對應
支持高併發
支持相同內容的文件只保存一份，節約磁盤空間
下載文件支持HTTP協議，可以使用內置Web Server，也可以和其他Web Server配合使用
支持在線擴容
支持主從文件（文件備份，讀寫）
存儲服務器上可以保存文件屬性（meta-data）V2.0網絡通信採用libevent，支持大併發訪問，整體性能更好
支持秒存（併發上傳）
支持斷點續傳，分片上傳

FastDFS主要用戶

京東,主要商品圖片存儲,可以看出來這是fastdfs典型路徑
UC,主要提供網盤服務
支付寶等

FastDFS相關概念

FastDFS服務端有三個模塊：跟蹤服務器（tracker server）、存儲服務器（storage server）、客戶端（client）。

跟蹤服務器（tracker server）

跟蹤服務器，主要做調度工作，起負載均衡的作用。在內存中記錄集羣中所有存儲組和存儲服務器的狀態信息，是客戶端和數據服務器交互的樞紐。相比GFS中的master更爲精簡，不記錄文件索引信息，佔用的內存量很少。
Tracker是FastDFS的協調者，負責管理所有的storage server和group，每個storage在啓動後會連接Tracker，告知自己所屬的group等信息，並保持週期性的心跳，tracker根據storage的心跳信息，建立group==>[storage server list]的映射表。
Tracker需要管理的元信息很少，會全部存儲在內存中；另外tracker上的元信息都是由storage彙報的信息生成的，本身不需要持久化任何數據，這樣使得tracker非常容易擴展，直接增加tracker機器即可擴展爲tracker cluster來服務，cluster裏每個tracker之間是完全對等的，所有的tracker都接受stroage的心跳信息，生成元數據信息來提供讀寫服務。

存儲服務器（storage server）

存儲服務器（又稱：存儲節點或數據服務器），文件和文件屬性（meta data）都保存到存儲服務器上。Storage server直接利用OS的文件系統調用管理文件。
Storage server（後簡稱storage）以組（卷，group或volume）爲單位組織，一個group內包含多臺storage機器，數據互爲備份，存儲空間以group內容量最小的storage爲準，所以建議group內的多個storage儘量配置相同，以免造成存儲空間的浪費。
以group爲單位組織存儲能方便的進行應用隔離、負載均衡、副本數定製（group內storage server數量即爲該group的副本數），比如將不同應用數據存到不同的group就能隔離應用數據，同時還可根據應用的訪問特性來將應用分配到不同的group來做負載均衡；缺點是group的容量受單機存儲容量的限制，同時當group內有機器壞掉時，數據恢復只能依賴group內地其他機器，使得恢復時間會很長。
group內每個storage的存儲依賴於本地文件系統，storage可配置多個數據存儲目錄，比如有10塊磁盤，分別掛載在/data/disk1-/data/disk10，則可將這10個目錄都配置爲storage的數據存儲目錄。

storage接受到寫文件請求時，會根據配置好的規則（後面會介紹），選擇其中一個存儲目錄來存儲文件。爲了避免單個目錄下的文件數太多，在storage第一次啓動時，會在每個數據存儲目錄裏創建2級子目錄，每級256個，總共65536個文件，新寫的文件會以hash的方式被路由到其中某個子目錄下，然後將文件數據直接作爲一個本地文件存儲到該目錄中。

客戶端（client）

客戶端，作爲業務請求的發起方，通過專有接口，使用TCP/IP協議與跟蹤器服務器或存儲節點進行數據交互。FastDFS向使用者提供基本文件訪問接口，比如upload、download、append、delete等，以客戶端庫的方式提供給用戶使用。
另外兩個概念：
group ：組，也可稱爲卷。同組內服務器上的文件是完全相同的，同一組內的storage server之間是對等的，文件上傳、刪除等操作可以在任意一臺storage server上進行。
meta data ：文件相關屬性，鍵值對（ Key Value Pair）方式，如：width=1024,heigth=768 。
Tracker相當於FastDFS的大腦，不論是上傳還是下載都是通過tracker來分配資源；客戶端一般可以使用ngnix等靜態服務器來調用或者做一部分的緩存；存儲服務器內部分爲卷（或者叫做組），卷於卷之間是平行的關係，可以根據資源的使用情況隨時增加，卷內服務器文件相互同步備份，以達到容災的目的。

FastDFS文件上傳機制

首先客戶端請求Tracker服務獲取到存儲服務器的ip地址和端口，然後客戶端根據返回的IP地址和端口號請求上傳文件，存儲服務器接收到請求後生產文件，並且將文件內容寫入磁盤並返回給客戶端file_id、路徑信息、文件名等信息，客戶端保存相關信息上傳完畢。

內部機制如下：

選擇tracker server

當集羣中不止一個tracker server時，由於tracker之間是完全對等的關係，客戶端在upload文件時可以任意選擇一個trakcer。選擇存儲的group 當tracker接收到upload file的請求時，會爲該文件分配一個可以存儲該文件的group，支持如下選擇group的規則：

Round robin，所有的group間輪詢
Specified group，指定某一個確定的group
Load balance，剩餘存儲空間多多group優先

選擇storage server

當選定group後，tracker會在group內選擇一個storage server給客戶端，支持如下選擇storage的規則：

Round robin，在group內的所有storage間輪詢
First server ordered by ip，按ip排序
First server ordered by priority，按優先級排序（優先級在storage上配置）

選擇storage path

當分配好storage server後，客戶端將向storage發送寫文件請求，storage將會爲文件分配一個數據存儲目錄，支持如下規則：

Round robin，多個存儲目錄間輪詢
剩餘存儲空間最多的優先

生成Fileid

選定存儲目錄之後，storage會爲文件生一個Fileid，由storage server ip、文件創建時間、文件大小、文件crc32和一個隨機數拼接而成，然後將這個二進制串進行base64編碼，轉換爲可打印的字符串。選擇兩級目錄當選定存儲目錄之後，storage會爲文件分配一個fileid，每個存儲目錄下有兩級256*256的子目錄，storage會按文件fileid進行兩次hash（猜測），路由到其中一個子目錄，然後將文件以fileid爲文件名存儲到該子目錄下。

生成文件名

當文件存儲到某個子目錄後，即認爲該文件存儲成功，接下來會爲該文件生成一個文件名，文件名由group、存儲目錄、兩級子目錄、fileid、文件後綴名（由客戶端指定，主要用於區分文件類型）拼接而成。

FastDFS文件下載機制

客戶端帶上文件名信息請求Tracker服務獲取到存儲服務器的ip地址和端口，然後客戶端根據返回的IP地址和端口號請求下載文件，存儲服務器接收到請求後返回文件給客戶端。

跟upload file一樣，在download file時客戶端可以選擇任意tracker server。tracker發送download請求給某個tracker，必須帶上文件名信息，tracke從文件名中解析出文件的group、大小、創建時間等信息，然後爲該請求選擇一個storage用來服務讀請求。由於group內的文件同步時在後臺異步進行的，所以有可能出現在讀到時候，文件還沒有同步到某些storage server上，爲了儘量避免訪問到這樣的storage，tracker按照如下規則選擇group內可讀的storage。

該文件上傳到的源頭storage - 源頭storage只要存活着，肯定包含這個文件，源頭的地址被編碼在文件名中。
文件創建時間戳==storage被同步到的時間戳且(當前時間-文件創建時間戳) > 文件同步最大時間（如5分鐘) - 文件創建後，認爲經過最大同步時間後，肯定已經同步到其他storage了。
文件創建時間戳 < storage被同步到的時間戳。 - 同步時間戳之前的文件確定已經同步了
(當前時間-文件創建時間戳) > 同步延遲閥值（如一天）。 - 經過同步延遲閾值時間，認爲文件肯定已經同步了。

同步時間管理

當一個文件上傳成功後，客戶端馬上發起對該文件下載請求（或刪除請求）時，tracker是如何選定一個適用的存儲服務器呢？其實每個存儲服務器都需要定時將自身的信息上報給tracker，這些信息就包括了本地同步時間（即，同步到的最新文件的時間戳）。而tracker根據各個存儲服務器的上報情況，就能夠知道剛剛上傳的文件，在該存儲組中是否已完成了同步。同步信息上報如下圖：

寫文件時，客戶端將文件寫至group內一個storage server即認爲寫文件成功，storage server寫完文件後，會由後臺線程將文件同步至同group內其他的storage server。
每個storage寫文件後，同時會寫一份binlog，binlog裏不包含文件數據，只包含文件名等元信息，這份binlog用於後臺同步，storage會記錄向group內其他storage同步的進度，以便重啓後能接上次的進度繼續同步；進度以時間戳的方式進行記錄，所以最好能保證集羣內所有server的時鐘保持同步。
storage的同步進度會作爲元數據的一部分彙報到tracker上，tracke在選擇讀storage的時候會以同步進度作爲參考。比如一個group內有A、B、C三個storage server，A向C同步到進度爲T1 (T1以前寫的文件都已經同步到B上了），B向C同步到時間戳爲T2（T2 > T1)，tracker接收到這些同步進度信息時，就會進行整理，將最小的那個做爲C的同步時間戳，本例中T1即爲C的同步時間戳爲T1（即所有T1以前寫的數據都已經同步到C上了）；同理，根據上述規則，tracker會爲A、B生成一個同步時間戳。

精巧的文件ID-FID

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

組名：文件上傳後所在的存儲組名稱，在文件上傳成功後有存儲服務器返回，需要客戶端自行保存。
虛擬磁盤路徑：存儲服務器配置的虛擬路徑，與磁盤選項store_path*對應。
數據兩級目錄：存儲服務器在每個虛擬磁盤路徑下創建的兩級目錄，用於存儲數據文件。
文件名：與文件上傳時不同。是由存儲服務器根據特定信息生成，文件名包含：源存儲服務器IP地址、文件創建時間戳、文件大小、隨機數和文件拓展名等信息。

快速定位文件

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

通過組名tracker能夠很快的定位到客戶端需要訪問的存儲服務器組，並將選擇合適的存儲服務器提供客戶端訪問；
存儲服務器根據“文件存儲虛擬磁盤路徑”和“數據文件兩級目錄”可以很快定位到文件所在目錄，並根據文件名找到客戶端需要訪問的文件。

系統部署架構

本文轉載自簡書

分佈式文件存儲系統調研