前言：(上傳和下載流程圖詳見：https://my.oschina.net/ydsakyclguozi/blog/403295)
（1）每次上傳文件後都會返回一個地址，用戶需要自己保存此地址。
（2）爲了支持大容量，存儲節點（服務器）採用了分卷（或分組）的組織方式。存儲系統由一個或多個卷組成，卷與卷之間的文件是相互獨立的，所有卷的文件容量累加就是整個存儲系統中的文件容量。一個卷可以由一臺或多臺存儲服務器組成，一個卷下的存儲服務器中的文件都是相同的，卷中的多臺存儲服務器起到了冗餘備份和負載均衡的作用。
網摘1
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都接受stroage的心跳信息，生成元數據信息來提供讀寫服務。
Upload file
FastDFS向使用者提供基本文件訪問接口，比如upload、download、append、delete等，以客戶端庫的方式提供給用戶使用。
選擇tracker server
|
1 |
|
選擇存儲的group
|
1 |
|
選擇storage server
|
1 |
|
選擇storage path
|
1 |
|
生成Fileid
|
1 |
|
選擇兩級目錄
|
1 |
|
生成文件名
|
1 |
|
文件同步
寫文件時，客戶端將文件寫至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，必須帶上文件名信息，tracke從文件名中解析出文件的group、大小、創建時間等信息，然後爲該請求選擇一個storage用來服務讀請求。由於group內的文件同步時在後臺異步進行的，所以有可能出現在讀到時候，文件還沒有同步到某些storage server上，爲了儘量避免訪問到這樣的storage，tracker按照如下規則選擇group內可讀的storage。
|
1 |
|
小文件合併存儲
將小文件合併存儲主要解決如下幾個問題：
|
1 |
|
FastDFS在V3.0版本里引入小文件合併存儲的機制，可將多個小文件存儲到一個大的文件（trunk file），爲了支持這個機制，FastDFS生成的文件fileid需要額外增加16個字節
|
1 |
|
每個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之間遷移數據來做動態負載均衡。
網摘2
FastDFS 介紹
FastDFS 是一個 C 語言實現的開源輕量級分佈式文件系統,作者餘慶(happyfish100),支持 Linux、FreeBSD、AID 等 Unix 系統,解決了大數據存儲和讀寫負載均衡等問題,適合存儲 4KB~500MB 之間的小文件,如圖片網站、短視頻網站、文檔、app 下載站等,UC、京東、支付寶、迅雷、酷狗等都有使用,其中 UC 基於 FastDFS 向用戶提供網盤、廣告和應用下載的業務的存儲服務 FastDFS 與 MogileFS、HDFS、TFS 等都不是系統級的分佈式文件系統,而是應用級的分佈式文件存儲服務。
FastDFS 架構
FastDFS服務有三個角色:跟蹤服務器(tracker server)、存儲服務器(storage server)和客戶端(client)
tracker server: 跟蹤服務器,主要做調度工作,起到均衡的作用;負責管理所有的 storage server 和 group,每個 storage 在啓動後會連接 Tracker,告知自己所屬 group 等信息,並保持週期性心跳, Tracker根據storage心跳信息,建立group--->[storage server list]的映射表;tracker管理的元數據很少,會直接存放在內存;tracker 上的元信息都是由 storage 彙報的信息生成的,本身不需要持久化任何數據,tracker 之間是對等關係,因此擴展 tracker 服務非常容易,之間增加 tracker服務器即可,所有tracker都接受stroage心跳信息,生成元數據信息來提供讀寫服務(與 其他 Master-Slave 架構的優勢是沒有單點,tracker 也不會成爲瓶頸,最終數據是和一個可用的 Storage Server進行傳輸的)
storage server:存儲服務器,主要提供容量和備份服務;以 group 爲單位,每個 group 內可以包含多臺storage server,數據互爲備份,存儲容量空間以group內容量最小的storage爲準;建 議group內的storage server配置相同;以group爲單位組織存儲能夠方便的進行應用隔離、負載均衡和副本數定製;缺點是 group 的容量受單機存儲容量的限制,同時 group 內機器壞掉,數據 恢復只能依賴 group 內其他機器重新同步(壞盤替換,重新掛載重啓 fdfs_storaged 即可)
多個group之間的存儲方式有3種策略:round robin(輪詢)、load balance(選擇最大剩餘空 間的組上傳文件)、specify group(指定group上傳)
group 中 storage 存儲依賴本地文件系統,storage 可配置多個數據存儲目錄,磁盤不做 raid, 直接分別掛載到多個目錄,將這些目錄配置爲 storage 的數據目錄即可
storage 接受寫請求時,會根據配置好的規則,選擇其中一個存儲目錄來存儲文件;爲避免單 個目錄下的文件過多,storage 第一次啓時,會在每個數據存儲目錄裏創建 2 級子目錄,每級 256 個,總共 65536 個,新寫的文件會以 hash 的方式被路由到其中某個子目錄下,然後將文件數據直 接作爲一個本地文件存儲到該目錄中
總結:1.高可靠性:無單點故障 2.高吞吐性:只要Group足夠多,數據流量是足夠分散的
FastDFS 工作流程
上傳
FastDFS 提供基本的文件訪問接口,如 upload、download、append、delete 等
選擇tracker server
集羣中 tracker 之間是對等關係,客戶端在上傳文件時可用任意選擇一個 tracker
選擇存儲 group
當tracker接收到upload file的請求時,會爲該文件分配一個可以存儲文件的group,目前支持選擇 group 的規則爲:
1. Round robin,所有 group 輪詢使用
2. Specified group,指定某個確定的 group
3. Load balance,剩餘存儲空間較多的 group 優先
選擇storage server
當選定group後,tracker會在group內選擇一個storage server給客戶端,目前支持選擇server 的規則爲:
1. Round robin,所有 server 輪詢使用(默認)
2. 根據IP地址進行排序選擇第一個服務器(IP地址最小者)
3. 根據優先級進行排序(上傳優先級由storage server來設置,參數爲upload_priority)
選擇storage path(磁盤或者掛載點)
當分配好storage server後,客戶端將向storage發送寫文件請求,storage會將文件分配一個數據存儲目錄,目前支持選擇存儲路徑的規則爲:
1. round robin,輪詢(默認)
2. load balance,選擇使用剩餘空間最大的存儲路徑
選擇下載服務器
目前支持的規則爲:
1. 輪詢方式,可以下載當前文件的任一storage server
2. 從源storage server下載
生成 file_id
選擇存儲目錄後,storage 會生成一個 file_id,採用 Base64 編碼,包含字段包括:storageserver ip、文件創建時間、文件大小、文件 CRC32 校驗碼和隨機數;每個存儲目錄下有兩個 256*256 個子目錄,storage 會按文件 file_id 進行兩次 hash,路由到其中一個子目錄,,然後將文件以 file_id 爲文件名存儲到該子目錄下,最後生成文件路徑:group 名稱、虛擬磁盤路徑、數據兩級目錄、file_id
其中,
組名:文件上傳後所在的存儲組的名稱,在文件上傳成功後由存儲服務器返回,需要客戶端自行保存
虛擬磁盤路徑:存儲服務器配置的虛擬路徑,與磁盤選項 store_path*參數對應
數據兩級目錄:存儲服務器在每個虛擬磁盤路徑下創建的兩級目錄,用於存儲數據文件
同步機制
1. 新增tracker服務器數據同步問題
由於 storage server 上配置了所有的 tracker server. storage server 和 trackerserver 之間的通信是由 storage server 主動發起的,storage server 爲每個 tracker server 啓動一個線程進行通信;在通信過程中,若發現該 tracker server 返回的本組 storage server列表比本機記錄少,就會將該tracker server上沒有的storage server 同步給該 tracker,這樣的機制使得 tracker 之間是對等關係,數據保持一致
2. 新增storage服務器數據同步問題
若新增storage server或者其狀態發生變化,tracker server都會將storage server列表同步給該組內所有 storage server;以新增 storage server 爲例,因爲新加入的 storage server 會主動連接 tracker server,tracker server 發現有新的 storage server 加入,就會將該組內所有的 storage server 返回給新加入的 storage server,並重新將該組的storage server列表返回給該組內的其他storage server;
3. 組內storage數據同步問題
組內storage server之間是對等的,文件上傳、刪除等操作可以在組內任意一臺storageserver 上進行。文件同步只能在同組內的 storage server 之間進行,採用 push 方式, 即源服務器同步到目標服務器
A. 只在同組內的storage server之間進行同步
B. 源數據才需要同步,備份數據不再同步
C. 特例:新增storage server時,由其中一臺將已有所有數據(包括源數據和備份數據)同步到新增服務器
storage server的7種狀態:
通過命令 fdfs_monitor /etc/fdfs/client.conf 可以查看 ip_addr 選項顯示 storageserver 當前狀態
INIT : 初始化,尚未得到同步已有數據的源服務器
WAIT_SYNC : 等待同步,已得到同步已有數據的源服務器
SYNCING : 同步中
DELETED : 已刪除,該服務器從本組中摘除
OFFLINE :離線
ONLINE : 在線,尚不能提供服務
ACTIVE : 在線,可以提供服務
組內增加storage serverA狀態變化過程:
1. storage server A 主動連接 tracker server,此時 tracker server 將 storageserverA 狀態設置爲 INIT
2. storage server A 向 tracker server 詢問追加同步的源服務器和追加同步截止時間點(當前時間),若組內只有storage server A或者上傳文件數爲0,則告訴新機器不需要數據同步,storage server A 狀態設置爲 ONLINE ;若組內沒有 active 狀態機器,就返回錯誤給新機器,新機器睡眠嘗試;否則 tracker 將其狀態設置爲 WAIT_SYNC
3. 假如分配了 storage server B 爲同步源服務器和截至時間點,那麼 storage server B會將截至時間點之前的所有數據同步給storage server A,並請求tracker設置 storage server A 狀態爲SYNCING;到了截至時間點後,storage server B向storage server A 的同步將由追加同步切換爲正常 binlog 增量同步,當取不到更多的 binlog 時,請求tracker將storage server A設置爲OFFLINE狀態,此時源同步完成
4. storage server B 向 storage server A 同步完所有數據,暫時沒有數據要同步時, storage server B請求tracker server將storage server A的狀態設置爲ONLINE
5. 當 storage server A 向 tracker server 發起心跳時,tracker sercer 將其狀態更改爲 ACTIVE,之後就是增量同步(binlog)
註釋:
1.整個源同步過程是源機器啓動一個同步線程,將數據 push 到新機器,最大達到一個磁盤的 IO,不能併發
2.由於源同步截止條件是取不到 binlog,系統繁忙,不斷有新數據寫入的情況,將會導致一直無法完成源同步過程
下載
client 發送下載請求給某個 tracker,必須帶上文件名信息,tracker 從文件名中解析出文件的 group、大小、創建時間等信息,然後爲該請求選擇一個 storage 用於讀請求;由於 group 內的文件同步在後臺是異步進行的,可能出現文件沒有同步到其他storage server上或者延遲的問題, 後面我們在使用 nginx_fastdfs_module 模塊可以很好解決這一問題
文件合併原理
小文件合併存儲主要解決的問題:
1. 本地文件系統inode數量有限,存儲小文件的數量受到限制
2. 多級目錄+目錄裏很多文件,導致訪問文件的開銷很大(可能導致很多次IO)
3. 按小文件存儲,備份和恢復效率低
FastDFS 提供合併存儲功能,默認創建的大文件爲 64MB,然後在該大文件中存儲很多小文件; 大文件中容納一個小文件的空間稱作一個 Slot,規定 Slot 最小值爲 256 字節,最大爲 16MB,即小於 256 字節的文件也要佔用 256 字節,超過 16MB 的文件獨立存儲;
爲了支持文件合併機制,FastDFS生成的文件file_id需要額外增加16個字節;每個trunk file 由一個id唯一標識,trunk file由group內的trunk server負責創建(trunk server是tracker 選出來的),並同步到group內其他的storage,文件存儲合併存儲到trunk file後,根據其文件偏移量就能從trunk file中讀取文件