文/余慶

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可以看出，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所示。 文件上傳 流程的步驟如下：

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期）