分佈式文件系統FastDFS詳解

單機時代

初創時期由於時間緊迫,在各種資源有限的情況下,通常就直接在項目目錄下建立靜態文件夾,用於用戶存放項目中的文件資源。如果按不同類型再細分,可以在項目目錄下再建立不同的子目錄來區分。例如: resources\static\file、 resources\static\img等。

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

缺點:如果只是後臺系統的使用一般也不會有什麼問題,但是作爲一個前端網站使用的話就會存在弊端。一方面,文件和代碼耦合在一起,文件越多存放越混亂;另一方面,如果流量比較大,靜態文件訪問會佔據一定的資源,影響正常業務進行,不利於網站快速發展。

獨立文件服務器

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

優點:圖片訪問是很消耗服務器資源的(因爲會涉及到操作系統的上下文切換和磁盤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相關概念

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、路徑信息、文件名等信息,客戶端保存相關信息上傳完畢。

內部機制如下:

1、選擇tracker server

當集羣中不止一個tracker server時,由於tracker之間是完全對等的關係,客戶端在upload文件時可以任意選擇一個trakcer。 選擇存儲的group 當tracker接收到upload file的請求時,會爲該文件分配一個可以存儲該文件的group,支持如下選擇group的規則:

1、Round robin,所有的group間輪詢

2、Specified group,指定某一個確定的group

3、Load balance,剩餘存儲空間多多group優先

2、選擇storage server

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

1、Round robin,在group內的所有storage間輪詢

2、First server ordered by ip,按ip排序

3、First server ordered by priority,按優先級排序(優先級在storage上配置)

3、選擇storage path

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

1、Round robin,多個存儲目錄間輪詢

2、剩餘存儲空間最多的優先

4、生成Fileid

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

5、生成文件名

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

下載機制

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

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

1、該文件上傳到的源頭storage - 源頭storage只要存活着,肯定包含這個文件,源頭的地址被編碼在文件名中。

2、文件創建時間戳==storage被同步到的時間戳 且(當前時間-文件創建時間戳) > 文件同步最大時間(如5分鐘) - 文件創建後,認爲經過最大同步時間後,肯定已經同步到其他storage了。

3、文件創建時間戳 < storage被同步到的時間戳。 - 同步時間戳之前的文件確定已經同步了

4、(當前時間-文件創建時間戳) > 同步延遲閥值(如一天)。 - 經過同步延遲閾值時間,認爲文件肯定已經同步了。

同步時間管理

當一個文件上傳成功後,客戶端馬上發起對該文件下載請求(或刪除請求)時,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生成一個同步時間戳。

精巧的文件ID-FID

說到下載就不得不提文件索引(又稱:FID)的精巧設計了。文件索引結構如下圖,是客戶端上傳文件後存儲服務器返回給客戶端,用於以後訪問該文件的索引信息。文件索引信息包括:組名,虛擬磁盤路徑,數據兩級目錄,文件名。

組名:文件上傳後所在的存儲組名稱,在文件上傳成功後有存儲服務器返回,需要客戶端自行保存。

虛擬磁盤路徑:存儲服務器配置的虛擬路徑,與磁盤選項store_path*對應。

數據兩級目錄:存儲服務器在每個虛擬磁盤路徑下創建的兩級目錄,用於存儲數據文件。

文件名:與文件上傳時不同。是由存儲服務器根據特定信息生成,文件名包含:源存儲服務器IP地址、文件創建時間戳、文件大小、隨機數和文件拓展名等信息。

快速定位文件

知道FastDFS FID的組成後,我們來看看FastDFS是如何通過這個精巧的FID定位到需要訪問的文件。

1、通過組名tracker能夠很快的定位到客戶端需要訪問的存儲服務器組,並將選擇合適的存儲服務器提供客戶端訪問;

2、存儲服務器根據“文件存儲虛擬磁盤路徑”和“數據文件兩級目錄”可以很快定位到文件所在目錄,並根據文件名找到客戶端需要訪問的文件。

如何搭建FastDFS?參考我博客的這篇文章 (FastDFS 集羣 安裝 配置:http:///fastdfs/2017/10/10/cluster-building-fastdfs.html),下圖爲某用戶搭建的架構示意圖


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章