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

FastDFS的設(shè)計理念

FastDFS是為互聯(lián)網(wǎng)應(yīng)用量身定做的分布式文件系統(tǒng)，充分考慮了冗余備份、負載均衡、線性擴容等機制，并注重高可用、高性能等指標(biāo)。和現(xiàn)有的類Google FS分布式文件系統(tǒng)相比，F(xiàn)astDFS的架構(gòu)和設(shè)計理念有其獨到之處，主要體現(xiàn)在輕量級、分組方式和對等結(jié)構(gòu)三個方面。 #p#

輕量級

FastDFS只有兩個角色：Tracker server和Storage server。Tracker server作為中心結(jié)點，其主要作用是負載均衡和調(diào)度。Tracker server在內(nèi)存中記錄分組和Storage server的狀態(tài)等信息，不記錄文件索引信息，占用的內(nèi)存量很少。另外，客戶端（應(yīng)用）和Storage server訪問Tracker server時，Tracker server掃描內(nèi)存中的分組和Storage server信息，然后給出應(yīng)答。由此可以看出Tracker server非常輕量化，不會成為系統(tǒng)瓶頸。

FastDFS中的Storage server在其他文件系統(tǒng)中通常稱作Trunk server或Data server。Storage server直接利用OS的文件系統(tǒng)存儲文件。FastDFS不會對文件進行分塊存儲，客戶端上傳的文件和Storage server上的文件一一對應(yīng)。

眾所周知，大多數(shù)網(wǎng)站都需要存儲用戶上傳的文件，如圖片、視頻、電子文檔等。出于降低帶寬和存儲成本的考慮，網(wǎng)站通常都會限制用戶上傳的文件大小，例如圖片文件不能超過5MB、視頻文件不能超過100MB等。我認為，對于互聯(lián)網(wǎng)應(yīng)用，文件分塊存儲沒有多大的必要。它既沒有帶來多大的好處，又增加了系統(tǒng)的復(fù)雜性。FastDFS不對文件進行分塊存儲，與支持文件分塊存儲的DFS相比，更加簡潔高效，并且完全能滿足絕大多數(shù)互聯(lián)網(wǎng)應(yīng)用的實際需要。

在FastDFS中，客戶端上傳文件時，文件ID不是由客戶端指定，而是由Storage server生成后返回給客戶端的。文件ID中包含了組名、文件相對路徑和文件名，Storage server可以根據(jù)文件ID直接定位到文件。因此FastDFS集群中根本不需要存儲文件索引信息，這是FastDFS比較輕量級的一個例證。而其他文件系統(tǒng)則需要存儲文件索引信息，這樣的角色通常稱作NameServer。其中mogileFS采用MySQL數(shù)據(jù)庫來存儲文件索引以及系統(tǒng)相關(guān)的信息，其局限性顯而易見，MySQL將成為整個系統(tǒng)的瓶頸。

FastDFS輕量級的另外一個體現(xiàn)是代碼量較小。***的V2.0包括了C客戶端API、FastDHT客戶端API和PHP extension等，代碼行數(shù)不到5.2萬行。 #p#

分組方式

類Google FS都支持文件冗余備份，例如Google FS、TFS的備份數(shù)是3。一個文件存儲到哪幾個存儲結(jié)點，通常采用動態(tài)分配的方式。采用這種方式，一個文件存儲到的結(jié)點是不確定的。舉例說明，文件備份數(shù)是3，集群中有A、B、C、D四個存儲結(jié)點。文件1可能存儲在A、B、C三個結(jié)點，文件2可能存儲在B、C、D三個結(jié)點，文件3可能存儲在A、B、D三個結(jié)點。

