FastDFS特性及問題思考

FastDFS是國人開發的一款分佈式文件系統，目前社區比較活躍。系統中存在三種節點：Client、Tracker、Storage，在底層存儲上經過邏輯的分組概念，使得經過在同組內配置多個Storage，從而實現軟RAID10，提高簡單負載均衡、併發IO的性能、及數據的冗餘備份；同時經過線性的添加新的邏輯存儲組，從容實現存儲容量的線性擴容。

文件下載上，除了支持經過API方式，目前還提供了apache和nginx的插件支持，同時也能夠不使用對應的插件，直接以Web靜態資源方式對外提供下載。目前FastDFS(V4.x)代碼量大概6w多行，內部的網絡模型使用比較成熟的libevent三方庫，具有高併發的處理能力。

特性

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下載，存在單點的性能瓶頸

問題分析：

從FastDFS的整個設計看，基本上都已簡單爲原則。好比以機器爲單位備份數據，簡化了tracker的管理工做；storage直接藉助本地文件系統原樣存儲文件，簡化了storage的管理工做；文件寫單份到storage即爲成功、而後後臺同步，簡化了寫文件流程。但簡單的方案能解決的問題一般也有限，FastDFS目前尚存在以下問題:

數據安全性：

>寫一份即成功：從源storage寫完文件至同步到組內其餘storage的時間窗口內，一旦源storage出現故障，就可能致使用戶數據丟失，而數據的丟失對存儲系統來講一般是不可接受的。

缺少自動化恢復機制：當storage的某塊磁盤故障時，只能換存磁盤，而後手動恢復數據；因爲按機器備份，彷佛也不可能有自動化恢復機制，除非有預先準備好的熱備磁盤，缺少自動化恢復機制會增長系統運維工做。
數據恢復效率低：恢復數據時，只能從group內其餘的storage讀取，同時因爲小文件的訪問效率自己較低，按文件恢復的效率也會很低，低的恢復效率也就意味着數據處於不安全狀態的時間更長。
缺少多機房容災支持：目前要作多機房容災，只能額外使用工具來將數據同步到備份的集羣，無自動化機制。

存儲空間利用率：

單機存儲的文件數受限於inode數量

每一個文件對應一個storage本地文件系統的文件，平均每一個文件會存在block_size/2的存儲空間浪費。
文件合併存儲能有效解決上述兩個問題，但因爲合併存儲沒有空間回收機制，刪除文件的空間不保證必定能複用，也存在空間浪費的問題

負載均衡：

group機制自己可用來作負載均衡，但這只是一種靜態的負載均衡機制，須要預先知道應用的訪問特性；同時group機制也致使不可能在group之間遷移數據來作動態負載均衡