0. 前言

本文是在學習GFS（The Google File System，谷歌文件系統(tǒng)）后對存在中心節(jié)點的分布式文件系統(tǒng)的一些宏觀的總結(jié)與思考。本文并沒有太多關(guān)注GFS的細節(jié)實現(xiàn)，而是側(cè)重在GFS的基礎(chǔ)上進行歸納和進一步探究。

1. 為什么需要分布式文件系統(tǒng)？

關(guān)于這個問題，百度百科是這么說的

計算機通過文件系統(tǒng)管理、存儲數(shù)據(jù)，而信息爆炸時代中人們可以獲取的數(shù)據(jù)成指數(shù)倍的增長，單純通過增加硬盤個數(shù)來擴展計算機文件系統(tǒng)的存儲容量的方式，在容量大小、容量增長速度、數(shù)據(jù)備份、數(shù)據(jù)安全等方面的表現(xiàn)都差強人意。分布式文件系統(tǒng)可以有效解決數(shù)據(jù)的存儲和管理難題.....

更深層次而言，縱觀人類軟件系統(tǒng)的發(fā)展史，業(yè)務(wù)的爆炸不斷驅(qū)動著技術(shù)飛速發(fā)展。隨著接入網(wǎng)絡(luò)的人數(shù)越來越多，軟件系統(tǒng)也需要不斷升級以能夠滿足海量用戶的并發(fā)請求。而軟件系統(tǒng)的升級過程，就是不斷挑戰(zhàn)性能瓶頸的過程。從這個角度出發(fā)，用戶的增多必然會導致單機無法容納需要持久化的數(shù)據(jù)，即使采用增加硬盤個數(shù)的方式將單機不斷擴大，在達到一定規(guī)模后，查找有關(guān)數(shù)據(jù)的操作會變得非常緩慢，掣肘整體軟件性能的提升。為了解決這些問題，分布式文件系統(tǒng)幾乎是必經(jīng)之路，也是唯一選擇。

2. 分布式文件系統(tǒng)理想的實現(xiàn)效果？

最終目標只有一句話：用戶使用分布式文件系統(tǒng)，感覺就像在使用單機文件系統(tǒng)一樣。

而限制這一最終目標達成的最主要因素，就在于網(wǎng)絡(luò)和機器都不是百分百的可靠。系統(tǒng)運行期間網(wǎng)絡(luò)的一點點波動、時延，或者機器的一點點故障，都有可能造成用戶無法看到或看到不符合預期的結(jié)果。

3. 分布式文件系統(tǒng)的要求？

1. 大容量。這點是分布式文件系統(tǒng)的基礎(chǔ)要求，也是固有屬性。如果大容量都無法滿足，那還不如單機的文件系統(tǒng)。

2. 支持并發(fā)訪問。支持的并發(fā)數(shù)量是衡量分布式文件系統(tǒng)性能的重要指標之一。

3. 持久化。這也是基礎(chǔ)要求，數(shù)據(jù)不能持久化的分布式文件系統(tǒng)是沒有太大意義的。

4. 高可用。分布式文件系統(tǒng)會存在很多服務(wù)器，難免會出現(xiàn)某個服務(wù)器宕機的情況，這種情況下仍需要保證文件系統(tǒng)的正常運轉(zhuǎn)。

5. 一致性。銜接上一條高可用，冗余備份是實現(xiàn)高可用最常見的方式，而一致性是冗余備份無論如何也繞不開的關(guān)鍵問題。

6. 低時延。沒有用戶愿意在發(fā)出一個請求后經(jīng)歷漫長的等待，時延也是衡量分布式文件系統(tǒng)性能的重要指標之一。不過關(guān)于這一點，不同的分布式文件系統(tǒng)有不同的要求，比如GFS就沒有過于追求某一次操作的低時延，而是更注重持續(xù)、穩(wěn)定的帶寬。

7. 可拓展（具有伸縮性）。系統(tǒng)都是隨著業(yè)務(wù)規(guī)模的擴大不斷升級，當業(yè)務(wù)需求對系統(tǒng)提出新的要求后，可拓展性就顯得尤為重要。

4. 分布式文件系統(tǒng)的系統(tǒng)模型

本文的系統(tǒng)模式是存在中心節(jié)點的分布式文件系統(tǒng)模型。

谷歌文件系統(tǒng)（The Google File System）的系統(tǒng)模型就是非常經(jīng)典的下圖：

我將該系統(tǒng)提取成為了一個較為通用的抽象模型：

在該模型中，分布式文件系統(tǒng)主要有master部分和server部分組成。master部分需要承載用戶的訪問請求并對所需資源進行定位，出于負載均衡方面的考慮一般不存儲文件；server部分是真正用來存放文件數(shù)據(jù)的部分。不同的分布式文件系統(tǒng)對master部分和server部分的可能會有不同的具體實現(xiàn)，但功能大體相似。

以該抽象模型為例，用戶想在系統(tǒng)中查詢文件的工作流程大致如下：

1. client向系統(tǒng)的master發(fā)送查詢請求，請求中包含需要查詢的文件的信息。

