一、FastDFS簡介
FastDFS是一款開源的輕量級分佈式文件系統，最早在ali，爲易道用車架構師餘慶所寫。它用純C語言實現，支持Linux、FreeBSD、AIX等UNIX系統。FastDFS爲互聯網應用量身定做，追求高性能和高擴展性，更適合稱作應用級的分佈式文件存儲服務。它只能通過專有API對文件進行存取訪問，不支持POSIX接口方式，通用性較低。
在語言支持方面，目前提供了C、java、php、.NET的API。
現應用在jd、taobao、58、uc、51cto。
二、FastDFS用途
1）FastDFS主要解決了大容量的文件存儲和高併發訪問的問題，文件存取時實現了負載均衡。
2）FastDFS實現了軟件方式的RAID，可以使用廉價的IDE硬盤進行存儲 ，支持存儲服務器在線擴容。
3）FastDFS特別適合大中型網站使用，用來存儲資源文件（如：圖片、文檔、音頻、視頻等等）。
三、FastDFS工作機制
1. 集羣架構圖
FastDFS集羣架構由追蹤服務器（tracker server）、存儲服務器（storage server）和客戶端（client）三個部分組成。
tracker server：主要做調度工作，在訪問中起負載均衡作用，在內存中記錄集羣中group和storage server的狀態信息，是連接client和storage server的樞紐，因爲相關信息全部在內存中，tracker server的性能非常高（它本身所需負載很小），一個較大的集羣中（如上百個group）有3臺就足夠。
storage server：文件和文件屬性（如metadata）都保存在該server上，存儲服務包括文件存儲，文件同步，提供文件訪問接口，同時以key-value的方式管理文件的元數據。
FastDFS架構解讀
- 兩個角色，tracker server和storage server，不需要存儲文件索引信息。
- 所有服務器都是對等的，不存在Master-Slave關係。
- 存儲服務器採用分組方式，同組內存儲服務器上的文件完全相同（RAID 1）。
- storage集羣中，組（或叫卷）和組之間不通信是相互獨立的，storage主動向tracker彙報狀態，所有組的容量累加就是整個存儲系統中的文件容量，一個組可由一臺或多臺storage server組成，一個組內的所有單個存儲服務器中的文件都是相同的，一組中的多臺存儲服務器起到了冗餘備份和負載均衡的作用，在組中增加服務器時，同步已有的文件由系統自動完成，同步完成後，系統自動將新增服務器切換到線上提供服務，當存儲空間不足或即將耗盡時，可動態添加組，只需要增加一臺或多臺服務器，並將它們配置爲一個新的組，這樣就擴大了存儲系統的容量。
- 擴展整個FastDFS集羣容量，在storage里加group即可。
2. 上傳下載機制
2.1 上傳機制
1、選擇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優先
2、選擇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上配置）
3、選擇storage path
當分配好storage server後，客戶端將向storage發送寫文件請求，storage將會爲文件分配一個數據存儲目錄，支持如下規則：
- 1、Round robin，多個存儲目錄間輪詢
- 2、剩餘存儲空間最多的優先
4、生成文件名
選定存儲目錄之後，storage會爲文件生一個文件名，由storage server ip、文件創建時間、文件大小、文件校驗碼和一個隨機數生成。
選擇兩級目錄，每個存儲目錄下有兩級256*256的子目錄，storage會按文件名進行兩次hash（猜測），路由到其中一個子目錄，然後將文件存儲到該子目錄下。
5、生成文件索引
當文件存儲到某個子目錄後，即認爲該文件存儲成功，接下來會爲該文件生成一個文件索引，即Fileid。Fileid由group、存儲目錄、兩級子目錄、文件名、文件後綴名（由客戶端指定，主要用於區分文件類型）拼接而成。
2.2 下載機制
客戶端帶上文件名信息請求Tracker服務獲取到存儲服務器的ip地址和端口，然後客戶端根據返回的IP地址和端口號請求下載文件，存儲服務器接收到請求後返回文件給客戶端。
3. 文件索引解析
文件索引示例：
group1/M00/00/0C/wKjRbExx2K0AAAAAAAANiSQUgyg37275.h
“group1"爲組名，”/M00/00/0C/"爲磁盤和目錄，"wKjRbExx2K0AAAAAAAANiSQUgyg37275.h"爲文件名及後綴。
其中文件名由源頭storage server ip、創建時的時間戳、文件大小、文件校驗碼和一個隨機數進行hash計算後生成，最後基於base64進行文本編碼，轉換爲可打印的字符。
4. 文件同步機制
storage server採用binlog文件記錄文件上傳、刪除等更新操作。binlog不記錄文件內容，只記錄文件名等元數據信息。
storage server中由專門的線程根據binlog進行文件同步。爲了最大程度地避免相互影響以及出於系統簡潔性考慮，storage server對組內除自己以外的每臺服務器都會啓動一個線程來進行文件同步。文件同步採用增量同步方式，系統記錄已同步的位置（binlog文件偏移量）到標識文件中。標識文件名格式：{dest storage IP}_{port}.mark
文件同步只在同組內的storage server之間進行，採用push方式，即源頭服務器同步給目標服務器。只有源頭數據才需要同步，備份數據並不需要再次同步，否則就構成環路了。
新增加一臺storage server時，由已有的一臺storage server將已有的所有數據（包括源頭數據和備份數據）同步給該新增服務器。
客戶端將一個文件上傳到一臺storage server後，文件上傳工作就結束了。由storage server根據binlog中的上傳記錄將這個文件同步到同組的其他storage server。這樣的文件同步方式是異步方式，異步方式帶來了文件同步延遲的問題。新上傳文件後，在尚未被同步過去的Storage server上訪問該文件，會出現找不到文件的現象。
四、優劣分析
1. 優點
- 系統無需支持POSIX(可移植操作系統)，降低了系統的複雜度，處理效率更高
- 支持在線擴容機制，增強系統的可擴展性
- 實現了軟RAID，增強系統的併發處理能力及數據容錯恢復能力
- 支持主從文件，支持自定義擴展名
- 支持多臺備用Tracker，增強系統的可用性
- 支持Nginx和Apache擴展，可提供http下載
什麼是主從文件？
主從文件是指文件ID有關聯的文件，一個主文件可以對應多個從文件。
主文件ID = 主文件名 + 主文件擴展名
從文件ID = 主文件名 + 從文件後綴名 + 從文件擴展名
使用主從文件的一個典型例子：以圖片爲例，主文件爲原始圖片，從文件爲該圖片的一張或多張縮略圖。
FastDFS中的主從文件只是在文件ID上有聯繫。FastDFS server端沒有記錄主從文件對應關係，因此刪除主文件，FastDFS不會自動刪除從文件。
刪除主文件後，從文件的級聯刪除，需要由應用端來實現。
主文件及其從文件均存放到同一個group中。
主從文件的生成順序：
1）先上傳主文件（如原文件），得到主文件ID
2）然後上傳從文件（如縮略圖），指定主文件ID和從文件後綴名（當然還可以同時指定從文件擴展名），得到從文件ID
2. 缺點
- 不支持斷點續傳，對大文件將是噩夢(FastDFS不適合大文件存儲)
- 不支持POSIX通用接口訪問，通用性較低
- 同步機制不支持文件正確性校驗，降低了系統的可用性，對跨公網的文件同步，存在較大延遲，需要應用做相應的容錯策略
- 通過API下載，存在單點的性能瓶頸
五、產生的實際問題與當前存在的解決方案
1. 文件同步延遲
文件同步方式是異步方式，新上傳文件後，在尚未被同步過去的storage server上訪問該文件，會出現找不到文件的現象。
解決方案：
需要說明的是，一個組包含的storage server不是通過配置文件設定的，而是通過tracker server獲取到的。客戶端和storage server主動連接tracker server。storage server主動向tracker server報告其狀態信息，包括磁盤剩餘空間、文件同步狀況、文件上傳下載次數等統計信息。storage server會連接集羣中所有的tracker server，向他們報告自己的狀態。storage server啓動一個單獨的線程來完成對一臺tracker server的連接和定時報告。另外，每臺storage server都會定時向tracker server報告它向同組的其他storage server同步到的文件時間戳。當tracker server收到一臺storage server的文件同步報告後，它會依次找出該組內各個storage server被同步到的文件時間戳最小值，作爲storage的一個屬性記錄到內存中。根據上述情況FastDFS提供下面簡單解決方案：
1、和文件更新一樣，優先選擇源storage server下載文件即可。這可以在tracker server的配置文件中設置，對應的參數名爲download_server。
2、選擇storage server的方法是輪流選擇（round-robin）。當client詢問tracker server有哪些storage server可以下載指定文件時，tracker server返回滿足如下四個條件之一的storage server：
- 該文件上傳到的源storage server，文件直接上傳到該服務器上的；
- 文件創建時間戳 < storage server被同步到的文件時間戳，這意味着當前文件已經被同步過來了；
- 文件創建時間戳 = storage server被同步到的文件時間戳，且（當前時間 - 文件創建時間戳） > 一個文件同步完成需要的最大時間（如5分鐘）；
- （當前時間 - 文件創建時間戳） > 文件同步延遲閾值，比如我們把閾值設置爲1天，表示文件同步在一天內肯定可以完成。
2. 數據安全性
- 寫一份即成功：從源storage寫完文件至同步到組內其他storage的時間窗口內，一旦源storage出現故障，就可能導致用戶數據丟失，而數據的丟失對存儲系統來說通常是不可接受的。
- 缺乏自動化恢復機制：當storage的某塊磁盤故障時，只能換存磁盤，然後手動恢復數據；由於按機器備份，似乎也不可能有自動化恢復機制，除非有預先準備好的熱備磁盤，缺乏自動化恢復機制會增加系統運維工作。
- 數據恢復效率低：恢復數據時，只能從group內其他的storage讀取，同時由於小文件的訪問效率本身較低，按文件恢復的效率也會很低，低的恢復效率也就意味着數據處於不安全狀態的時間更長。
- 缺乏多機房容災支持：目前要做多機房容災，只能額外使用工具來將數據同步到備份的集羣，無自動化機制。
3. 存儲空間利用率
單機存儲的文件數受限於inode數量
每個文件對應一個storage本地文件系統的文件，平均每個文件會存在block_size/2的存儲空間浪費。
文件合併存儲能有效解決上述兩個問題，但由於合併存儲沒有空間回收機制，刪除文件的空間不保證一定能複用，也存在空間浪費的問題。
4. 負載均衡
group機制本身可用來做負載均衡，但這只是一種靜態的負載均衡機制，需要預先知道應用的訪問特性；同時group機制也導致不可能在group之間遷移數據來做動態負載均衡。
六、參考文獻
FastDFS的介紹 [https://www.cnblogs.com/shenxm/p/8459292.html]
分佈式文件系統FastDFS詳解 [https://www.cnblogs.com/ityouknow/p/8240976.html]
FastDFS特性及問題思考 [https://www.cnblogs.com/jym-sunshine/p/6397705.html]
FastDFS同步問題討論 [https://www.cnblogs.com/snake-hand/p/3161528.html]