分布式文件系統FastDFS如何做到高可用？

大家好我是數據僧，下面是我對這個問題的理解，不對之處還望指正。

什么是高可用？通俗講就是在任何異常情況下，系統依然能正常提供服務。盡量縮短系統不可用時間，以提高系統的可用時間。大多按照年可用時間99.99%為標準。平攤到每個月不可用時間在幾十分鐘內。如何做到高可用？1，系統設計上避免使用單點。2，自動故障轉移。

我們下面來看看FastDFS是如何做到這兩點的。通過下圖來了解下FastDFS的架構。

Tracker server主要作用是負載均衡和調度，通過Tracker server在文件上傳時可以根據一些策略找到Storage server提供文件上傳服務。Tracker server可以由一臺或者N臺服務器組成。可以隨時增加或者下線不會影響線上服務，同時可以根據線上服務器的壓力情況隨時增加或者減少。

Tracker負責管理Storage和group。每個storage會去連結Tracker，并切報告自己所屬的group等信息，并保持和Tracker周期性的心跳。tracker根據storage的心跳信息建立 group-storage server list的映射表。所有的元信息很少，都存儲在內存中。這樣就使Tracker非常容易擴展。

Storage server：可以稱為存儲服務器。客戶端上傳的文件最終存儲在Storage服務器上，Storage server沒有實現自己的文件系統而是利用操作系統 的文件系統來管理文件。存儲系統由一個或多個組組成，組與組之間的文件是相互獨立的，所有組的文件容量累加就是整個存儲系統中的文件容量。

文件上傳流程

1,Client想上傳圖片，它先向Tracker進行詢問，Tracker查看一下登記信息之后，告訴Client哪個storage當前空閑，Tracker會把IP和端口號都返回給Client，Client在拿到IP和端口號之后，便不再需要通過Tracker，直接便向Storage進行上傳圖片，Storage在保存圖片的同時，會向Tracker進行匯報，告訴Tracker它當前是否還留有剩余空間，以及剩余空間大小。匯報完之后，Storage將服務器上存儲圖片的地址返回給Client，Client可以拿著這個地址進行訪問圖片。

我們來了解下文件索引信息。主要包括：組名，虛擬磁盤路徑，數據兩級目錄，文件名。如下所示：

我們來看看文件索引的具體解釋和組成部分：

組名：文件上傳后所在的storage組名稱，在文件上傳成功后由storage服務器返回，需要客戶端自行保存。

虛擬磁盤路徑：storage配置的虛擬路徑，與磁盤選項store_path*對應。如果配置了store_path0則是M00，如果配置了store_path1則是M01，以此類推。

數據兩級目錄：storage服務器在每個虛擬磁盤路徑下創建的兩級目錄，用于存儲數據文件。文件名：與文件上傳時不同。是由存儲服務器根據特定信息生成，

文件名包含：源存儲服務器IP地址、文件創建時間戳、文件大小、隨機數和文件拓展名等信息

文件下載流程

如圖所示FastDFS下載的時序圖

圖解如下

Storage Server啟動后會主動去連結Tracker Server，周期性向Tracker Server發送心跳。

然后client詢問tracker下載文件的storage，參數為文件標識（組名和文件名），tracker返回一臺可用的storage。

最后client直接和storage通訊完成文件下載。

我們在來看看FastDFS下載的運行的示意圖

FastDFS高可用架構實踐。

如果FastDFS壓力過大此時我們如何在對這個架構進行優化呢？我們可以使用ATS做文件緩存服務。

我們通過對FastDFS中的Tracker server和Storage server 的工作流程的了解，以及上傳和下載的具體場景圖列，可以發現它做到了冗余，做到了自動故障轉移。以上就是我這個問題的理解。

我們一起探討FastDFS的相關問題。在評論區留言，我們一起討論，持續更新對這個問題的理解。