2010-11-25 10:59:57 來源：《程序員》
FastDFS是一款類Google FS的開源分布式文件系統(tǒng)，它用純C語言實(shí)現(xiàn)，支持Linux、FreeBSD、AIX等UNIX系統(tǒng)。它只能通過專有API對(duì)文件進(jìn)行存取訪問，不支持POSIX接口方式，不能mount使用。準(zhǔn)確地講，Google FS以及FastDFS、mogileFS、HDFS、TFS等類Google FS都不是系統(tǒng)級(jí)的分布式文件系統(tǒng)，而是應(yīng)用級(jí)的分布式文件存儲(chǔ)服務(wù)。
FastDFS的設(shè)計(jì)理念
FastDFS是為互聯(lián)網(wǎng)應(yīng)用量身定做的分布式文件系統(tǒng)，充分考慮了冗余備份、負(fù)載均衡、線性擴(kuò)容等機(jī)制，并注重高可用、高性能等指標(biāo)。和現(xiàn)有的類Google FS分布式文件系統(tǒng)相比，F(xiàn)astDFS的架構(gòu)和設(shè)計(jì)理念有其獨(dú)到之處，主要體現(xiàn)在輕量級(jí)、分組方式和對(duì)等結(jié)構(gòu)三個(gè)方面。
輕量級(jí)
FastDFS只有兩個(gè)角色：Tracker server和Storage server。Tracker server作為中心結(jié)點(diǎn)，其主要作用是負(fù)載均衡和調(diào)度。Tracker server在內(nèi)存中記錄分組和Storage server的狀態(tài)等信息，不記錄文件索引信息，占用的內(nèi)存量很少。另外，客戶端（應(yīng)用）和Storage server訪問Tracker server時(shí)，Tracker server掃描內(nèi)存中的分組和Storage server信息，然后給出應(yīng)答。由此可以看出Tracker server非常輕量化，不會(huì)成為系統(tǒng)瓶頸。
FastDFS中的Storage server在其他文件系統(tǒng)中通常稱作Trunk server或Data server。Storage server直接利用OS的文件系統(tǒng)存儲(chǔ)文件。FastDFS不會(huì)對(duì)文件進(jìn)行分塊存儲(chǔ)，客戶端上傳的文件和Storage server上的文件一一對(duì)應(yīng)。
眾所周知，大多數(shù)網(wǎng)站都需要存儲(chǔ)用戶上傳的文件，如圖片、視頻、電子文檔等。出于降低帶寬和存儲(chǔ)成本的考慮，網(wǎng)站通常都會(huì)限制用戶上傳的文件大小，例如圖片文件不能超過5MB、視頻文件不能超過100MB等。我認(rèn)為，對(duì)于互聯(lián)網(wǎng)應(yīng)用，文件分塊存儲(chǔ)沒有多大的必要。它既沒有帶來多大的好處，又增加了系統(tǒng)的復(fù)雜性。FastDFS不對(duì)文件進(jìn)行分塊存儲(chǔ)，與支持文件分塊存儲(chǔ)的DFS相比，更加簡潔高效，并且完全能滿足絕大多數(shù)互聯(lián)網(wǎng)應(yīng)用的實(shí)際需要。
在FastDFS中，客戶端上傳文件時(shí)，文件ID不是由客戶端指定，而是由Storage server生成后返回給客戶端的。文件ID中包含了組名、文件相對(duì)路徑和文件名，Storage server可以根據(jù)文件ID直接定位到文件。因此FastDFS集群中根本不需要存儲(chǔ)文件索引信息，這是FastDFS比較輕量級(jí)的一個(gè)例證。而其他文件系統(tǒng)則需要存儲(chǔ)文件索引信息，這樣的角色通常稱作NameServer。其中mogileFS采用MySQL數(shù)據(jù)庫來存儲(chǔ)文件索引以及系統(tǒng)相關(guān)的信息，其局限性顯而易見，MySQL將成為整個(gè)系統(tǒng)的瓶頸。
FastDFS輕量級(jí)的另外一個(gè)體現(xiàn)是代碼量較小。最新的V2.0包括了C客戶端API、FastDHT客戶端API和PHP extension等，代碼行數(shù)不到5.2萬行。
分組方式
類Google FS都支持文件冗余備份，例如Google FS、TFS的備份數(shù)是3。一個(gè)文件存儲(chǔ)到哪幾個(gè)存儲(chǔ)結(jié)點(diǎn)，通常采用動(dòng)態(tài)分配的方式。采用這種方式，一個(gè)文件存儲(chǔ)到的結(jié)點(diǎn)是不確定的。舉例說明，文件備份數(shù)是3，集群中有A、B、C、D四個(gè)存儲(chǔ)結(jié)點(diǎn)。文件1可能存儲(chǔ)在A、B、C三個(gè)結(jié)點(diǎn)，文件2可能存儲(chǔ)在B、C、D三個(gè)結(jié)點(diǎn)，文件3可能存儲(chǔ)在A、B、D三個(gè)結(jié)點(diǎn)。
FastDFS采用了分組存儲(chǔ)方式。集群由一個(gè)或多個(gè)組構(gòu)成，集群存儲(chǔ)總?cè)萘繛榧褐兴薪M的存儲(chǔ)容量之和。一個(gè)組由一臺(tái)或多臺(tái)存儲(chǔ)服務(wù)器組成，同組內(nèi)的多臺(tái)Storage server之間是互備關(guān)系，同組存儲(chǔ)服務(wù)器上的文件是完全一致的。文件上傳、下載、刪除等操作可以在組內(nèi)任意一臺(tái)Storage server上進(jìn)行。類似木桶短板效應(yīng)，一個(gè)組的存儲(chǔ)容量為該組內(nèi)存儲(chǔ)服務(wù)器容量最小的那個(gè)，由此可見組內(nèi)存儲(chǔ)服務(wù)器的軟硬件配置最好是一致的。
采用分組存儲(chǔ)方式的好處是靈活、可控性較強(qiáng)。比如上傳文件時(shí)，可以由客戶端直接指定上傳到的組。一個(gè)分組的存儲(chǔ)服務(wù)器訪問壓力較大時(shí)，可以在該組增加存儲(chǔ)服務(wù)器來擴(kuò)充服務(wù)能力（縱向擴(kuò)容）。當(dāng)系統(tǒng)容量不足時(shí)，可以增加組來擴(kuò)充存儲(chǔ)容量（橫向擴(kuò)容）。采用這樣的分組存儲(chǔ)方式，可以使用FastDFS對(duì)文件進(jìn)行管理，使用主流的Web server如Apache、nginx等進(jìn)行文件下載。
對(duì)等結(jié)構(gòu)
FastDFS集群中的Tracker server也可以有多臺(tái)，Tracker server和Storage server均不存在單點(diǎn)問題。Tracker server之間是對(duì)等關(guān)系，組內(nèi)的Storage server之間也是對(duì)等關(guān)系。傳統(tǒng)的Master-Slave結(jié)構(gòu)中的Master是單點(diǎn)，寫操作僅針對(duì)Master。如果Master失效，需要將Slave提升為Master，實(shí)現(xiàn)邏輯會(huì)比較復(fù)雜。和Master-Slave結(jié)構(gòu)相比，對(duì)等結(jié)構(gòu)中所有結(jié)點(diǎn)的地位是相同的，每個(gè)結(jié)點(diǎn)都是Master，不存在單點(diǎn)問題。
FastDFS的架構(gòu)
圖1展示的是FastDFS的系統(tǒng)架構(gòu)。
圖1 FastDFS的系統(tǒng)架構(gòu)
從圖1可以看出，Tracker server之間相互獨(dú)立，不存在直接聯(lián)系。
客戶端和Storage server主動(dòng)連接Tracker server。Storage server主動(dòng)向Tracker server報(bào)告其狀態(tài)信息，包括磁盤剩余空間、文件同步狀況、文件上傳下載次數(shù)等統(tǒng)計(jì)信息。Storage server會(huì)連接集群中所有的Tracker server，向他們報(bào)告自己的狀態(tài)。Storage server啟動(dòng)一個(gè)單獨(dú)的線程來完成對(duì)一臺(tái)Tracker server的連接和定時(shí)報(bào)告。需要說明的是，一個(gè)組包含的Storage server不是通過配置文件設(shè)定的，而是通過Tracker server獲取到的。
不同組的Storage server之間不會(huì)相互通信，同組內(nèi)的Storage server之間會(huì)相互連接進(jìn)行文件同步。
Storage server采用binlog文件記錄文件上傳、刪除等更新操作。binlog中只記錄文件名，不記錄文件內(nèi)容。
文件同步只在同組內(nèi)的Storage server之間進(jìn)行，采用push方式，即源頭服務(wù)器同步給目標(biāo)服務(wù)器。只有源頭數(shù)據(jù)才需要同步，備份數(shù)據(jù)并不需要再次同步，否則就構(gòu)成環(huán)路了。有個(gè)例外，就是新增加一臺(tái)Storage server時(shí)，由已有的一臺(tái)Storage server將已有的所有數(shù)據(jù)（包括源頭數(shù)據(jù)和備份數(shù)據(jù)）同步給該新增服務(wù)器。
Storage server中由專門的線程根據(jù)binlog進(jìn)行文件同步。為了最大程度地避免相互影響以及出于系統(tǒng)簡潔性考慮，Storage server對(duì)組內(nèi)除自己以外的每臺(tái)服務(wù)器都會(huì)啟動(dòng)一個(gè)線程來進(jìn)行文件同步。
文件同步采用增量同步方式，系統(tǒng)記錄已同步的位置（binlog文件偏移量）到標(biāo)識(shí)文件中。標(biāo)識(shí)文件名格式：{dest storage IP}_{port}.mark，例如：192.168.1.14_23000.mark。
[page] 文件上傳和下載的交互過程
接下來我們一起看一下文件上傳和下載的交互過程。文件上傳和下載流程分別如圖2、圖3所示。文件上傳流程的步驟如下：
圖2 文件上傳流程
圖3 文件下載流程
1. Client詢問Tracker server上傳到的Storage server；
2. Tracker server返回一臺(tái)可用的Storage server，返回的數(shù)據(jù)為該Storage server的IP地址和端口；
3. Client直接和該Storage server建立連接，進(jìn)行文件上傳，Storage server返回新生成的文件ID，文件上傳結(jié)束。
文件下載流程的步驟如下：
1. Client詢問Tracker server可以下載指定文件的Storage server，參數(shù)為文件ID（包含組名和文件名）；
2. Tracker server返回一臺(tái)可用的Storage server；
3. Client直接和該Storage server建立連接，完成文件下載。
文件同步延遲問題的提出
客戶端將一個(gè)文件上傳到一臺(tái)Storage server后，文件上傳工作就結(jié)束了。由該Storage server根據(jù)binlog中的上傳記錄將這個(gè)文件同步到同組的其他Storage server。這樣的文件同步方式是異步方式，異步方式帶來了文件同步延遲的問題。新上傳文件后，在尚未被同步過去的Storage server上訪問該文件，會(huì)出現(xiàn)找不到文件的現(xiàn)象。FastDFS是如何解決文件同步延遲這個(gè)問題的呢？
文件的訪問分為兩種情況：文件更新和文件下載。文件更新包括設(shè)置文件附加屬性和刪除文件。文件的附加屬性包括文件大小、圖片寬度、圖片高度等。FastDFS中，文件更新操作都會(huì)優(yōu)先選擇源Storage server，也就是該文件被上傳到的那臺(tái)Storage server。這樣的做法不僅避免了文件同步延遲的問題，而且有效地避免了在多臺(tái)Storage server上更新同一文件可能引起的時(shí)序錯(cuò)亂的問題。
那么文件下載是如何解決文件同步延遲這個(gè)問題的呢？
要回答這個(gè)問題，需要先了解文件名中包含了什么樣的信息。Storage server生成的文件名中，包含了源Storage server的IP地址和文件創(chuàng)建時(shí)間等字段。文件創(chuàng)建時(shí)間為UNIX時(shí)間戳，后面稱為文件時(shí)間戳。從文件名或文件ID中，可以反解出這兩個(gè)字段。
然后我們?cè)賮砜匆幌?，Tracker server是如何準(zhǔn)確地知道一個(gè)文件已被同步到一臺(tái)Storage server上的。前面已經(jīng)講過，文件同步采用主動(dòng)推送的方式。另外，每臺(tái)storage server都會(huì)定時(shí)向tracker server報(bào)告它向同組的其他storage server同步到的文件時(shí)間戳。當(dāng)tracker server收到一臺(tái)storage server的文件同步報(bào)告后，它會(huì)依次找出該組內(nèi)各個(gè)storage server（后稱作為S）被同步到的文件時(shí)間戳最小值，作為S的一個(gè)屬性記錄到內(nèi)存中。
FastDFS對(duì)文件同步延遲問題的解決方案
下面我們來看一下FastDFS采取的解決方法。
一個(gè)最簡單的解決辦法，和文件更新一樣，優(yōu)先選擇源Storage server下載文件即可。這可以在Tracker server的配置文件中設(shè)置，對(duì)應(yīng)的參數(shù)名為download_server。
另外一種選擇Storage server的方法是輪流選擇（round-robin）。當(dāng)Client詢問Tracker server有哪些Storage server可以下載指定文件時(shí)，Tracker server返回滿足如下四個(gè)條件之一的Storage server：
該文件上傳到的源Storage server，文件直接上傳到該服務(wù)器上的；
文件創(chuàng)建時(shí)間戳 < Storage server被同步到的文件時(shí)間戳，這意味著當(dāng)前文件已經(jīng)被同步過來了；
文件創(chuàng)建時(shí)間戳=Storage server被同步到的文件時(shí)間戳，且（當(dāng)前時(shí)間—文件創(chuàng)建時(shí)間戳） > 一個(gè)文件同步完成需要的最大時(shí)間（如5分鐘）；
?。ó?dāng)前時(shí)間—文件創(chuàng)建時(shí)間戳） > 文件同步延遲閾值，比如我們把閾值設(shè)置為1天，表示文件同步在一天內(nèi)肯定可以完成。
結(jié)束語
看了上面的介紹，你是否認(rèn)為FastDFS比較簡潔高效呢？原雅虎同事——一位比較資深的系統(tǒng)架構(gòu)師聽完FastDFS介紹后，作出這樣的評(píng)價(jià)：“FastDFS是窮人的解決方案”。他的意思是說FastDFS把簡潔和高效做到了極致，非常節(jié)約資源，中小網(wǎng)站完全用得起，這是對(duì)FastDFS的極大認(rèn)可和褒獎(jiǎng)。
FastDFS從2008年7月發(fā)布至今，已推出31個(gè)版本，后續(xù)完善和優(yōu)化工作正在持續(xù)進(jìn)行中。目前已有多家公司在生產(chǎn)環(huán)境中使用FastDFS，相信通過我們的不懈努力，F(xiàn)astDFS一定會(huì)越來越好！
作者簡介：
余慶，現(xiàn)在淘寶網(wǎng)Java中間件團(tuán)隊(duì)從事Java基礎(chǔ)平臺(tái)研發(fā)工作，有10年互聯(lián)網(wǎng)開發(fā)和架構(gòu)經(jīng)歷，曾擔(dān)任新浪網(wǎng)開發(fā)工程師、雅虎中國架構(gòu)師。開源分布式文件系統(tǒng)FastDFS和分布式哈希系統(tǒng)FastDHT的作者，對(duì)分布式數(shù)據(jù)存儲(chǔ)架構(gòu)有比較深入的研究。
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請(qǐng)及時(shí)通知本站，予以刪除。
搶沙發(fā)
