網摘彙總：
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
當叢集中不止一個tracker server時，由于tracker之間是完全對等的關系，用戶端在upload檔案時可以任意選擇一個trakcer。 選擇存儲的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給用戶端，支援如下選擇storage的規則： 1. Round robin，在group内的所有storage間輪詢 2. First server ordered by ip，按ip排序 3. First server ordered by priority，按優先級排序（優先級在storage上配置） 選擇storage path
當配置設定好storage server後，用戶端将向storage發送寫檔案請求，storage将會為檔案配置設定一個資料存儲目錄，支援如下規則： 1. Round robin，多個存儲目錄間輪詢 2. 剩餘存儲空間最多的優先 生成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，必須帶上檔案名資訊，tracke從檔案名中解析出檔案的group、大小、建立時間等資訊，然後為該請求選擇一個storage用來服務讀請求。由于group内的檔案同步時在背景異步進行的，是以有可能出現在讀到時候，檔案還沒有同步到某些storage server上，為了盡量避免通路到這樣的storage，tracker按照如下規則選擇group内可讀的storage。
1. 該檔案上傳到的源頭storage - 源頭storage隻要存活着，肯定包含這個檔案，源頭的位址被編碼在檔案名中。 2. 檔案建立時間戳==storage被同步到的時間戳 且(目前時間-檔案建立時間戳) > 檔案同步最大時間（如5分鐘) - 檔案建立後，認為經過最大同步時間後，肯定已經同步到其他storage了。 3. 檔案建立時間戳 < storage被同步到的時間戳。 - 同步時間戳之前的檔案确定已經同步了 4. (目前時間-檔案建立時間戳) > 同步延遲閥值（如一天）。 - 經過同步延遲門檻值時間，認為檔案肯定已經同步了。 小檔案合并存儲
将小檔案合并存儲主要解決如下幾個問題：
1. 本地檔案系統inode數量有限，進而存儲的小檔案數量也就受到限制。 2. 多級目錄+目錄裡很多檔案，導緻通路檔案的開銷很大（可能導緻很多次IO） 3. 按小檔案存儲，備份與恢複的效率低 FastDFS在V3.0版本裡引入小檔案合并存儲的機制，可将多個小檔案存儲到一個大的檔案（trunk file），為了支援這個機制，FastDFS生成的檔案fileid需要額外增加16個位元組
1. trunk file id 2. 檔案在trunk file内部的offset 3. 檔案占用的存儲空間大小 （位元組對齊及删除空間複用，檔案占用存儲空間>=檔案大小） 每個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 編碼,包含字段包括:storage server 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 選項顯示 storage server 目前狀态
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中讀取檔案
--------------------- 本文來自 u013378306 的CSDN 部落格 ，全文位址請點選：https://blog.csdn.net/u013378306/article/details/74852355?utm_source=copy
特性
1）在上述介紹中Tracker伺服器是整個系統的核心樞紐，其完成了通路排程(負載均衡)，監控管理Storage伺服器，由此可見Tracker的作用至關重要，也就增加了系統的單點故障，為此FastDFS支援多個備用的Tracker，雖然實際測試發現備用Tracker運作不是非常完美，但還是能保證系統可用。
2）在檔案同步上，隻有同組的Storage才做同步，由檔案所在的源Storage伺服器push至其它Storage伺服器，目前同步是采用Binlog方式實作，由于目前底層對同步後的檔案不做正确性校驗，是以這種同步方式僅适用單個叢集點的局部内部網絡，如果在公網上使用，肯定會出現損壞檔案的情況，需要自行添加檔案校驗機制。
3）支援主從檔案，非常适合存在關聯關系的圖檔，在存儲方式上，FastDFS在主從檔案ID上做取巧，完成了關聯關系的存儲。
優點
1）系統無需支援POSIX(可移植作業系統)，降低了系統的複雜度，處理效率更高
2）支援線上擴容機制，增強系統的可擴充性
3）實作了軟RAID，增強系統的并發處理能力及資料容錯恢複能力
4）支援主從檔案，支援自定義擴充名
5）主備Tracker服務，增強系統的可用性
缺點
1）不支援斷點續傳，對大檔案将是噩夢(FastDFS不适合大檔案存儲)
2）不支援POSIX通用接口通路，通用性較低
3）對跨公網的檔案同步，存在較大延遲，需要應用做相應的容錯政策
4）同步機制不支援檔案正确性校驗，降低了系統的可用性
5）通過API下載下傳，存在單點的性能瓶頸
---------------------
本文來自 HeyManLeader 的CSDN 部落格 ，全文位址請點選：https://blog.csdn.net/sinat_27186785/article/details/52011130?utm_source=copy