（打算使用FastDFS來存儲商城的圖片，特地研究一下）nginx
文/餘慶程序員
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 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。
文件上傳和下載的交互過程
接下來咱們一塊兒看一下文件上傳和下載的交互過程。文件上傳和下載流程分別如圖二、圖3所示。文件上傳流程的步驟以下：
圖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期 http://www.programmer.com.cn/4380/）