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之間遷移數據來做動態負載均衡