關於分布式檔案儲存系統問題的自我思考

2022-07-30 11:12:07 字數 1486 閱讀 6122

1. 前言

其實站在使用者的角度思考:其需求功能非常簡單,能成功快速增刪讀寫檔案就ok了,如同操作本地的單機檔案系統一樣簡單。例如如下:

a. 讀取檔案操作,read函式: ssize_t read(int fd, void* buf, size_t count);

b. 寫入檔案操作,write函式: ssize_t write(int fd, const void* buf, size_t count)。 

2. 問題

既然分布式檔案系統是由許多資料節點組成的集群,如果你是乙個操心的主,可能會進一步的思考,其實現背後的諸多問題:

2.1. 寫檔案操作

a. 在單機本地檔案系統,我們不用關心資料存放的節點,因為預設寫本地服務上;那在分布式檔案系統上,檔案寫到哪個節點上或者哪些節點上了呢(資料副本策略)?

b. 這些資料節點怎麼從集群種選置和敲定的(資料放置策略)?

c. 客戶端直接和這些資料節點同時溝通,還是只是和其中的乙個資料節點代表做溝通呢(資料複製策略)?

d. 另外,資料寫入成功與否直接影響服務的可靠性,所以寫入操作的成功或失敗結果返回非常重要。那麼在分布式檔案系統裡,寫入的成功如何來度量?是成功地寫入到乙個資料節點,還是成功地寫入到多個資料節點後算操作成功,然後返回結果給客戶端呢(資料複製時同步非同步策略)?

2.2. 讀取檔案操作

同樣的,客戶端在讀取資料檔案時,又到哪個資料節點上去取資料呢(資料節點擊擇策略)。

2.3. 資料組織與索引

在單機本地檔案系統裡,由於linux的io機制,檔名與物理磁碟的block編號自然建立了一一對映的關係。然而在分布式檔案系統裡,由於多了資料節點的維度,終端訪問的檔名與其所在的集群物理磁碟block位置之間的索引關係會是什麼樣的?檔案的邏輯結構如何組織的?

2.4. 空閒時段和心跳時期

在高峰期,集群服務在頻繁地與客戶端發生的溝通和任務排程執行;我們知道服務集群是7*24不休息的,那麼在半夜等空閒的低負載時期,集群服務又會「偷偷摸摸」幹些啥事情呢?

當集群規模逐漸擴大時,節點不可用、網路異常、磁碟損壞等各類的故障發生率高:假設乙個節點每天的故障發生率是1%,那麼由乙個100節點組成的集群每天的故障發生率變成了0.64(1-0.99^100)。因此集群服務的健壯容錯、資料可用性也是分布式檔案系統的重要衡量指標之一。那麼一旦故障發生,服務必須仍能正常提供工作,並且具有能及時的檢查並進行資料的遷移與修復能力。而集群服務通過心跳機制完成各個節點間的負載或死活狀態的資訊共享與故障檢測;通過節點映象、資料遷移操作來修復資料節點故障或資料不均衡的現象。

以上僅是關於分布式檔案儲存系統的一些我個人的思考,有所不對或片面不全的地方,後續再補充吧。

參考:

1. 《大規模分布式儲存系統:原理解析與架構實戰》楊傳輝著

2. 《大資料日知錄》張俊林著

FastDFS分布式檔案儲存系統

負載均衡和排程,通過tracker server 在文上傳的時候可以根據一些策略找到storage server提供檔案上傳服務,可以將tracker 稱為追蹤伺服器或排程伺服器 檔案儲存,客戶端上傳的檔案最終儲存在storage 伺服器,storage server沒有實現自己的檔案系統而是利用作...

python分布式儲存系統 分布式系統

danger 什麼是分布式系統 分布式系統是由一組通過網路進行通訊 為了完成共同的任務而協調工作的計算機節點組成的系統。分布式系統的出現是為了用廉價的 普通的機器完成單個計算機無法完成的計算 儲存任務。其目的是利用更多的機器,處理更多的資料。首先需要明確的是,只有當單個節點的處理能力無法滿足日益增長...

FastDFS分布式儲存檔案系統

本次模擬單節點tracker伺服器以及兩台storage伺服器,建立之前必須確保伺服器之間都能相互ping通以及關閉防火牆 或者開放tracker伺服器與storage伺服器中配置檔案裡涉及的埠 安裝gcc環境 yum install y gcc c 建立存放目錄並進入該目錄 mkdir p opt...