FastDFS是一個開源的輕量級分布式文件系統，由跟蹤服務器（tracker server）、存儲服務器（storage server）和客戶端（client）三個部分組成，主要解決了海量數據存儲問題，特別適合以中小文件（建議范圍：4KB < file_size <500MB）為載體的在線服務。

Storage server

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的方式被路由到其中某個子目錄下，然后將文件數據直接作為一個本地文件存儲到該目錄中。

Tracker server

Tracker是FastDFS的協調者，負責管理所有的storage server和group，每個storage在啟動后會連接Tracker，告知自己所屬的group等信息，并保持周期性的心跳，tracker根據storage的心跳信息，建立group==>[storage server list]的映射表。

Tracker需要管理的元信息很少，會全部存儲在內存中；另外tracker上的元信息都是由storage匯報的信息生成的，本身不需要持久化任何數據，這樣使得tracker非常容易擴展，直接增加tracker機器即可擴展為tracker cluster來服務，cluster里每個tracker之間是完全對等的，所有的tracker都接受storage的心跳信息，生成元數據信息來提供讀寫服務。

Upload file

FastDFS向使用者提供基本文件訪問接口，比如upload、download、append、delete等，以客戶端庫的方式提供給用戶使用。

選擇tracker server

當集群中不止一個trackerserver時，由于tracker之間是完全對等的關系，客戶端在upload文件時可以任意選擇一個tracker。

選擇存儲的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、文件后綴名（由客戶端指定，主要用于區分文件類型）拼接而成。

文件同步

寫文件時，客戶端將文件寫至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生成一個同步時間戳。

Download file

客戶端upload file成功后，會拿到一個storage生成的文件名，接下來客戶端根據這個文件名即可訪問到該文件。

跟upload file一樣，在download file時客戶端可以選擇任意tracker server。

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

該文件上傳到的源頭storage - 源頭storage只要存活著，肯定包含這個文件，源頭的地址被編碼在文件名中。

文件創建時間戳==storage被同步到的時間戳 且(當前時間-文件創建時間戳) > 文件同步最大時間（如5分鐘) - 文件創建后，認為經過最大同步時間后，肯定已經同步到其他storage了。

文件創建時間戳 < storage被同步到的時間戳。 - 同步時間戳之前的文件確定已經同步了

(當前時間-文件創建時間戳) > 同步延遲閥值（如一天）。 - 經過同步延遲閾值時間，認為文件肯定已經同步了。

小文件合并存儲

將小文件合并存儲主要解決如下幾個問題：

本地文件系統inode數量有限，從而存儲的小文件數量也就受到限制。

多級目錄+目錄里很多文件，導致訪問文件的開銷很大（可能導致很多次IO）

按小文件存儲，備份與恢復的效率低

FastDFS在V3.0版本里引入小文件合并存儲的機制，可將多個小文件存儲到一個大的文件（trunk file），為了支持這個機制，FastDFS生成的文件fileid需要額外增加16個字節

trunk file id

文件在trunk file內部的offset

文件占用的存儲空間大小 （字節對齊及刪除空間復用，文件占用存儲空間>=文件大小）

每個trunk file由一個id唯一標識，trunk file由group內的trunk server負責創建（trunk server是tracker選出來的），并同步到group內其他的storage，文件存儲合并存儲到trunk file后，根據其offset就能從trunk file讀取到文件。

文件在trunk file內的offset編碼到文件名，決定了其在trunk file內的位置是不能更改的，也就不能通過compact的方式回收trunk file內刪除文件的空間。但當trunk file內有文件刪除時，其刪除的空間是可以被復用的，比如一個100KB的文件被刪除，接下來存儲一個99KB的文件就可以直接復用這片刪除的存儲空間。

HTTP訪問支持

FastDFS的tracker和storage都內置了http協議的支持，客戶端可以通過http協議來下載文件，tracker在接收到請求時，通過http的redirect機制將請求重定向至文件所在的storage上；除了內置的http協議外，FastDFS還提供了通過apache或nginx擴展模塊下載文件的支持。

其他特性

FastDFS提供了設置/獲取文件擴展屬性的接口（setmeta/getmeta)，擴展屬性以key-value對的方式存儲在storage上的同名文件（擁有特殊的前綴或后綴），比如/group/M00/00/01/some_file為原始文件，則該文件的擴展屬性存儲在/group/M00/00/01/.some_file.meta文件（真實情況不一定是這樣，但機制類似），這樣根據文件名就能定位到存儲擴展屬性的文件。

以上兩個接口作者不建議使用，額外的meta文件會進一步“放大”海量小文件存儲問題，同時由于meta非常小，其存儲空間利用率也不高，比如100bytes的meta文件也需要占用4K（block_size）的存儲空間。

FastDFS還提供appender file的支持，通過upload_appender_file接口存儲，appender file允許在創建后，對該文件進行append操作。實際上，appender file與普通文件的存儲方式是相同的，不同的是，appender file不能被合并存儲到trunk file。

問題討論

從FastDFS的整個設計看，基本上都以簡單為原則。比如以機器為單位備份數據，簡化了tracker的管理工作；storage直接借助本地文件系統原樣存儲文件，簡化了storage的管理工作；文件寫單份到storage即為成功、然后后臺同步，簡化了寫文件流程。但簡單的方案能解決的問題通常也有限，FastDFS目前尚存在如下問題（歡迎探討）。

數據安全性

• 寫一份即成功：從源storage寫完文件至同步到組內其他storage的時間窗口內，一旦源storage出現故障，就可能導致用戶數據丟失，而數據的丟失對存儲系統來說通常是不可接受的。

• 缺乏自動化恢復機制：當storage的某塊磁盤故障時，只能換存磁盤，然后手動恢復數據；由于按機器備份，似乎也不可能有自動化恢復機制，除非有預先準備好的熱備磁盤，缺乏自動化恢復機制會增加系統運維工作。

• 數據恢復效率低：恢復數據時，只能從group內其他的storage讀取，同時由于小文件的訪問效率本身較低，按文件恢復的效率也會很低，低的恢復效率也就意味著數據處于不安全狀態的時間更長。

• 缺乏多機房容災支持：目前要做多機房容災，只能額外做工具來將數據同步到備份的集群，無自動化機制。

存儲空間利用率

• 單機存儲的文件數受限于inode數量

• 每個文件對應一個storage本地文件系統的文件，平均每個文件會存在block_size/2的存儲空間浪費。

• 文件合并存儲能有效解決上述兩個問題，但由于合并存儲沒有空間回收機制，刪除文件的空間不保證一定能復用，也存在空間浪費的問題

負載均衡

• group機制本身可用來做負載均衡，但這只是一種靜態的負載均衡機制，需要預先知道應用的訪問特性；同時group機制也導致不可能在group之間遷移數據來做動態負載均衡。

備注

FastDFS GitHub地址：https://github.com/happyfish100/fastdfs

總結

以上是生活随笔為你收集整理的FastDFS分布式文件系统设计原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。