FastDFS采用了分組存儲方式。集群由一個或多個組構(gòu)成，集群存儲總?cè)萘繛榧褐兴薪M的存儲容量之和。一個組由一臺或多臺存儲服務(wù)器組成，同組內(nèi)的多臺Storage server之間是互備關(guān)系，同組存儲服務(wù)器上的文件是完全一致的。文件上傳、下載、刪除等操作可以在組內(nèi)任意一臺Storage server上進行。類似木桶短板效應(yīng)，一個組的存儲容量為該組內(nèi)存儲服務(wù)器容量最小的那個，由此可見組內(nèi)存儲服務(wù)器的軟硬件配置***是一致的。

采用分組存儲方式的好處是靈活、可控性較強。比如上傳文件時，可以由客戶端直接指定上傳到的組。一個分組的存儲服務(wù)器訪問壓力較大時，可以在該組增加存儲服務(wù)器來擴充服務(wù)能力（縱向擴容）。當(dāng)系統(tǒng)容量不足時，可以增加組來擴充存儲容量（橫向擴容）。采用這樣的分組存儲方式，可以使用FastDFS對文件進行管理，使用主流的Web server如Apache、nginx等進行文件下載。 #p#

對等結(jié)構(gòu)

FastDFS集群中的Tracker server也可以有多臺，Tracker server和Storage server均不存在單點問題。Tracker server之間是對等關(guān)系，組內(nèi)的Storage server之間也是對等關(guān)系。傳統(tǒng)的Master-Slave結(jié)構(gòu)中的Master是單點，寫操作僅針對Master。如果Master失效，需要將Slave提升為Master，實現(xiàn)邏輯會比較復(fù)雜。和Master-Slave結(jié)構(gòu)相比，對等結(jié)構(gòu)中所有結(jié)點的地位是相同的，每個結(jié)點都是Master，不存在單點問題。 #p#

FastDFS的架構(gòu)

圖1展示的是FastDFS的系統(tǒng)架構(gòu)。

圖1 FastDFS的系統(tǒng)架構(gòu)

從圖1可以看出，Tracker server之間相互獨立，不存在直接聯(lián)系。

客戶端和Storage server主動連接Tracker server。Storage server主動向Tracker server報告其狀態(tài)信息，包括磁盤剩余空間、文件同步狀況、文件上傳下載次數(shù)等統(tǒng)計信息。Storage server會連接集群中所有的Tracker server，向他們報告自己的狀態(tài)。Storage server啟動一個單獨的線程來完成對一臺Tracker server的連接和定時報告。需要說明的是，一個組包含的Storage server不是通過配置文件設(shè)定的，而是通過Tracker server獲取到的。

不同組的Storage server之間不會相互通信，同組內(nèi)的Storage server之間會相互連接進行文件同步。

Storage server采用binlog文件記錄文件上傳、刪除等更新操作。binlog中只記錄文件名，不記錄文件內(nèi)容。

文件同步只在同組內(nèi)的Storage server之間進行，采用push方式，即源頭服務(wù)器同步給目標(biāo)服務(wù)器。只有源頭數(shù)據(jù)才需要同步，備份數(shù)據(jù)并不需要再次同步，否則就構(gòu)成環(huán)路了。有個例外，就是新增加一臺Storage server時，由已有的一臺Storage server將已有的所有數(shù)據(jù)（包括源頭數(shù)據(jù)和備份數(shù)據(jù)）同步給該新增服務(wù)器。

Storage server中由專門的線程根據(jù)binlog進行文件同步。為了***程度地避免相互影響以及出于系統(tǒng)簡潔性考慮，Storage server對組內(nèi)除自己以外的每臺服務(wù)器都會啟動一個線程來進行文件同步。

