fastdfs是國人開發的一款分布式檔案系統，目前社群比較活躍。系統中存在三種節點：client、tracker、storage，在底層儲存上通過邏輯的分組概念，使得通過在同組內配置多個storage，從而實現軟raid10，提公升簡單負載均衡、併發io的效能、及資料的冗餘備份；同時通過線性的新增新的邏輯儲存組，從容實現儲存容量的線性擴容。
1）在上述介紹中tracker伺服器是整個系統的核心樞紐，其完成了訪問排程(負載均衡)，監控管理storage伺服器，由此可見tracker的作用至關重要，也就增加了系統的單點故障，為此fastdfs支援多個備用的tracker，雖然實際測試發現備用tracker執行不是非常完美，但還是能保證系統可用。
2）在檔案同步上，只有同組的storage才做同步，由檔案所在的源storage伺服器push至其它storage伺服器，目前同步是採用binlog方式實現，由於目前底層對同步後的檔案不做正確性校驗，因此這種同步方式僅適用單個集群點的區域性內部網路，如果在公網上使用，肯定會出現損壞檔案的情況，需要自行新增檔案校驗機制。
3）支援主從檔案，非常適合存在關聯關係的，在儲存方式上，fastdfs在主從檔案id上做取巧，完成了關聯關係的儲存。
4）支援主從檔案，支援自定義副檔名
5）主備tracker服務，增強系統的可用性
缺點
1）不支援斷點續傳，對大檔案將是噩夢(fastdfs不適合大檔案儲存)
2）不支援posix通用介面訪問，通用性較低
3）對跨公網的檔案同步，存在較大延遲，需要應用做相應的容錯策略
4）同步機制不支援檔案正確性校驗，降低了系統的可用性
從fastdfs的整個設計看，基本上都已簡單為原則。比如以機器為單位備份資料，簡化了tracker的管理工作；storage直接借助本地檔案系統原樣儲存檔案，簡化了storage的管理工作；檔案寫單份到storage即為成功、然後後台同步，簡化了寫檔案流程。但簡單的方案能解決的問題通常也有限，fastdfs目前尚存在如下問題:
資料安全性：
寫乙份即成功：從源storage寫完檔案至同步到組內其他storage的時間視窗內，一旦源storage出現故障，就可能導致使用者資料丟失，而資料的丟失對儲存系統來說通常是不可接受的。
缺乏自動化恢復機制：當storage的某塊磁碟故障時，只能換存磁碟，然後手動恢復資料；由於按機器備份，似乎也不可能有自動化恢復機制，除非有預先準備好的熱備磁碟，缺乏自動化恢復機制會增加系統運維工作。
資料恢復效率低：恢復資料時，只能從group內其他的storage讀取，同時由於小檔案的訪問效率本身較低，按檔案恢復的效率也會很低，低的恢復效率也就意味著資料處於不安全狀態的時間更長。
缺乏多機房容災支援：目前要做多機房容災，只能額外使用工具來將資料同步到備份的集群，無自動化機制。
儲存空間利用率：
單機儲存的檔案數受限於inode數量
每個檔案對應乙個storage本地檔案系統的檔案，平均每個檔案會存在block_size/2的儲存空間浪費。
檔案合併儲存能有效解決上述兩個問題，但由於合併儲存沒有空間**機制，刪除檔案的空間不保證一定能復用，也存在空間浪費的問題
負載均衡：
group機制本身可用來做負載均衡，但這只是一種靜態的負載均衡機制，需要預先知道應用的訪問特性；同時group機制也導致不可能在group之間遷移資料來做動態負載均衡
FastDFS問題排查
記一次fastdfs問題的排查。fastdfs基本架構特點鮮明，分為tracker storage兩個模組，前者乙個，後者多個，用以保證 分布式 冗餘式 因此後者一般多個伺服器且乙個伺服器放乙個，一台伺服器允許同時具有tracker和storage 一般也的確如此，畢竟tracker不怎麼佔空間 t...
fastDFS及搭建過程
tracker server負責接收客戶端的請求，選擇合適的組合storage server。tracker server和storage server之間也會用心跳機制來檢測對方是否活著。tracker需要管理的資訊都放在記憶體中，並且裡面所有的tracker都是對等的 每個節點地位相同 容易擴充...
FastDFS介紹及使用
fastdfs是乙個分布式檔案系統 storage server 後簡稱storage 以組 卷，group或volume 為單位組織，乙個group內包含多台storage機器，資料互為備份，儲存空間以group內容量最小的storage為準，所以建議group內的多個storage盡量配置相同，...