0. 前言

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

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

關(guān)于這個(gè)問(wèn)題，百度百科是這么說(shuō)的

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

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

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

最終目標(biāo)只有一句話(huà)：用戶(hù)使用分布式文件系統(tǒng)，感覺(jué)就像在使用單機(jī)文件系統(tǒng)一樣。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. client根據(jù)查詢(xún)內(nèi)容的位置坐標(biāo)找到相應(yīng)的server節(jié)點(diǎn)，并發(fā)送查詢(xún)請(qǐng)求。

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

   上述流程以查詢(xún)?yōu)槔?，增加、修改、刪除的操作也類(lèi)似。

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

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

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

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

1. 大容量。系統(tǒng)中的server部分存在多個(gè)存儲(chǔ)節(jié)點(diǎn)滿(mǎn)足系統(tǒng)大容量的需求，對(duì)應(yīng)GFS中存在多個(gè)chunkserver。存儲(chǔ)節(jié)點(diǎn)越多，系統(tǒng)的容量越大，但也會(huì)相應(yīng)的提高系統(tǒng)的運(yùn)營(yíng)成本，給系統(tǒng)性能帶來(lái)更大的挑戰(zhàn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. 總結(jié)與后記

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

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

由于本人水平有限，難免會(huì)存在錯(cuò)誤紕漏，歡迎大家與我交流，歡迎批評(píng)指正！謝謝！

7. 參考文獻(xiàn)

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