文/餘慶
FastDFS是一款類Google FS的開源分佈式文件系統，它用純C語言實現，支持Linux、FreeBSD、AIX等UNIX系統。它只能通過專有API對文件進行存取訪問，不支持POSIX接口方式，不能mount使用。準確地講，Google FS以及FastDFS、mogileFS、HDFS、TFS等類Google FS都不是系統級的分佈式文件系統，而是應用級的分佈式文件存儲服務。
FastDFS的設計理念
FastDFS是爲互聯網應用量身定做的分佈式文件系統，充分考慮了冗餘備份、負載均衡、線性擴容等機制，並注重高可用、高性能等指標。和現有的類Google FS分佈式文件系統相比，FastDFS的架構和設計理念有其獨到之處，主要體現在輕量級、分組方式和對等結構三個方面。
輕量級
FastDFS只有兩個角色：Tracker server和Storage server。Tracker server作爲中心結點，其主要作用是負載均衡和調度。Tracker server在內存中記錄分組和Storage server的狀態等信息，不記錄文件索引信息，佔用的內存量很少。另外，客戶端（應用）和Storage server訪問Tracker server時，Tracker server掃描內存中的分組和Storage server信息，然後給出應答。由此可以看出Tracker server非常輕量化，不會成爲系統瓶頸。
FastDFS中的Storage server在其他文件系統中通常稱作Trunk server或Data server。Storage server直接利用OS的文件系統存儲文件。FastDFS不會對文件進行分塊存儲，客戶端上傳的文件和Storage server上的文件一一對應。
衆所周知，大多數網站都需要存儲用戶上傳的文件，如圖片、視頻、電子文檔等。出於降低帶寬和存儲成本的考慮，網站通常都會限制用戶上傳的文件大小，例如圖片文件不能超過5MB、視頻文件不能超過100MB等。我認爲，對於互聯網應用，文件分塊存儲沒有多大的必要。它既沒有帶來多大的好處，又增加了系統的複雜性。FastDFS不對文件進行分塊存儲，與支持文件分塊存儲的DFS相比，更加簡潔高效，並且完全能滿足絕大多數互聯網應用的實際需要。
在FastDFS中，客戶端上傳文件時，文件ID不是由客戶端指定，而是由Storage server生成後返回給客戶端的。文件ID中包含了組名、文件相對路徑和文件名，Storage server可以根據文件ID直接定位到文件。因此FastDFS集羣中根本不需要存儲文件索引信息，這是FastDFS比較輕量級的一個例證。而其他文件系統則需要存儲文件索引信息，這樣的角色通常稱作NameServer。其中mogileFS採用MySQL數據庫來存儲文件索引以及系統相關的信息，其侷限性顯而易見，MySQL將成爲整個系統的瓶頸。
FastDFS輕量級的另外一個體現是代碼量較小。最新的V2.0包括了C客戶端API、FastDHT客戶端API和PHP extension等，代碼行數不到5.2萬行。
分組方式
類Google FS都支持文件冗餘備份，例如Google FS、TFS的備份數是3。一個文件存儲到哪幾個存儲結點，通常採用動態分配的方式。採用這種方式，一個文件存儲到的結點是不確定的。舉例說明，文件備份數是3，集羣中有A、B、C、D四個存儲結點。文件1可能存儲在A、B、C三個結點，文件2可能存儲在B、C、D三個結點，文件3可能存儲在A、B、D三個結點。
FastDFS採用了分組存儲方式。集羣由一個或多個組構成，集羣存儲總容量爲集羣中所有組的存儲容量之和。一個組由一臺或多臺存儲服務器組成，同組內的多臺Storage server之間是互備關係，同組存儲服務器上的文件是完全一致的。文件上傳、下載、刪除等操作可以在組內任意一臺Storage server上進行。類似木桶短板效應，一個組的存儲容量爲該組內存儲服務器容量最小的那個，由此可見組內存儲服務器的軟硬件配置最好是一致的。
採用分組存儲方式的好處是靈活、可控性較強。比如上傳文件時，可以由客戶端直接指定上傳到的組。一個分組的存儲服務器訪問壓力較大時，可以在該組增加存儲服務器來擴充服務能力（縱向擴容）。當系統容量不足時，可以增加組來擴充存儲容量（橫向擴容）。採用這樣的分組存儲方式，可以使用FastDFS對文件進行管理，使用主流的Web server如Apache、nginx等進行文件下載。
對等結構
FastDFS集羣中的Tracker server也可以有多臺，Tracker server和Storage server均不存在單點問題。Tracker server之間是對等關係，組內的Storage server之間也是對等關係。傳統的Master-Slave結構中的Master是單點，寫操作僅針對Master。如果Master失效，需要將Slave提升爲Master，實現邏輯會比較複雜。和Master-Slave結構相比，對等結構中所有結點的地位是相同的，每個結點都是Master，不存在單點問題。
FastDFS的架構
圖1展示的是FastDFS的系統架構。
圖1 FastDFS的系統架構
從圖1可以看出，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 server採用binlog文件記錄文件上傳、刪除等更新操作。binlog中只記錄文件名，不記錄文件內容。
文件同步只在同組內的Storage server之間進行，採用push方式，即源頭服務器同步給目標服務器。只有源頭數據才需要同步，備份數據並不需要再次同步，否則就構成環路了。有個例外，就是新增加一臺Storage server時，由已有的一臺Storage server將已有的所有數據（包括源頭數據和備份數據）同步給該新增服務器。
Storage server中由專門的線程根據binlog進行文件同步。爲了最大程度地避免相互影響以及出於系統簡潔性考慮，Storage server對組內除自己以外的每臺服務器都會啓動一個線程來進行文件同步。
文件同步採用增量同步方式，系統記錄已同步的位置（binlog文件偏移量）到標識文件中。標識文件名格式：{dest storage IP}_{port}.mark，例如：192.168.1.14_23000.mark。
文件上傳和下載的交互過程
接下來我們一起看一下文件上傳和下載的交互過程。文件上傳和下載流程分別如圖2、圖3所示。文件上傳流程的步驟如下：
圖2 文件上傳流程
圖3 文件下載流程
1. Client詢問Tracker server上傳到的Storage server；
2. Tracker server返回一臺可用的Storage server，返回的數據爲該Storage server的IP地址和端口；
3. Client直接和該Storage server建立連接，進行文件上傳，Storage server返回新生成的文件ID，文件上傳結束。
文件下載流程的步驟如下：
1. Client詢問Tracker server可以下載指定文件的Storage server，參數爲文件ID（包含組名和文件名）；
2. Tracker server返回一臺可用的Storage server；
3. Client直接和該Storage server建立連接，完成文件下載。
文件同步延遲問題的提出
客戶端將一個文件上傳到一臺Storage server後，文件上傳工作就結束了。由該Storage server根據binlog中的上傳記錄將這個文件同步到同組的其他Storage server。這樣的文件同步方式是異步方式，異步方式帶來了文件同步延遲的問題。新上傳文件後，在尚未被同步過去的Storage server上訪問該文件，會出現找不到文件的現象。FastDFS是如何解決文件同步延遲這個問題的呢？
文件的訪問分爲兩種情況：文件更新和文件下載。文件更新包括設置文件附加屬性和刪除文件。文件的附加屬性包括文件大小、圖片寬度、圖片高度等。FastDFS中，文件更新操作都會優先選擇源Storage server，也就是該文件被上傳到的那臺Storage server。這樣的做法不僅避免了文件同步延遲的問題，而且有效地避免了在多臺Storage server上更新同一文件可能引起的時序錯亂的問題。
那麼文件下載是如何解決文件同步延遲這個問題的呢？
要回答這個問題，需要先了解文件名中包含了什麼樣的信息。Storage server生成的文件名中，包含了源Storage server的IP地址和文件創建時間等字段。文件創建時間爲UNIX時間戳，後面稱爲文件時間戳。從文件名或文件ID中，可以反解出這兩個字段。
然後我們再來看一下，Tracker server是如何準確地知道一個文件已被同步到一臺Storage server上的。前面已經講過，文件同步採用主動推送的方式。另外，每臺storage server都會定時向tracker server報告它向同組的其他storage server同步到的文件時間戳。當tracker server收到一臺storage server的文件同步報告後，它會依次找出該組內各個storage server（後稱作爲S）被同步到的文件時間戳最小值，作爲S的一個屬性記錄到內存中。
FastDFS對文件同步延遲問題的解決方案
下面我們來看一下FastDFS採取的解決方法。
一個最簡單的解決辦法，和文件更新一樣，優先選擇源Storage server下載文件即可。這可以在Tracker server的配置文件中設置，對應的參數名爲download_server。
另外一種選擇Storage server的方法是輪流選擇（round-robin）。當Client詢問Tracker server有哪些Storage server可以下載指定文件時，Tracker server返回滿足如下四個條件之一的Storage server：
該文件上傳到的源Storage server，文件直接上傳到該服務器上的；
文件創建時間戳 < Storage server被同步到的文件時間戳，這意味着當前文件已經被同步過來了；
文件創建時間戳=Storage server被同步到的文件時間戳，且（當前時間—文件創建時間戳） > 一個文件同步完成需要的最大時間（如5分鐘）；
（當前時間—文件創建時間戳） > 文件同步延遲閾值，比如我們把閾值設置爲1天，表示文件同步在一天內肯定可以完成。
結束語
看了上面的介紹，你是否認爲FastDFS比較簡潔高效呢？原雅虎同事——一位比較資深的系統架構師聽完FastDFS介紹後，作出這樣的評價：“FastDFS是窮人的解決方案”。他的意思是說FastDFS把簡潔和高效做到了極致，非常節約資源，中小網站完全用得起，這是對FastDFS的極大認可和褒獎。
FastDFS從2008年7月發佈至今，已推出31個版本，後續完善和優化工作正在持續進行中。目前已有多家公司在生產環境中使用FastDFS，相信通過我們的不懈努力，FastDFS一定會越來越好！
作者簡介：
餘慶，現在淘寶網Java中間件團隊從事Java基礎平臺研發工作，有10年互聯網開發和架構經歷，曾擔任新浪網開發工程師、雅虎中國架構師。開源分佈式文件系統FastDFS和分佈式哈希系統FastDHT的作者，對分佈式數據存儲架構有比較深入的研究。
（本文來自《程序員》雜誌10年11期）