1、Fast DFS 上傳交互過程
Fast DFS向使用者提供基本文件訪問接口，比如upload、download、append、delete等，以客戶端庫的方式提供給用戶使用。
1. client詢問tracker上傳到的storage，不需要附加參數；
2. tracker返回一臺可用的storage，並返回storage的相關信息；
3. client直接和storage通訊完成文件上傳（包括生成file ID ，存儲磁盤）；
4. Fast DFS file download或 者 預覽
返回FILE ID文件名的格式如下：
2、Fast DFS 下載交付過程
客戶端upload file成功後，會拿到一個storage生成的文件名，接下來客戶端根據這個文件名即可訪問到該文件；
1. client詢問tracker下載文件的storage，參數爲文件標識（卷名和文件名）；
2. tracker返回一臺可用的storage；
3. client直接和storage通訊完成文件下載。
需要說明的是，client爲使用FastDFS服務的調用方，client也應該是一臺服務器，它對tracker和storage的調用均爲服務器間的調用。
3、Fast DFS 同步原理
寫文件時，客戶端將文件寫至group內一個storage server即認爲寫文件成功，storage server寫完文件後，會由後臺線程將文件同步至同group內其他的storage server。
每個storage寫文件後，同時會寫一份bin log，bin log裏不包含文件數據，只包含文件名等元信息，這份bin log用於後臺同步，storage會記錄向group內其他storage同步的進度，以便重啓後能接上次的進度繼續同步；進度以時間戳的方式進行記錄，所以最好能保證集羣內所有server的時鐘保持同步。
storage的同步進度會作爲元數據的一部分彙報到tracker上，tracker在選擇讀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生成一個同步時間戳。
4、Fast DFS 特性說明
1）在上述介紹中Tracker服務器是整個系統的核心樞紐，其完成了訪問調度(負載均衡)，監控管理Storage服務器，由此可見Tracker的作用至關重要，也就增加了系統的單點故障，爲此Fast DFS支持多個備用的Tracker，雖然實際測試發現備用Tracker運行不是非常完美，但還是能保證系統可用。
2）在文件同步上，只有同組的Storage才做同步，由文件所在的源Storage服務器push至其它Storage服務器，目前同步是採用Bin log方式實現，由於目前底層對同步後的文件不做正確性校驗，因此這種同步方式僅適用單個集羣點的局部內部網絡，如果在公網上使用，肯定會出現損壞文件的情況，需要自行添加文件校驗機制。
3）支持主從文件，非常適合存在關聯關係的圖片，在存儲方式上，Fast DFS在主從文件ID上做取巧，完成了關聯關係的存儲
5、Fast DFS 優勢、缺點、使用場景
5.1、優勢
1）系統無需支持POSIX(可移植操作系統)，降低了系統的複雜度，處理效率更高
2）支持在線擴容機制，增強系統的可擴展性
3）實現了軟RAID，增強系統的併發處理能力及數據容錯恢復能力
4）支持主從文件，支持自定義擴展名
5）主備Tracker服務，增強系統的可用性
5.2、缺點
1）不支持斷點續傳，對大文件將是噩夢(Fast DFS不適合大文件存儲)
2）不支持POSIX通用接口訪問，通用性較低
3）對跨公網的文件同步，存在較大延遲，需要應用做相應的容錯策略
4）同步機制不支持文件正確性校驗，降低了系統的可用性
5）通過API下載，存在單點的性能瓶頸
5.3、使用場景
Fast DFS是一款類似Google FS的開源分佈式文件系統，是純C語言開發的。
Fast DFS是一個開源的輕量級分佈式文件系統，它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問（文件上傳、文件下載）等，解決了大容量存儲和負載均衡的問題。特別適合以文件爲載體的在線服務，如相冊網站、視頻網站等等。
6、思考
《問題分析》：
從Fast DFS的整個設計看，基本上都已簡單爲原則。比如以機器爲單位備份數據，簡化了tracker的管理工作；storage直接藉助本地文件系統原樣存儲文件，簡化了storage的管理工作；文件寫單份到storage即爲成功、然後後臺同步，簡化了寫文件流程。但簡單的方案能解決的問題通常也有限，Fast DFS目前尚存在如下問題:
1、數據安全性：
寫一份即成功：從源storage寫完文件至同步到組內其他storage的時間窗口內，一旦源storage出現故障，就可能導致用戶數據丟失，而數據的丟失對存儲系統來說通常是不可接受的。
缺乏自動化恢復機制：當storage的某塊磁盤故障時，只能換存磁盤，然後手動恢復數據；由於按機器備份，似乎也不可能有自動化恢復機制，除非有預先準備好的熱備磁盤，缺乏自動化恢復機制會增加系統運維工作。
數據恢復效率低：恢復數據時，只能從group內其他的storage讀取，同時由於小文件的訪問效率本身較低，按文件恢復的效率也會很低，低的恢復效率也就意味着數據處於不安全狀態的時間更長。
缺乏多機房容災支持：目前要做多機房容災，只能額外使用工具來將數據同步到備份的集羣，無自動化機制。
2、存儲空間利用率：
單機存儲的文件數受限於inode數量
每個文件對應一個storage本地文件系統的文件，平均每個文件會存在block_size/2的存儲空間浪費。
文件合併存儲能有效解決上述兩個問題，但由於合併存儲沒有空間回收機制，刪除文件的空間不保證一定能複用，也存在空間浪費的問題
3、負載均衡：
group機制本身可用來做負載均衡，但這只是一種靜態的負載均衡機制，需要預先知道應用的訪問特性；同時group機制也導致不可能在group之間遷移數據來做動態負載均衡