分佈式文件系統FastDFS詳解

時間 2019-11-30

原文原文鏈接

爲何要使用分佈式文件系統呢？

嗯，這個問題問的好，使用了它對咱們有哪些好處？帶着這個問題咱們來往下看：html

單機時代

初創時期因爲時間緊迫，在各類資源有限的狀況下，一般就直接在項目目錄下創建靜態文件夾，用於用戶存放項目中的文件資源。若是按不一樣類型再細分，能夠在項目目錄下再創建不一樣的子目錄來區分。例如：resources\static\file、resources\static\img等。前端

優勢：這樣作比較便利，項目直接引用就行，實現起來也簡單，無需任何複雜技術，保存數據庫記錄和訪問起來也很方便。算法

缺點：若是隻是後臺系統的使用通常也不會有什麼問題，可是做爲一個前端網站使用的話就會存在弊端。一方面，文件和代碼耦合在一塊兒，文件越多存放越混亂；另外一方面，若是流量比較大，靜態文件訪問會佔據必定的資源，影響正常業務進行，不利於網站快速發展。數據庫

獨立文件服務器

隨着公司業務不斷髮展，將代碼和文件放在同一服務器的弊端就會愈來愈明顯。爲了解決上面的問題引入獨立圖片服務器，工做流程以下：項目上傳文件時，首先經過ftp或者ssh將文件上傳到圖片服務器的某個目錄下，再經過ngnix或者apache來訪問此目錄下的文件，返回一個獨立域名的圖片URL地址，前端使用文件時就經過這個URL地址讀取。apache

優勢：圖片訪問是很消耗服務器資源的（由於會涉及到操做系統的上下文切換和磁盤I/O操做），分離出來後，Web/App服務器能夠更專一發揮動態處理的能力；獨立存儲，更方便作擴容、容災和數據遷移；方便作圖片訪問請求的負載均衡，方便應用各類緩存策略（HTTP Header、Proxy Cache等），也更加方便遷移到CDN。緩存

缺點：單機存在性能瓶頸，容災、垂直擴展性稍差服務器

分佈式文件系統

經過獨立文件服務器能夠解決一些問題，若是某天存儲文件的那臺服務忽然down了怎麼辦？可能你會說，定時將文件系統備份，這臺down機的時候，迅速切換到另外一臺就OK了，可是這樣處理須要人工來干預。另外，當存儲的文件超過100T的時候怎麼辦？單臺服務器的性能問題？這個時候咱們就應該考慮分佈式文件系統了。網絡

業務繼續發展，單臺服務器存儲和響應也很快到達了瓶頸，新的業務須要文件訪問具備高響應性、高可用性來支持系統。分佈式文件系統，通常分爲三塊內容來配合，服務的存儲、訪問的仲裁系統，文件存儲系統，文件的容災系統來構成，仲裁系統至關於文件服務器的大腦，根據必定的算法來決定文件存儲的位置，文件存儲系統負責保存文件，容災系統負責文件系統和本身的相互備份。架構

優勢：擴展能力: 毫無疑問，擴展能力是一個分佈式文件系統最重要的特色；高可用性: 在分佈式文件系統中，高可用性包含兩層，一是整個文件系統的可用性，二是數據的完整和一致性；彈性存儲: 能夠根據業務須要靈活地增長或縮減數據存儲以及增刪存儲池中的資源，而不須要中斷系統運行併發

缺點：系統複雜度稍高，須要更多服務器

FastDFS

毫無疑問FastDFS就屬於咱們上面介紹的分佈式文件系統，下面咱們來詳細瞭解一下：

什麼是FastDFS

FastDFS是一個開源的輕量級分佈式文件系統。它解決了大數據量存儲和負載均衡等問題。特別適合以中小文件（建議範圍：4KB < file_size <500MB）爲載體的在線服務，如相冊網站、視頻網站等等。在UC基於FastDFS開發向用戶提供了：網盤，社區，廣告和應用下載等業務的存儲服務。

FastDFS是一款開源的輕量級分佈式文件系統純C實現，支持Linux、FreeBSD等UNIX系統類google FS，不是通用的文件系統，只能經過專有API訪問，目前提供了C、Java和PHP API爲互聯網應用量身定作，解決大容量文件存儲問題，追求高性能和高擴展性FastDFS能夠看作是基於文件的key value pair存儲系統，稱做分佈式文件存儲服務更爲合適。

FastDFS特性：

