分佈式文件系統FastDFS架構認知

FastDFS是一款類Google FS的開源分佈式文件系統（應用級的分佈式文件存儲服務）。

FastDFS的設計理念

FastDFS是爲互聯網應用量身定作的分佈式文件系統，充分考慮了冗餘備份、負載均衡、線性擴容等機制，並注重高可用、高性能等指標。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上的文件一一對應。

在FastDFS中，客戶端上傳文件時，文件ID不是由客戶端指定，而是由Storage server生成後返回給客戶端的。文件ID中包含了組名、文件相對路徑和文件名，Storage server能夠根據文件ID直接定位到文件。所以FastDFS集羣中根本不須要存儲文件索引信息，這是FastDFS比較輕量級的一個例證。而其餘文件系統則須要存儲文件索引信息，這樣的角色一般稱做NameServer。其中mogileFS採用MySQL數據庫來存儲文件索引以及系統相關的信息，其侷限性顯而易見，mysql將成爲整個系統的瓶頸。

FastDFS輕量級的另一個體現是代碼量較小，代碼行數不到5.2萬行。

分組方式

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

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對組內除本身之外的每臺服務器都會啓動一個線程來進行文件同步。

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

文件上傳流程

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創建鏈接，完成文件下載。