FastDFS是一款類GoogleFS的開源分布式文件系統，它用純C語言實現，支持Linux、FreeBSD、AIX等UNIX系統。它只能通過專有API對文件進行存取訪問，不支持POSIX接口方式，不能mount使用。準確地講，GoogleFS以及FastDFS、mogileFS、HDFS、TFS等類GoogleFS都不是系統級的分布式文件系統，而是應用級的分布式文件存儲服務。

FastDFS的設計理念

FastDFS是為互聯網應用量身定做的分布式文件系統，充分考慮了冗余備份、負載均衡、線性擴容等機制，并注重高可用、高性能等指標。和現有的類Google FS分布式文件系統相比，FastDFS的架構和設計理念有其獨到之處，主要體現在輕量級、分組方式和對等結構三個方面。 #p#

輕量級

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萬行。 #p#

分組方式

類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等進行文件下載。 #p#

對等結構

FastDFS集群中的Tracker server也可以有多臺，Tracker server和Storage server均不存在單點問題。Tracker server之間是對等關系，組內的Storage server之間也是對等關系。傳統的Master-Slave結構中的Master是單點，寫操作僅針對Master。如果Master失效，需要將Slave提升為Master，實現邏輯會比較復雜。和Master-Slave結構相比，對等結構中所有結點的地位是相同的，每個結點都是Master，不存在單點問題。 #p#

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。 #p#

文件上傳和下載的交互過程

接下來我們一起看一下文件上傳和下載的交互過程。文件上傳和下載流程分別如圖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，文件上傳結束。 #p#

文件下載流程的步驟如下：

1. Client詢問Tracker server可以下載指定文件的Storage server，參數為文件ID（包含組名和文件名）；

2. Tracker server返回一臺可用的Storage server；

3. Client直接和該Storage server建立連接，完成文件下載。 #p#

文件同步延遲問題的提出

客戶端將一個文件上傳到一臺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的一個屬性記錄到內存中。 #p#

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天，表示文件同步在一天內肯定可以完成。 #p#

結束語

看了上面的介紹，你是否認為FastDFS比較簡潔高效呢？原雅虎同事——一位比較資深的系統架構師聽完FastDFS介紹后，作出這樣的評價：“FastDFS是窮人的解決方案”。他的意思是說FastDFS把簡潔和高效做到了***，非常節約資源，中小網站完全用得起，這是對FastDFS的極大認可和褒獎。

FastDFS從2008年7月發布至今，已推出31個版本，后續完善和優化工作正在持續進行中。目前已有多家公司在生產環境中使用FastDFS，相信通過我們的不懈努力，FastDFS一定會越來越好！

作者簡介：

余慶，現在淘寶網Java中間件團隊從事Java基礎平臺研發工作，有10年互聯網開發和架構經歷，曾擔任新浪網開發工程師、雅虎中國架構師。開源分布式文件系統FastDFS和分布式哈希系統FastDHT的作者，對分布式數據存儲架構有比較深入的研究。