文件不分塊存儲，上傳的文件和OS文件系統中的文件一一對應
支持相同內容的文件只保存一份，節約磁盤空間
下載文件支持HTTP協議，可使用內置Web Server，也能夠和其餘Web Server配合使用
支持在線擴容
支持主從文件
存儲服務器上能夠保存文件屬性（meta-data）V2.0網絡通訊採用libevent，支持大併發訪問，總體性能更好

FastDFS相關概念

FastDFS服務端有三個角色：跟蹤服務器（tracker server）、存儲服務器（storage server）和客戶端（client）。

tracker server：跟蹤服務器，主要作調度工做，起負載均衡的做用。在內存中記錄集羣中全部存儲組和存儲服務器的狀態信息，是客戶端和數據服務器交互的樞紐。相比GFS中的master更爲精簡，不記錄文件索引信息，佔用的內存量不多。

Tracker是FastDFS的協調者，負責管理全部的storage server和group，每一個storage在啓動後會鏈接Tracker，告知本身所屬的group等信息，並保持週期性的心跳，tracker根據storage的心跳信息，創建group==>[storage server list]的映射表。

Tracker須要管理的元信息不多，會所有存儲在內存中；另外tracker上的元信息都是由storage彙報的信息生成的，自己不須要持久化任何數據，這樣使得tracker很是容易擴展，直接增長tracker機器便可擴展爲tracker cluster來服務，cluster裏每一個tracker之間是徹底對等的，全部的tracker都接受stroage的心跳信息，生成元數據信息來提供讀寫服務。

storage server：存儲服務器（又稱：存儲節點或數據服務器），文件和文件屬性（meta data）都保存到存儲服務器上。Storage server直接利用OS的文件系統調用管理文件。

Storage server（後簡稱storage）以組（卷，group或volume）爲單位組織，一個group內包含多臺storage機器，數據互爲備份，存儲空間以group內容量最小的storage爲準，因此建議group內的多個storage儘可能配置相同，以避免形成存儲空間的浪費。

以group爲單位組織存儲能方便的進行應用隔離、負載均衡、副本數定製（group內storage server數量即爲該group的副本數），好比將不一樣應用數據存到不一樣的group就能隔離應用數據，同時還可根據應用的訪問特性來將應用分配到不一樣的group來作負載均衡；缺點是group的容量受單機存儲容量的限制，同時當group內有機器壞掉時，數據恢復只能依賴group內地其餘機器，使得恢復時間會很長。

group內每一個storage的存儲依賴於本地文件系統，storage可配置多個數據存儲目錄，好比有10塊磁盤，分別掛載在/data/disk1-/data/disk10，則可將這10個目錄都配置爲storage的數據存儲目錄。

storage接受到寫文件請求時，會根據配置好的規則（後面會介紹），選擇其中一個存儲目錄來存儲文件。爲了不單個目錄下的文件數太多，在storage第一次啓動時，會在每一個數據存儲目錄裏建立2級子目錄，每級256個，總共65536個文件，新寫的文件會以hash的方式被路由到其中某個子目錄下，而後將文件數據直接做爲一個本地文件存儲到該目錄中。

client：客戶端，做爲業務請求的發起方，經過專有接口，使用TCP/IP協議與跟蹤器服務器或存儲節點進行數據交互。FastDFS向使用者提供基本文件訪問接口，好比upload、download、append、delete等，以客戶端庫的方式提供給用戶使用。

另外兩個概念：

group ：組，也可稱爲卷。同組內服務器上的文件是徹底相同的，同一組內的storage server之間是對等的，文件上傳、刪除等操做能夠在任意一臺storage server上進行。

meta data ：文件相關屬性，鍵值對（ Key Value Pair）方式，如：width=1024,heigth=768 。

Tracker至關於FastDFS的大腦，不管是上傳仍是下載都是經過tracker來分配資源；客戶端通常可使用ngnix等靜態服務器來調用或者作一部分的緩存；存儲服務器內部分爲卷（或者叫作組），卷於卷之間是平行的關係，能夠根據資源的使用狀況隨時增長，卷內服務器文件相互同步備份，以達到容災的目的。

上傳機制

首先客戶端請求Tracker服務獲取到存儲服務器的ip地址和端口，而後客戶端根據返回的IP地址和端口號請求上傳文件，存儲服務器接收到請求後生產文件，而且將文件內容寫入磁盤並返回給客戶端file_id、路徑信息、文件名等信息，客戶端保存相關信息上傳完畢。

內部機制以下：

一、選擇tracker server

當集羣中不止一個tracker server時，因爲tracker之間是徹底對等的關係，客戶端在upload文件時能夠任意選擇一個trakcer。選擇存儲的group 當tracker接收到upload file的請求時，會爲該文件分配一個能夠存儲該文件的group，支持以下選擇group的規則：