文件同步采用增量同步方式，系統(tǒng)記錄已同步的位置（binlog文件偏移量）到標(biāo)識文件中。標(biāo)識文件名格式：{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，返回的數(shù)據(jù)為該Storage server的IP地址和端口；

3. Client直接和該Storage server建立連接，進行文件上傳，Storage server返回新生成的文件ID，文件上傳結(jié)束。 #p#

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

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

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

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

文件同步延遲問題的提出

客戶端將一個文件上傳到一臺Storage server后，文件上傳工作就結(jié)束了。由該Storage server根據(jù)binlog中的上傳記錄將這個文件同步到同組的其他Storage server。這樣的文件同步方式是異步方式，異步方式帶來了文件同步延遲的問題。新上傳文件后，在尚未被同步過去的Storage server上訪問該文件，會出現(xiàn)找不到文件的現(xiàn)象。FastDFS是如何解決文件同步延遲這個問題的呢？

文件的訪問分為兩種情況：文件更新和文件下載。文件更新包括設(shè)置文件附加屬性和刪除文件。文件的附加屬性包括文件大小、圖片寬度、圖片高度等。FastDFS中，文件更新操作都會優(yōu)先選擇源Storage server，也就是該文件被上傳到的那臺Storage server。這樣的做法不僅避免了文件同步延遲的問題，而且有效地避免了在多臺Storage server上更新同一文件可能引起的時序錯亂的問題。

那么文件下載是如何解決文件同步延遲這個問題的呢？

要回答這個問題，需要先了解文件名中包含了什么樣的信息。Storage server生成的文件名中，包含了源Storage server的IP地址和文件創(chuàng)建時間等字段。文件創(chuàng)建時間為UNIX時間戳，后面稱為文件時間戳。從文件名或文件ID中，可以反解出這兩個字段。

然后我們再來看一下，Tracker server是如何準確地知道一個文件已被同步到一臺Storage server上的。前面已經(jīng)講過，文件同步采用主動推送的方式。另外，每臺storage server都會定時向tracker server報告它向同組的其他storage server同步到的文件時間戳。當(dāng)tracker server收到一臺storage server的文件同步報告后，它會依次找出該組內(nèi)各個storage server（后稱作為S）被同步到的文件時間戳最小值，作為S的一個屬性記錄到內(nèi)存中。 #p#

FastDFS對文件同步延遲問題的解決方案

下面我們來看一下FastDFS采取的解決方法。

一個最簡單的解決辦法，和文件更新一樣，優(yōu)先選擇源Storage server下載文件即可。這可以在Tracker server的配置文件中設(shè)置，對應(yīng)的參數(shù)名為download_server。

另外一種選擇Storage server的方法是輪流選擇（round-robin）。當(dāng)Client詢問Tracker server有哪些Storage server可以下載指定文件時，Tracker server返回滿足如下四個條件之一的Storage server：

• 該文件上傳到的源Storage server，文件直接上傳到該服務(wù)器上的；
• 文件創(chuàng)建時間戳 < Storage server被同步到的文件時間戳，這意味著當(dāng)前文件已經(jīng)被同步過來了；
• 文件創(chuàng)建時間戳=Storage server被同步到的文件時間戳，且（當(dāng)前時間—文件創(chuàng)建時間戳） > 一個文件同步完成需要的***時間（如5分鐘）；
• （當(dāng)前時間—文件創(chuàng)建時間戳） > 文件同步延遲閾值，比如我們把閾值設(shè)置為1天，表示文件同步在一天內(nèi)肯定可以完成。 #p#

結(jié)束語

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

FastDFS從2008年7月發(fā)布至今，已推出31個版本，后續(xù)完善和優(yōu)化工作正在持續(xù)進行中。目前已有多家公司在生產(chǎn)環(huán)境中使用FastDFS，相信通過我們的不懈努力，F(xiàn)astDFS一定會越來越好！

作者簡介：

余慶，現(xiàn)在淘寶網(wǎng)Java中間件團隊從事Java基礎(chǔ)平臺研發(fā)工作，有10年互聯(lián)網(wǎng)開發(fā)和架構(gòu)經(jīng)歷，曾擔(dān)任新浪網(wǎng)開發(fā)工程師、雅虎中國架構(gòu)師。開源分布式文件系統(tǒng)FastDFS和分布式哈希系統(tǒng)FastDHT的作者，對分布式數(shù)據(jù)存儲架構(gòu)有比較深入的研究。