對存在中心節點的分佈式文件系統的總結與思考

時間 2020-08-10

原文原文鏈接

對存在中心節點的分佈式文件系統的總結與思考

0. 前言

本文是在學習GFS（The Google File System，谷歌文件系統）後對存在中心節點的分佈式文件系統的一些宏觀的總結與思考。本文並無太多關注GFS的細節實現，而是側重在GFS的基礎上進行概括和進一步探究。redis

1. 爲何須要分佈式文件系統？

關於這個問題，百度百科是這麼說的緩存

計算機經過文件系統管理、存儲數據，而信息爆炸時代中人們能夠獲取的數據成指數倍的增加，單純經過增長硬盤個數來擴展計算機文件系統的存儲容量的方式，在容量大小、容量增加速度、數據備份、數據安全等方面的表現都差強人意。分佈式文件系統能夠有效解決數據的存儲和管理難題.....安全

更深層次而言，縱觀人類軟件系統的發展史，業務的爆炸不斷驅動着技術飛速發展。隨着接入網絡的人數愈來愈多，軟件系統也須要不斷升級以可以知足海量用戶的併發請求。而軟件系統的升級過程，就是不斷挑戰性能瓶頸的過程。從這個角度出發，用戶的增多必然會致使單機沒法容納須要持久化的數據，即便採用增長硬盤個數的方式將單機不斷擴大，在達到必定規模後，查找有關數據的操做會變得很是緩慢，掣肘總體軟件性能的提高。爲了解決這些問題，分佈式文件系統幾乎是必經之路，也是惟一選擇。服務器

2. 分佈式文件系統理想的實現效果？

最終目標只有一句話：用戶使用分佈式文件系統，感受就像在使用單機文件系統同樣。網絡

而限制這一最終目標達成的最主要因素，就在於網絡和機器都不是百分百的可靠。系統運行期間網絡的一點點波動、時延，或者機器的一點點故障，都有可能形成用戶沒法看到或看到不符合預期的結果。併發

3. 分佈式文件系統的要求？

大容量。這點是分佈式文件系統的基礎要求，也是固有屬性。若是大容量都沒法知足，那還不如單機的文件系統。
支持併發訪問。支持的併發數量是衡量分佈式文件系統性能的重要指標之一。
持久化。這也是基礎要求，數據不能持久化的分佈式文件系統是沒有太大意義的。
高可用。分佈式文件系統會存在不少服務器，不免會出現某個服務器宕機的狀況，這種狀況下仍須要保證文件系統的正常運轉。
一致性。銜接上一條高可用，冗餘備份是實現高可用最多見的方式，而一致性是冗餘備份不管如何也繞不開的關鍵問題。
低時延。沒有用戶願意在發出一個請求後經歷漫長的等待，時延也是衡量分佈式文件系統性能的重要指標之一。不過關於這一點，不一樣的分佈式文件系統有不一樣的要求，好比GFS就沒有過於追求某一次操做的低時延，而是更注重持續、穩定的帶寬。
可拓展（具備伸縮性）。系統都是隨着業務規模的擴大不斷升級，當業務需求對系統提出新的要求後，可拓展性就顯得尤其重要。

4. 分佈式文件系統的系統模型

本文的系統模式是存在中心節點的分佈式文件系統模型。app

谷歌文件系統（The Google File System）的系統模型就是很是經典的下圖：負載均衡

我將該系統提取成爲了一個較爲通用的抽象模型：分佈式

在該模型中，分佈式文件系統主要有master部分和server部分組成。master部分須要承載用戶的訪問請求並對所需資源進行定位，出於負載均衡方面的考慮通常不存儲文件；server部分是真正用來存放文件數據的部分。不一樣的分佈式文件系統對master部分和server部分的可能會有不一樣的具體實現，但功能大致類似。性能

以該抽象模型爲例，用戶想在系統中查詢文件的工做流程大體以下：

client向系統的master發送查詢請求，請求中包含須要查詢的文件的信息。
master獲取client須要所需內容在server中的位置座標，並返回client。
client根據查詢內容的位置座標找到相應的server節點，併發送查詢請求。
server將查詢的內容返回給client，查詢過程完畢。

上述流程以查詢爲例，增長、修改、刪除的操做也相似。

須要注意的是，分佈式文件系統也能夠採用以下模型：

但該模型中，master還須要承擔向server發送文件請求並接受文件內容的任務，在併發場景下I/O負擔會加劇到不可思議，master極易成爲系統的性能瓶頸，所以並不可取。

5.如何知足分佈式文件系統的要求？

這部分將參照上文的第三部分，以GFS系統爲參考，但不只限於GFS系統，逐條進行解決方案說明與分析：

大容量。系統中的server部分存在多個存儲節點知足系統大容量的需求，對應GFS中存在多個chunkserver。存儲節點越多，系統的容量越大，但也會相應的提升系統的運營成本，給系統性能帶來更大的挑戰。
支持併發訪問。系統對併發的支持主要體如今兩個方面：第一.master部分能夠支持多個client併發查詢文件所在的server座標。第二.server能夠支持多個client併發的操做數據。固然，並非全部的分佈式文件系統都須要同時知足這兩種併發，例如，master徹底能夠採用相似生產者-消費者的方式，client的查詢請求加入master隊列，而後master逐條取出並處理。
持久化。master和server都會將自身的數據保存到磁盤，server天然沒必要多說，會持久化存儲的文件數據，master部分須要持久化的東西較爲複雜，不一樣的分佈式文件系統持久化的內容也存在差別，我理解對於大多數系統而言，master至少應該持久化兩部份內容：1）文件與server的信息，如二者的命名空間、映射關係等 2）server中各個節點的最新版本id，節點版本id存在的必要是爲了知足一致性。