2. master獲取client需要所需內(nèi)容在server中的位置坐標，并返回client。

3. client根據(jù)查詢內(nèi)容的位置坐標找到相應的server節(jié)點，并發(fā)送查詢請求。

4. server將查詢的內(nèi)容返回給client，查詢過程完畢。

   上述流程以查詢?yōu)槔黾?、修改、刪除的操作也類似。

   需要注意的是，分布式文件系統(tǒng)也可以采用如下模型：

但該模型中，master還需要承擔向server發(fā)送文件請求并接受文件內(nèi)容的任務(wù)，在并發(fā)場景下I/O負擔會加重到難以想象，master極易成為系統(tǒng)的性能瓶頸，因此并不可取。

5.如何滿足分布式文件系統(tǒng)的要求？

這部分將參照上文的第三部分，以GFS系統(tǒng)為參考，但不僅限于GFS系統(tǒng)，逐條進行解決方案說明與分析：

1. 大容量。系統(tǒng)中的server部分存在多個存儲節(jié)點滿足系統(tǒng)大容量的需求，對應GFS中存在多個chunkserver。存儲節(jié)點越多，系統(tǒng)的容量越大，但也會相應的提高系統(tǒng)的運營成本，給系統(tǒng)性能帶來更大的挑戰(zhàn)。

2. 支持并發(fā)訪問。系統(tǒng)對并發(fā)的支持主要體現(xiàn)在兩個方面：第一.master部分可以支持多個client并發(fā)查詢文件所在的server坐標。第二.server可以支持多個client并發(fā)的操作數(shù)據(jù)。當然，并不是所有的分布式文件系統(tǒng)都需要同時滿足這兩種并發(fā)，例如，master完全可以采用類似生產(chǎn)者-消費者的方式，client的查詢請求加入master隊列，然后master逐條取出并處理。

3. 持久化。master和server都會將自身的數(shù)據(jù)保存到磁盤，server自然不必多說，會持久化存儲的文件數(shù)據(jù)，master部分需要持久化的東西較為復雜，不同的分布式文件系統(tǒng)持久化的內(nèi)容也存在差異，我理解對于大多數(shù)系統(tǒng)而言，master至少應該持久化兩部分內(nèi)容：1）文件與server的信息，如兩者的命名空間、映射關(guān)系等 2）server中各個節(jié)點的最新版本id，節(jié)點版本id存在的必要是為了滿足一致性。

   值得注意的是，由于GFS采用了給節(jié)點頭分配租約（lease）的方式，因此并不需要持久化server當前的主節(jié)點（primary）。另外，GFS的持久化方式是日志（log）+checkpoint，checkpoint是為了防止日志隨著時間的增長膨脹得太大。這種log+checkpoint的方式非常不錯，也是redis等常用軟件中采用的方式。

4. 高可用。最常見的方式就是冗余備份了，在GFS系統(tǒng)中高可用主要體現(xiàn)在兩個方面：

   1）master的高可用。master的操作日志、存檔等數(shù)據(jù)會被復制到多臺機器，master故障時，監(jiān)控設(shè)備會在冗余機器上啟動新的master進程，并采用更新DNS的方式引導client訪問新的master，保證系統(tǒng)持續(xù)可用。另外，GFS還提供了陰影master，陰影master能在master故障時提供只讀服務(wù)，但是陰影master的數(shù)據(jù)通常會落后1秒左右。

   2）server的高可用。每份數(shù)據(jù)默認有3個chunkserver進行備份，當然，3個只是默認值，會根據(jù)不同文件的訪問熱度進行靈活調(diào)整，避免3個chunkserver無法應對熱點數(shù)據(jù)的請求而成為系統(tǒng)瓶頸。在冗余備份時，需要考慮不同的server節(jié)點放置在不同的位置，如GFS會將同一文件不同的備份機放到不同的機架上，避免整個機架故障造成系統(tǒng)癱瘓，如今，大型系統(tǒng)需要考慮備份不僅放在不同的機架，甚至要越遠越好，即“異地容災備份”。

