文/余慶

FastDFS是一款類Google?FS的開源分布式文件系統(tǒng)，它用純C語言實現(xiàn)，支持Linux、FreeBSD、AIX等UNIX系統(tǒng)。它只 能通過專有API對文件進行存取訪問，不支持POSIX接口方式，不能mount使用。準(zhǔn)確地講，Google?FS以及FastDFS、 mogileFS、HDFS、TFS等類Google?FS都不是系統(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)三個方面。

輕量級

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

分組方式

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

對等結(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，不存在單點問題。

FastDFS的架構(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。

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

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

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

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

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

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

文件同步延遲問題的提出

客戶端將一個 文件上傳 到一臺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是如何準(zhǔn)確地知道一個文件已被同步到一臺Storage?server上的。前面已經(jīng)講過，文件 同步采用主動推送的方式。另外，每臺storage?server都會定時向tracker?server報告它向同組的其他 storage?server同步到的文件時間戳。當(dāng)tracker?server收到一臺storage?server的文件同步報告后，它會依次找出 該組內(nèi)各個storage?server（后稱作為S）被同步到的文件時間戳最小值，作為S的一個屬性記錄到內(nèi)存中。

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)肯定可以完成。

結(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)有比較深入的研究。

（本文來自《程序員》雜志10年11期）