值得注意的是，因爲GFS採用了給節點頭分配租約（lease）的方式，所以並不須要持久化server當前的主節點（primary）。另外，GFS的持久化方式是日誌（log）+checkpoint，checkpoint是爲了防止日誌隨着時間的增加膨脹得太大。這種log+checkpoint的方式很是不錯，也是redis等經常使用軟件中採用的方式。
高可用。最多見的方式就是冗餘備份了，在GFS系統中高可用主要體如今兩個方面：

1）master的高可用。master的操做日誌、存檔等數據會被複制到多臺機器，master故障時，監控設備會在冗餘機器上啓動新的master進程，並採用更新DNS的方式引導client訪問新的master，保證系統持續可用。另外，GFS還提供了陰影master，陰影master能在master故障時提供只讀服務，可是陰影master的數據一般會落後1秒左右。

2）server的高可用。每份數據默認有3個chunkserver進行備份，固然，3個只是默認值，會根據不一樣文件的訪問熱度進行靈活調整，避免3個chunkserver沒法應對熱點數據的請求而成爲系統瓶頸。在冗餘備份時，須要考慮不一樣的server節點放置在不一樣的位置，如GFS會將同一文件不一樣的備份機放到不一樣的機架上，避免整個機架故障形成系統癱瘓，現在，大型系統須要考慮備份不只放在不一樣的機架，甚至要越遠越好，即「異地容災備份」。
一致性。多備份解決了高可用問題，但同時會引入一致性問題，不一樣的備份所處地理距離越遠，安全性越高，但一致性越困難。一致性產生的最根本緣由就是網絡的不可靠性，若是存在絕對可靠的網絡，那也不會存在一致性的難題，雖然隨着現在網絡的發展，網絡出現不可靠的機率愈來愈低，但在設計分佈式系統時，仍然須要考慮網絡每時每刻都存在不可靠的可能性，注意，必定要假設每時每刻均可能發生網絡故障，這對系統的一致性是很是巨大的挑戰。

在GFS系統中，大部分文件發生變化都是由於執行了追加（append）操做，而一般不會發生內容的覆蓋。GFS保證append操做一致性採用的鬆弛一致性模型：append操做會發送給多個備份中實時的primary節點，由primary節點指定執行順序，並通知其餘節點。在其餘節點所有執行成功後，primary節點會告訴client執行成功了，不然只要有一個節點執行失敗，primary就會告訴client失敗了，須要client從新發起操做請求。這個過程當中，若是執行失敗了，該過程並不會刪除已經append成功的節點中的文件信息，這顯然會形成沒必要要的空間浪費，這也是我認爲GFS能夠改進的點之一，好比採用兩階段提交或三階段提交的方法。另外，若是GFS同時存在讀和寫，那麼讀的線程有可能會讀到沒有寫完整的數據，這也是GFS作的不夠嚴謹的地方之一，這一問題能夠採用寫時複製、讀的過程當中檢查是否讀到了正在寫入的位置等方式進行改進。
低時延。緩存是減小時延很是有效的手段，可是在緩存的同時須要考慮緩存與磁盤數據的一致性問題。GFS的客戶端會緩存一些chunk句柄或對應的chunkserver的位置（這部分信息一般不會變化，所以不會存在複雜的一致性問題），但並不會緩存文件數據，由於該系統的業務場景下文件重用率不高，緩存文件內容的收益較小。在chunkserver中，chunk被存儲爲本地文件，此時Linux會提供操做系統層面的緩存，GFS沒有進行額外的緩存處理。

另外，GFS還採用了特殊的方式縮短查詢請求的時延：在查詢的時候，不是必須通過primary節點，而是根據距離、負載等因素選擇可以最快響應的server節點查詢。
可拓展（具備伸縮性）。系統的可拓展性主要考慮兩個方面：

1）master的可拓展性。master的可拓展方式主要有將單機master拓展爲多機master，具體實現可採用主從機制。可是在GFS系統中，並無對master進行拓展。這主要是由於，GFS以較大的數據塊存儲文件數據（每一個chunkserver保存64M），這就可以儘可能減小master保存的server信息，並減小client與master交互的次數，同時，client在查詢有關文件信息的時候，頗有可能會在同一次查詢中額外詢問一些後續的chunk信息，master有時也會主動告知client一些後續額外chunk信息，client一樣會緩存這些信息，這在業務主要是順序讀的場景中，幾乎不須要增長額外的成本就很是有效的減小了client與master交互的頻次，減小了master的負擔，若是採用這些方法就可以知足GFS的業務需求，那天然沒必要多此一舉去增長多機master。

可是若是考慮更爲長遠和大規模的場景，隨着server的增長，單機master必然會成爲系統的瓶頸，系統的升級就是不斷與瓶頸作鬥爭，所以，在必定業務規模下，master的拓展也必須在軟件設計之初就加以考慮。

2）server的可拓展性。server的可拓展性指的是隨着系統存儲文件數量的不斷增大，server節點不夠用時，須要補充新的server節點，此時須要新節點向master進行註冊，master即可以給新節點分配數據。master在給新節點分配數據時，能夠藉助新節點進一步實現系統的負載均衡，但也應該注意，不要爲了緩解負荷較重節點的壓力一會兒將過多的熱點數據分配給新節點，這會形成新節點短時間內負載忽然增大。