5. 一致性。多備份解決了高可用問題，但同時會引入一致性問題，不同的備份所處地理距離越遠，安全性越高，但一致性越困難。一致性產(chǎn)生的最根本原因就是網(wǎng)絡(luò)的不可靠性，如果存在絕對可靠的網(wǎng)絡(luò)，那也不會存在一致性的難題，雖然隨著如今網(wǎng)絡(luò)的發(fā)展，網(wǎng)絡(luò)出現(xiàn)不可靠的概率越來越低，但在設(shè)計分布式系統(tǒng)時，仍然需要考慮網(wǎng)絡(luò)每時每刻都存在不可靠的可能性，注意，一定要假設(shè)每時每刻都可能發(fā)生網(wǎng)絡(luò)故障，這對系統(tǒng)的一致性是非常巨大的挑戰(zhàn)。

   在GFS系統(tǒng)中，大部分文件發(fā)生變化都是因為執(zhí)行了追加（append）操作，而通常不會發(fā)生內(nèi)容的覆蓋。GFS保證append操作一致性采用的松弛一致性模型：append操作會發(fā)送給多個備份中實時的primary節(jié)點，由primary節(jié)點指定執(zhí)行順序，并通知其他節(jié)點。在其他節(jié)點全部執(zhí)行成功后，primary節(jié)點會告訴client執(zhí)行成功了，否則只要有一個節(jié)點執(zhí)行失敗，primary就會告訴client失敗了，需要client重新發(fā)起操作請求。這個過程中，如果執(zhí)行失敗了，該過程并不會刪除已經(jīng)append成功的節(jié)點中的文件信息，這顯然會造成不必要的空間浪費，這也是我認為GFS可以改進的點之一，比如采用兩階段提交或三階段提交的方法。另外，如果GFS同時存在讀和寫，那么讀的線程有可能會讀到?jīng)]有寫完整的數(shù)據(jù)，這也是GFS做的不夠嚴謹?shù)牡胤街?，這一問題可以采用寫時復制、讀的過程中檢查是否讀到了正在寫入的位置等方式進行改進。

6. 低時延。緩存是減少時延非常有效的手段，但是在緩存的同時需要考慮緩存與磁盤數(shù)據(jù)的一致性問題。GFS的客戶端會緩存一些chunk句柄或?qū)腸hunkserver的位置（這部分信息通常不會變化，因此不會存在復雜的一致性問題），但并不會緩存文件數(shù)據(jù)，因為該系統(tǒng)的業(yè)務(wù)場景下文件重用率不高，緩存文件內(nèi)容的收益較小。在chunkserver中，chunk被存儲為本地文件，此時Linux會提供操作系統(tǒng)層面的緩存，GFS沒有進行額外的緩存處理。

   另外，GFS還采用了特殊的方式縮短查詢請求的時延：在查詢的時候，不是必須經(jīng)過primary節(jié)點，而是根據(jù)距離、負載等因素選擇能夠最快響應的server節(jié)點查詢。

7. 可拓展（具有伸縮性）。系統(tǒng)的可拓展性主要考慮兩個方面：

   1）master的可拓展性。master的可拓展方式主要有將單機master拓展為多機master，具體實現(xiàn)可采用主從機制。但是在GFS系統(tǒng)中，并沒有對master進行拓展。這主要是因為，GFS以較大的數(shù)據(jù)塊存儲文件數(shù)據(jù)（每個chunkserver保存64M），這就能夠盡量減少master保存的server信息，并減少client與master交互的次數(shù)，同時，client在查詢有關(guān)文件信息的時候，很有可能會在同一次查詢中額外詢問一些后續(xù)的chunk信息，master有時也會主動告知client一些后續(xù)額外chunk信息，client同樣會緩存這些信息，這在業(yè)務(wù)主要是順序讀的場景中，幾乎不需要增加額外的成本就非常有效的減少了client與master交互的頻次，減少了master的負擔，如果采用這些方法就能夠滿足GFS的業(yè)務(wù)需求，那自然不必畫蛇添足去增加多機master。

   但是如果考慮更為長遠和大規(guī)模的場景，隨著server的增加，單機master必然會成為系統(tǒng)的瓶頸，系統(tǒng)的升級就是不斷與瓶頸做斗爭，因此，在一定業(yè)務(wù)規(guī)模下，master的拓展也必須在軟件設(shè)計之初就加以考慮。

   2）server的可拓展性。server的可拓展性指的是隨著系統(tǒng)存儲文件數(shù)量的不斷增大，server節(jié)點不夠用時，需要補充新的server節(jié)點，此時需要新節(jié)點向master進行注冊，master便可以給新節(jié)點分配數(shù)據(jù)。master在給新節(jié)點分配數(shù)據(jù)時，可以借助新節(jié)點進一步實現(xiàn)系統(tǒng)的負載均衡，但也應該注意，不要為了緩解負荷較重節(jié)點的壓力一下子將過多的熱點數(shù)據(jù)分配給新節(jié)點，這會造成新節(jié)點短期內(nèi)負載突然增大。

6. 總結(jié)與后記

本文是在對GFS學習后，閱讀了一些相關(guān)文章，對存在中心節(jié)點的分布式文件系統(tǒng)進行的歸納，從分布式文件系統(tǒng)存在的意義、終極目標說起，依據(jù)自己抽象出來的分布式文件系統(tǒng)通用模型分析了如何滿足分布式文件系統(tǒng)應該滿足的要求。

本文很多內(nèi)容都是以GFS的實現(xiàn)方式為例，對GFS的優(yōu)缺點進行了簡單的探討。文中提到的GFS可以改進的點，只是針對我認為較為通用的場景，并沒有過多的考慮GFS的業(yè)務(wù)場景，因此可能在特定業(yè)務(wù)場景下并不成立。

由于本人水平有限，難免會存在錯誤紕漏，歡迎大家與我交流，歡迎批評指正！謝謝！

7. 參考文獻

1. Ghemawat S , Gobioff H , Leung S T . The Google file system[J]. Acm Sigops Operating Systems Review, 2003, 37(5):29-43.