一、Round robin，全部的group間輪詢
二、Specified group，指定某一個肯定的group
三、Load balance，剩餘存儲空間多多group優先

二、選擇storage server

當選定group後，tracker會在group內選擇一個storage server給客戶端，支持以下選擇storage的規則：

一、Round robin，在group內的全部storage間輪詢
二、First server ordered by ip，按ip排序
三、First server ordered by priority，按優先級排序（優先級在storage上配置）

三、選擇storage path

當分配好storage server後，客戶端將向storage發送寫文件請求，storage將會爲文件分配一個數據存儲目錄，支持以下規則：

一、Round robin，多個存儲目錄間輪詢
二、剩餘存儲空間最多的優先

四、生成Fileid

選定存儲目錄以後，storage會爲文件生一個Fileid，由storage server ip、文件建立時間、文件大小、文件crc32和一個隨機數拼接而成，而後將這個二進制串進行base64編碼，轉換爲可打印的字符串。選擇兩級目錄當選定存儲目錄以後，storage會爲文件分配一個fileid，每一個存儲目錄下有兩級256*256的子目錄，storage會按文件fileid進行兩次hash（猜想），路由到其中一個子目錄，而後將文件以fileid爲文件名存儲到該子目錄下。

五、生成文件名

當文件存儲到某個子目錄後，即認爲該文件存儲成功，接下來會爲該文件生成一個文件名，文件名由group、存儲目錄、兩級子目錄、fileid、文件後綴名（由客戶端指定，主要用於區分文件類型）拼接而成。

下載機制

客戶端帶上文件名信息請求Tracker服務獲取到存儲服務器的ip地址和端口，而後客戶端根據返回的IP地址和端口號請求下載文件，存儲服務器接收到請求後返回文件給客戶端。

跟upload file同樣，在download file時客戶端能夠選擇任意tracker server。tracker發送download請求給某個tracker，必須帶上文件名信息，tracke從文件名中解析出文件的group、大小、建立時間等信息，而後爲該請求選擇一個storage用來服務讀請求。因爲group內的文件同步時在後臺異步進行的，因此有可能出如今讀到時候，文件尚未同步到某些storage server上，爲了儘可能避免訪問到這樣的storage，tracker按照以下規則選擇group內可讀的storage。

一、該文件上傳到的源頭storage - 源頭storage只要存活着，確定包含這個文件，源頭的地址被編碼在文件名中。
二、文件建立時間戳==storage被同步到的時間戳且(當前時間-文件建立時間戳) > 文件同步最大時間（如5分鐘) - 文件建立後，認爲通過最大同步時間後，確定已經同步到其餘storage了。
三、文件建立時間戳 < storage被同步到的時間戳。 - 同步時間戳以前的文件肯定已經同步了
四、(當前時間-文件建立時間戳) > 同步延遲閥值（如一天）。 - 通過同步延遲閾值時間，認爲文件確定已經同步了。

同步時間管理

當一個文件上傳成功後，客戶端立刻發起對該文件下載請求（或刪除請求）時，tracker是如何選定一個適用的存儲服務器呢？其實每一個存儲服務器都須要定時將自身的信息上報給tracker，這些信息就包括了本地同步時間（即，同步到的最新文件的時間戳）。而tracker根據各個存儲服務器的上報狀況，就可以知道剛剛上傳的文件，在該存儲組中是否已完成了同步。同步信息上報以下圖：

寫文件時，客戶端將文件寫至group內一個storage server即認爲寫文件成功，storage server寫完文件後，會由後臺線程將文件同步至同group內其餘的storage server。

每一個storage寫文件後，同時會寫一份binlog，binlog裏不包含文件數據，只包含文件名等元信息，這份binlog用於後臺同步，storage會記錄向group內其餘storage同步的進度，以便重啓後能接上次的進度繼續同步；進度以時間戳的方式進行記錄，因此最好能保證集羣內全部server的時鐘保持同步。

storage的同步進度會做爲元數據的一部分彙報到tracker上，tracke在選擇讀storage的時候會以同步進度做爲參考。好比一個group內有A、B、C三個storage server，A向C同步到進度爲T1 (T1之前寫的文件都已經同步到B上了），B向C同步到時間戳爲T2（T2 > T1)，tracker接收到這些同步進度信息時，就會進行整理，將最小的那個作爲C的同步時間戳，本例中T1即爲C的同步時間戳爲T1（即全部T1之前寫的數據都已經同步到C上了）；同理，根據上述規則，tracker會爲A、B生成一個同步時間戳。