英文原文：The Google File System，編譯：ImportNew - 儲(chǔ)曉穎   新浪微博：@瘋狂編碼中的xiaoY

　　【譯者預(yù)讀】

　　GFS這三個(gè)字母無(wú)需過(guò)多修飾，《Google File System》的論文也早有譯版。但是這不妨礙我們加點(diǎn)批注、重溫經(jīng)典，并結(jié)合上篇Haystack的文章，將GFS、TFS、Haystack進(jìn)行一次全方位的對(duì)比，一窺各巨頭的架構(gòu)師們是如何權(quán)衡利弊、各取所需。

　　1. 介紹

　　我們?cè)O(shè)計(jì)和實(shí)現(xiàn)了GFS來(lái)滿足Google與日俱增的數(shù)據(jù)處理需求。與傳統(tǒng)的分布式文件系統(tǒng)一樣，GFS著眼在幾個(gè)重要的目標(biāo)，比如性能、可伸縮性、可靠性和可用性。不過(guò)它也會(huì)優(yōu)先考慮我們自身應(yīng)用場(chǎng)景的特征和技術(shù)環(huán)境，所以與早先一些文件系統(tǒng)的設(shè)計(jì)思想還是有諸多不同。我們?nèi)鹘y(tǒng)方案之精華、根據(jù)自身需求做了大膽的設(shè)計(jì)創(chuàng)新。在我們的場(chǎng)景中：

　　首先，組件故障是常態(tài)而不是異常。文件系統(tǒng)包含成百上千的存儲(chǔ)機(jī)器，而且是廉價(jià)的普通機(jī)器，被大量的客戶端機(jī)器訪問(wèn)。這樣的機(jī)器質(zhì)量和數(shù)量導(dǎo)致任何時(shí)間點(diǎn)都可能有一些機(jī)器不可用，甚至無(wú)法從當(dāng)前故障中恢復(fù)。導(dǎo)致故障的原因很多，比如應(yīng)用bug、操作系統(tǒng)bug、人為錯(cuò)誤，以及磁盤、內(nèi)存、連接器、網(wǎng)絡(luò)等硬件故障，甚至是電力供應(yīng)。因此，持續(xù)監(jiān)控、錯(cuò)誤偵測(cè)、故障容忍和自動(dòng)恢復(fù)必須全面覆蓋整個(gè)系統(tǒng)。

　　其次，用傳統(tǒng)視角來(lái)看，我們要處理的文件很多都是巨型的，好幾GB的文件也很常見(jiàn)。通常情況下每個(gè)文件中包含了多個(gè)應(yīng)用對(duì)象，比如web文檔。面對(duì)快速增長(zhǎng)、TB級(jí)別、包含數(shù)十億對(duì)象的數(shù)據(jù)集合，如果按數(shù)十億個(gè)KB級(jí)別的小文件來(lái)管理，即使文件系統(tǒng)能支持，也是非常不明智的。因此，一些設(shè)計(jì)上的假設(shè)和參數(shù)，比如I/O操作和塊大小，需要被重新審視。

　　第三，大部分文件發(fā)生變化是通過(guò)append新數(shù)據(jù)，而不是覆蓋、重寫已有的數(shù)據(jù)，隨機(jī)寫幾乎不存在。被寫入時(shí)，文件變成只讀，而且通常只能是順序讀。很多數(shù)據(jù)場(chǎng)景都符合這些特征。比如文件組成大型的庫(kù)，使用數(shù)據(jù)分析程序?qū)ζ鋻呙琛１热缬蛇\(yùn)行中的程序持續(xù)生成的數(shù)據(jù)流。比如歸檔數(shù)據(jù)。還可能是分布式計(jì)算的中間結(jié)果，在一臺(tái)機(jī)器上產(chǎn)生、然后在另一臺(tái)處理。這些數(shù)據(jù)場(chǎng)景都是由制造者持續(xù)增量的產(chǎn)生新數(shù)據(jù)，再由消費(fèi)者讀取處理。在這種模式下append是性能優(yōu)化和保證原子性的焦點(diǎn)。然而在客戶端緩存數(shù)據(jù)塊沒(méi)有太大意義。

　　第四，向應(yīng)用提供類似文件系統(tǒng)API，增加了我們的靈活性。松弛的一致性模型設(shè)計(jì)也極大的簡(jiǎn)化了API，不會(huì)給應(yīng)用程序強(qiáng)加繁重負(fù)擔(dān)。我們將介紹一個(gè)原子的append操作，多客戶端能并發(fā)的對(duì)一個(gè)文件執(zhí)行append，不需考慮任何同步。

　　當(dāng)前我們部署了多個(gè)GFS集群，服務(wù)不同的應(yīng)用。最大的擁有超過(guò)1000個(gè)存儲(chǔ)節(jié)點(diǎn)，提供超過(guò)300TB的磁盤存儲(chǔ)，被成百上千個(gè)客戶端機(jī)器大量訪問(wèn)。

　　2 設(shè)計(jì)概覽

　　2.1 假設(shè)

　　設(shè)計(jì)GFS過(guò)程中我們做了很多的設(shè)計(jì)假設(shè)，它們既意味著挑戰(zhàn)，也帶來(lái)了機(jī)遇。現(xiàn)在我們?cè)敿?xì)描述下這些假設(shè)。

• 系統(tǒng)是構(gòu)建在很多廉價(jià)的、普通的組件上，組件會(huì)經(jīng)常發(fā)生故障。它必須不間斷監(jiān)控自己、偵測(cè)錯(cuò)誤，能夠容錯(cuò)和快速恢復(fù)。
• 系統(tǒng)存儲(chǔ)了適當(dāng)數(shù)量的大型文件，我們預(yù)期幾百萬(wàn)個(gè)，每個(gè)通常是100MB或者更大，即使是GB級(jí)別的文件也需要高效管理。也支持小文件，但是不需要著重優(yōu)化。
• 系統(tǒng)主要面對(duì)兩種讀操作：大型流式讀和小型隨機(jī)讀。在大型流式讀中，單個(gè)操作會(huì)讀取幾百KB，也可以達(dá)到1MB或更多。相同客戶端發(fā)起的連續(xù)操作通常是在一個(gè)文件讀取一個(gè)連續(xù)的范圍。小型隨機(jī)讀通常在特定的偏移位置上讀取幾KB。重視性能的應(yīng)用程序通常會(huì)將它們的小型讀批量打包、組織排序，能顯著的提升性能。
• 也會(huì)面對(duì)大型的、連續(xù)的寫，將數(shù)據(jù)append到文件。append數(shù)據(jù)的大小與一次讀操作差不多。一旦寫入，幾乎不會(huì)被修改。不過(guò)在文件特定位置的小型寫也是支持的，但沒(méi)有著重優(yōu)化。
• 系統(tǒng)必須保證多客戶端對(duì)相同文件并發(fā)append的高效和原子性。我們的文件通常用于制造者消費(fèi)者隊(duì)列或者多路合并。幾百個(gè)機(jī)器運(yùn)行的制造者，將并發(fā)的append到一個(gè)文件。用最小的同步代價(jià)實(shí)現(xiàn)原子性是關(guān)鍵所在。文件被append時(shí)也可能出現(xiàn)并發(fā)的讀。
• 持久穩(wěn)定的帶寬比低延遲更重要。我們更注重能夠持續(xù)的、大批量的、高速度的處理海量數(shù)據(jù)，對(duì)某一次讀寫操作的回復(fù)時(shí)間要求沒(méi)那么嚴(yán)格。

　　2.2 接口

　　GFS提供了一個(gè)非常親切的文件系統(tǒng)接口，盡管它沒(méi)有全量實(shí)現(xiàn)標(biāo)準(zhǔn)的POSIX API。像在本地磁盤中一樣，GFS按層級(jí)目錄來(lái)組織文件，一個(gè)文件路徑（path）能作為一個(gè)文件的唯一ID。我們支持常規(guī)文件操作，比如create、delete、open、close、read和write。

　　除了常規(guī)操作，GFS還提供快照和record append操作。快照可以用很低的花費(fèi)為一個(gè)文件或者整個(gè)目錄樹(shù)創(chuàng)建一個(gè)副本。record append允許多個(gè)客戶端并發(fā)的append數(shù)據(jù)到同一個(gè)文件，而且保證它們的原子性。這對(duì)于實(shí)現(xiàn)多路合并、制造消費(fèi)者隊(duì)列非常有用，大量的客戶端能同時(shí)的append，也不用要考慮鎖等同步問(wèn)題。這些特性對(duì)于構(gòu)建大型分布式應(yīng)用是無(wú)價(jià)之寶。快照和record append將在章節(jié)3.4、3.3討論。

　　2.3 架構(gòu)

　　一個(gè)GFS集群包含單個(gè)master和多個(gè)chunkserver，被多個(gè)客戶端訪問(wèn)，如圖1所示。圖1中各組件都是某臺(tái)普通Linux機(jī)器上運(yùn)行在用戶級(jí)別的一個(gè)進(jìn)程。在同一臺(tái)機(jī)器上一起運(yùn)行chunkserver和客戶端也很容易，只要機(jī)器資源允許。

　　文件被劃分為固定大小的chunk。每個(gè)chunk在創(chuàng)建時(shí)會(huì)被分配一個(gè)chunk句柄，chunk句柄是一個(gè)不變的、全局唯一的64位的ID。chunkserver在本地磁盤上將chunk存儲(chǔ)為L(zhǎng)inux文件，按照chunk句柄和字節(jié)范圍來(lái)讀寫chunk數(shù)據(jù)。為了可靠性，每個(gè)chunk被復(fù)制到多個(gè)chunkserver上，默認(rèn)是3份，用戶能為不同命名空間的文件配置不同的復(fù)制級(jí)別。

　　master維護(hù)所有的文件系統(tǒng)元數(shù)據(jù)。包括命名空間，訪問(wèn)控制信息，從文件到chunk的映射，和chunk位置。它也負(fù)責(zé)主導(dǎo)一些影響整個(gè)系統(tǒng)的活動(dòng)，比如chunk租賃管理、孤兒chunk的垃圾回收，以及chunkserver之間的chunk遷移。master會(huì)周期性的與每臺(tái)chunkserver通訊，使用心跳消息，以發(fā)號(hào)施令或者收集chunkserver狀態(tài)。

　　每個(gè)應(yīng)用程序會(huì)引用GFS的客戶端API，此API與正規(guī)文件系統(tǒng)API相似，并且負(fù)責(zé)與master和chunkserver通訊，基于應(yīng)用的行為來(lái)讀寫數(shù)據(jù)。客戶端只在獲取元數(shù)據(jù)時(shí)與master交互，真實(shí)的數(shù)據(jù)操作會(huì)直接發(fā)至chunkserver。我們不需提供嚴(yán)格完整的POSIX API，因此不需要hook到Linux的vnode層面。

　　客戶端和chunkserver都不會(huì)緩存文件數(shù)據(jù)。客戶端緩存文件數(shù)據(jù)收益很小，因?yàn)榇蟛糠?a href=/pingce/yingyong/ target=_blank class=infotextkey>應(yīng)用通常會(huì)順序掃描大型文件，緩存重用率不高，要么就是工作集合太大緩存很困難。沒(méi)有緩存簡(jiǎn)化了客戶端和整個(gè)系統(tǒng)，排除緩存一致性問(wèn)題。（但是客戶端會(huì)緩存元數(shù)據(jù)。）chunkserver不需要緩存文件數(shù)據(jù)因?yàn)閏hunk被存儲(chǔ)為本地文件，Linux提供的OS層面的buffer緩存已經(jīng)保存了頻繁訪問(wèn)的文件。

　　2.4 單一Master

　　單一master大大的簡(jiǎn)化了我們的設(shè)計(jì)，單一master能夠放心使用全局策略執(zhí)行復(fù)雜的chunk布置、制定復(fù)制決策等。然而，我們必須在讀寫過(guò)程中盡量減少對(duì)它的依賴，它才不會(huì)成為一個(gè)瓶頸。客戶端從不通過(guò)master讀寫文件，它只會(huì)詢問(wèn)master自己應(yīng)該訪問(wèn)哪個(gè)chunkserver。客戶端會(huì)緩存這個(gè)信息一段時(shí)間，隨后的很多操作即可以復(fù)用此緩存，與chunkserver直接交互。

　　我們利用圖1來(lái)展示一個(gè)簡(jiǎn)單讀操作的交互過(guò)程。首先，使用固定的chunk size，客戶端將應(yīng)用程序指定的文件名和字節(jié)偏移量翻譯為一個(gè)GFS文件及內(nèi)部chunk序號(hào)，隨后將它們作為參數(shù)，發(fā)送請(qǐng)求到master。master找到對(duì)應(yīng)的chunk句柄和副本位置，回復(fù)給客戶端。客戶端緩存這些信息，使用GFS文件名+chunk序號(hào)作為key。

　　客戶端然后發(fā)送一個(gè)讀請(qǐng)求到其中一個(gè)副本，很可能是最近的那個(gè)。請(qǐng)求中指定了chunk句柄以及在此chunk中讀取的字節(jié)范圍。后面對(duì)相同chunk的讀不再與master交互，直到客戶端緩存信息過(guò)期或者文件被重新打開(kāi)。事實(shí)上，客戶端通常會(huì)在一個(gè)與master的請(qǐng)求中順帶多索要一些其他chunk的信息，而且master也可能將客戶端索要chunk后面緊跟的其他chunk信息主動(dòng)回復(fù)回去。這些額外的信息避免了未來(lái)可能發(fā)生的一些client-master交互，幾乎不會(huì)導(dǎo)致額外的花費(fèi)。

　　2.5 chunk size

　　chunk size是其中一個(gè)關(guān)鍵的設(shè)計(jì)參數(shù)。我們選擇了64MB，這是比典型的文件系統(tǒng)的塊大多了。每個(gè)chunk副本在chunkserver上被存儲(chǔ)為一個(gè)普通的Linux文件，只在必要的時(shí)候才去擴(kuò)展。懶惰的空間分配避免了內(nèi)部碎片導(dǎo)致的空間浪費(fèi)，chunk size越大，碎片的威脅就越大。

　　chunk size較大時(shí)可以提供幾種重要的優(yōu)勢(shì)。首先，它減少了客戶端與master的交互，因?yàn)閷?duì)同一個(gè)chunk的讀寫僅需要對(duì)master執(zhí)行一次初始請(qǐng)求以獲取chunk位置信息。在我們的應(yīng)用場(chǎng)景中大部分應(yīng)用會(huì)順序的讀寫大型文件，chunk size較大（chunk數(shù)量就較少）能有效的降低與master的交互次數(shù)。對(duì)于小型的隨機(jī)讀，即使整個(gè)數(shù)據(jù)集合達(dá)到TB級(jí)別，客戶端也能舒服的緩存所有的chunk位置信息（因?yàn)閏hunk size大，chunk數(shù)量小）。其次，既然用戶面對(duì)的是較大的chunk，它更可能愿意在同一個(gè)大chunk上執(zhí)行很多的操作（而不是操作非常多的小chunk），這樣就可以對(duì)同一個(gè)chunkserver保持長(zhǎng)期的TCP連接以降低網(wǎng)絡(luò)負(fù)載。第三，它減少了master上元數(shù)據(jù)的大小，這允許我們放心的在內(nèi)存緩存元數(shù)據(jù)，章節(jié)2.6.1會(huì)討論繼而帶來(lái)的各種好處。

　　不過(guò)chunk size如果很大，即使使用懶惰的空間分配，也有它的缺點(diǎn)。一個(gè)小文件包含chunk數(shù)量較少，可能只有一個(gè)。在chunkserver上這些chunk可能變成熱點(diǎn)，因?yàn)楹芏嗫蛻舳藭?huì)訪問(wèn)相同的文件（如果chunk size較小，那小文件也會(huì)包含很多chunk，資源競(jìng)爭(zhēng)可以分擔(dān)到各個(gè)小chunk上，就可以緩解熱點(diǎn)）。不過(guò)實(shí)際上熱點(diǎn)沒(méi)有導(dǎo)致太多問(wèn)題，因?yàn)槲覀兊?a href=/pingce/yingyong/ target=_blank class=infotextkey>應(yīng)用大部分都是連續(xù)的讀取很大的文件，包含很多chunk（即使chunk size較大）。

　　然而，熱點(diǎn)確實(shí)曾經(jīng)導(dǎo)致過(guò)問(wèn)題，當(dāng)GFS最初被用在批量隊(duì)列系統(tǒng)時(shí)：用戶將一個(gè)可執(zhí)行程序?qū)懭隚FS，它只占一個(gè)chunk，然后幾百臺(tái)機(jī)器同時(shí)啟動(dòng)，請(qǐng)求此可執(zhí)行程序。存儲(chǔ)此可執(zhí)行文件的chunkserver在過(guò)多的并發(fā)請(qǐng)求下負(fù)載較重。我們通過(guò)提高它的復(fù)制級(jí)別解決了這個(gè)問(wèn)題（更多冗余，分擔(dān)壓力），并且建議該系統(tǒng)交錯(cuò)安排啟動(dòng)時(shí)間。一個(gè)潛在的長(zhǎng)期解決方案是允許客戶端從其他客戶端讀取數(shù)據(jù)（P2P模式~）。

　　2.6 元數(shù)據(jù)

　　master主要存儲(chǔ)三種類型的元數(shù)據(jù)：文件和chunk的命名空間，從文件到chunk的映射，每個(gè)chunk副本的位置。所有的元數(shù)據(jù)被保存在master的內(nèi)存中。前兩種也會(huì)持久化保存，通過(guò)記錄操作日志，存儲(chǔ)在master的本地磁盤并且復(fù)制到遠(yuǎn)程機(jī)器。使用操作日志允許我們更簡(jiǎn)單可靠的更新master狀態(tài)，不會(huì)因?yàn)閙aster的當(dāng)機(jī)導(dǎo)致數(shù)據(jù)不一致。master不會(huì)持久化存儲(chǔ)chunk位置，相反，master會(huì)在啟動(dòng)時(shí)詢問(wèn)每個(gè)chunkserver以獲取它們各自的chunk位置信息，新chunkserver加入集群時(shí)也是如此。

　　2.6.1 內(nèi)存中數(shù)據(jù)結(jié)構(gòu)

　　因?yàn)樵獢?shù)據(jù)存儲(chǔ)在內(nèi)存中，master可以很快執(zhí)行元數(shù)據(jù)操作。而且可以簡(jiǎn)單高效的在后臺(tái)周期性掃描整個(gè)元數(shù)據(jù)狀態(tài)。周期性的掃描作用很多，有些用于實(shí)現(xiàn)chunk垃圾回收，有些用于chunkserver故障導(dǎo)致的重新復(fù)制，以及為了均衡各機(jī)器負(fù)載與磁盤使用率而執(zhí)行的chunk遷移。章節(jié)4.3和4.4將討論其細(xì)節(jié)。

　　這么依賴內(nèi)存不免讓人有些顧慮，隨著chunk的數(shù)量和今后整體容量的增長(zhǎng)，整個(gè)系統(tǒng)將受限于master有多少內(nèi)存。不過(guò)實(shí)際上這不是一個(gè)很嚴(yán)重的限制。每個(gè)64MB的chunk，master為其維護(hù)少于64byte的元數(shù)據(jù)。大部分chunk是填充滿數(shù)據(jù)的，因?yàn)榇蟛糠治募芏郼hunk，只有少數(shù)可能只填充了部分。同樣的，對(duì)于文件命名空間數(shù)據(jù)，每個(gè)文件只能占用少于64byte，文件名稱會(huì)使用前綴壓縮緊密的存儲(chǔ)。

　　如果整個(gè)文件系統(tǒng)真的擴(kuò)展到非常大的規(guī)模，給master添點(diǎn)內(nèi)存條、換臺(tái)好機(jī)器scale up一下也是值得的。為了單一master+內(nèi)存中數(shù)據(jù)結(jié)構(gòu)所帶來(lái)的簡(jiǎn)化、可靠性、性能和彈性，咱豁出去了。

　　2.6.2 Chunk位置

　　master不會(huì)持久化的保存哪個(gè)chunkserver有哪些chunk副本。它只是在自己?jiǎn)?dòng)時(shí)拉取chunkserver上的信息（隨后也會(huì)周期性的執(zhí)行拉取）。master能保證它自己的信息時(shí)刻都是最新的，因?yàn)樗刂屏怂械腸hunk布置操作，并用常規(guī)心跳消息監(jiān)控chunkserver狀態(tài)。

　　我們最初嘗試在master持久化保存chunk位置信息，但是后來(lái)發(fā)現(xiàn)這樣太麻煩，每當(dāng)chunkserver加入或者離開(kāi)集群、改變名稱、故障、重啟等等時(shí)候就要保持master信息的同步。一般集群都會(huì)有幾百臺(tái)服務(wù)器，這些事件經(jīng)常發(fā)生。

　　話說(shuō)回來(lái)，只有chunkserver自己才對(duì)它磁盤上存了哪些chunk有最終話語(yǔ)權(quán)。沒(méi)理由在master上費(fèi)盡心機(jī)的維護(hù)一個(gè)一致性視圖，chunkserver上發(fā)生的一個(gè)錯(cuò)誤就可能導(dǎo)致chunk莫名消失（比如一個(gè)磁盤可能失效）或者運(yùn)維人員可能重命名一個(gè)chunkserver等等。

　　2.6.3 操作日志

　　操作日志是對(duì)重要元數(shù)據(jù)變更的歷史記錄。它是GFS的核心之一。不僅因?yàn)樗窃獢?shù)據(jù)唯一的持久化記錄，而且它還要承擔(dān)一個(gè)邏輯上的時(shí)間標(biāo)準(zhǔn)，為并發(fā)的操作定義順序。各文件、chunk、以及它們的版本（見(jiàn)章節(jié)4.5），都會(huì)根據(jù)它們創(chuàng)建時(shí)的邏輯時(shí)間被唯一的、永恒的標(biāo)識(shí)。

　　既然操作日志這么重要，我們必須可靠的存儲(chǔ)它，而且直至元數(shù)據(jù)更新被持久化完成（記錄操作日志）之后，才能讓變化對(duì)客戶端可見(jiàn)。否則，我們有可能失去整個(gè)文件系統(tǒng)或者最近的客戶端操作，即使chunkserver沒(méi)有任何問(wèn)題（元數(shù)據(jù)丟了或錯(cuò)了，chunkserver沒(méi)問(wèn)題也變得有問(wèn)題了）。因此，我們將它復(fù)制到多個(gè)遠(yuǎn)程機(jī)器，直到日志記錄被flush到本地磁盤以及遠(yuǎn)程機(jī)器之后才會(huì)回復(fù)客戶端。master會(huì)捆綁多個(gè)日志記錄，一起flush，以減少flush和復(fù)制對(duì)整個(gè)系統(tǒng)吞吐量的沖擊。

　　master可以通過(guò)重放操作日志來(lái)恢復(fù)它的元數(shù)據(jù)狀態(tài)。為了最小化master的啟動(dòng)時(shí)間，日志不能太多（多了重放就需要很久）。所以master會(huì)在適當(dāng)?shù)臅r(shí)候執(zhí)行“存檔”，每當(dāng)日志增長(zhǎng)超過(guò)一個(gè)特定的大小就會(huì)執(zhí)行存檔。所以它不需要從零開(kāi)始回放日志，僅需要從本地磁盤裝載最近的存檔，并回放存檔之后發(fā)生的有限數(shù)量的日志。存檔是一個(gè)緊密的類B樹(shù)結(jié)構(gòu)，它能直接映射到內(nèi)存，不用額外的解析。通過(guò)這些手段可以加速恢復(fù)和改進(jìn)可用性。

　　因?yàn)闃?gòu)建一個(gè)存檔會(huì)消耗點(diǎn)時(shí)間，master的內(nèi)部狀態(tài)做了比較精細(xì)的結(jié)構(gòu)化設(shè)計(jì)，創(chuàng)建一個(gè)新的存檔不會(huì)延緩持續(xù)到來(lái)的請(qǐng)求。master可以快速切換到一個(gè)新的日志文件，在另一個(gè)后臺(tái)線程中創(chuàng)建存檔。這個(gè)新存檔能體現(xiàn)切換之前所有的變異結(jié)果。即使一個(gè)有幾百萬(wàn)文件的集群，創(chuàng)建存檔也可以在短時(shí)間完成。結(jié)束時(shí)，它也會(huì)寫入本地和遠(yuǎn)程的磁盤。

　　恢復(fù)元數(shù)據(jù)時(shí)，僅僅需要最后完成的存檔和其后產(chǎn)生的日志。老的存檔和日志文件能被自由刪除，不過(guò)我們保險(xiǎn)起見(jiàn)不會(huì)隨意刪除。在存檔期間如果發(fā)生故障（存檔文件爛尾了）也不會(huì)影響正確性，因?yàn)榛謴?fù)代碼能偵測(cè)和跳過(guò)未完成的存檔。

　　2.7 一致性模型

　　GFS松弛的一致性模型能很好的支持我們高度分布式的應(yīng)用，而且實(shí)現(xiàn)起來(lái)非常簡(jiǎn)單高效。我們現(xiàn)在討論GFS的一致性保證。

　　2.7.1 GFS的一致性保證

　　文件命名空間變化（比如文件創(chuàng)建）是原子的，只有master能處理此種操作：master中提供了命名空間的鎖機(jī)制，保證了原子性的和正確性（章節(jié)4.1）；master的操作日志為這些操作定義了一個(gè)全局統(tǒng)一的順序（章節(jié)2.6.3）

　　各種數(shù)據(jù)變異在不斷發(fā)生，被它們改變的文件區(qū)域處于什么狀態(tài)？這取決于變異是否成功了、有沒(méi)有并發(fā)變異等各種因素。表1列出了所有可能的結(jié)果。對(duì)于文件區(qū)域A，如果所有客戶端從任何副本上讀到的數(shù)據(jù)都是相同的，那A就是一致的。如果A是一致的，并且客戶端可以看到變異寫入的完整數(shù)據(jù)，那A就是defined。當(dāng)一個(gè)變異成功了、沒(méi)有受到并發(fā)寫的干擾，它寫入的區(qū)域?qū)?huì)是defined（也是一致的）：所有客戶端都能看到這個(gè)變異寫入的完整數(shù)據(jù)。對(duì)同個(gè)區(qū)域的多個(gè)并發(fā)變異成功寫入，此區(qū)域是一致的，但可能是undefined：所有客戶端看到相同的數(shù)據(jù)，但是它可能不會(huì)反應(yīng)任何一個(gè)變異寫的東西，可能是多個(gè)變異混雜的碎片。一個(gè)失敗的變異導(dǎo)致區(qū)域不一致（也是undefined）：不同客戶端可能看到不同的數(shù)據(jù)在不同的時(shí)間點(diǎn)。下面描述我們的應(yīng)用程序如何區(qū)分defined區(qū)域和undefined區(qū)域。

　　數(shù)據(jù)變異可能是寫操作或者record append。寫操作導(dǎo)致數(shù)據(jù)被寫入一個(gè)用戶指定的文件偏移。而record append導(dǎo)致數(shù)據(jù)（record）被原子的寫入GFS選擇的某個(gè)偏移（正常情況下是文件末尾，見(jiàn)章節(jié)3.3），GFS選擇的偏移被返回給客戶端，其代表了此record所在的defined區(qū)域的起始偏移量。另外，某些異常情況可能會(huì)導(dǎo)致GFS在區(qū)域之間插入了padding或者重復(fù)的record。他們占據(jù)的區(qū)域可認(rèn)為是不一致的，不過(guò)數(shù)據(jù)量不大。

　　如果一系列變異都成功寫入了，GFS保證發(fā)生變異的文件區(qū)域是defined的，并完整的包含最后一個(gè)變異。GFS通過(guò)兩點(diǎn)來(lái)實(shí)現(xiàn)：(a) chunk的所有副本按相同的順序來(lái)實(shí)施變異（章節(jié)3.1）；(b) 使用chunk版本數(shù)來(lái)偵測(cè)任何舊副本，副本變舊可能是因?yàn)樗l(fā)生過(guò)故障、錯(cuò)過(guò)了變異（章節(jié)4.5）。執(zhí)行變異過(guò)程時(shí)將跳過(guò)舊的副本，客戶端調(diào)用master獲取chunk位置時(shí)也不會(huì)返回舊副本。GFS會(huì)盡早的通過(guò)垃圾回收處理掉舊的副本。

　　因?yàn)榭蛻舳司彺媪薱hunk位置，所以它們可能向舊副本發(fā)起讀請(qǐng)求。不過(guò)緩存項(xiàng)有超時(shí)機(jī)制，文件重新打開(kāi)時(shí)也會(huì)更新。而且，我們大部分的文件是append-only的，這種情況下舊副本最壞只是無(wú)法返回?cái)?shù)據(jù)（append-only意味著只增不減也不改，版本舊只意味著會(huì)丟數(shù)據(jù)、少數(shù)據(jù)），而不會(huì)返回過(guò)期的、錯(cuò)誤的數(shù)據(jù)。一旦客戶端與master聯(lián)系，它將立刻得到最新的chunk位置（不包含舊副本）。

　　在一個(gè)變異成功寫入很久之后，組件的故障仍然可能腐化、破壞數(shù)據(jù)。GFS中，master和所有chunkserver之間會(huì)持續(xù)handshake通訊并交換信息，借此master可以識(shí)別故障的chunkserver并且通過(guò)檢查checksum偵測(cè)數(shù)據(jù)腐化（章節(jié)5.2）。一旦發(fā)現(xiàn)此問(wèn)題，會(huì)盡快執(zhí)行一個(gè)restore，從合法的副本復(fù)制合法數(shù)據(jù)替代腐化副本（章節(jié)4.3）。一個(gè)chunk也可能發(fā)生不可逆的丟失，那就是在GFS反應(yīng)過(guò)來(lái)采取措施之前，所有副本都被丟失。通常GFS在分鐘內(nèi)就能反應(yīng)。即使出現(xiàn)這種天災(zāi)，chunk也只是變得不可用，而不會(huì)腐化：應(yīng)用收到清晰的錯(cuò)誤而不是錯(cuò)誤的數(shù)據(jù)。

　　【譯者注】一致性的問(wèn)題介紹起來(lái)難免晦澀枯燥，下面譯者用一些比較淺顯的例子來(lái)解釋GFS中的一致、不一致、defined、undefined四種狀態(tài)。

　　讀者可以想象這樣一個(gè)場(chǎng)景，某人和他老婆共用同一個(gè)Facebook賬號(hào)，同時(shí)登陸，同時(shí)看到某張照片，他希望將其順時(shí)針旋轉(zhuǎn)90度，他老婆希望將其逆時(shí)針旋轉(zhuǎn)90度。兩人同時(shí)點(diǎn)了修改按鈕，F(xiàn)acebook應(yīng)該聽(tīng)誰(shuí)的？俗話說(shuō)意見(jiàn)相同聽(tīng)老公的，意見(jiàn)不同聽(tīng)老婆的。但是Facebook不懂這個(gè)算法，當(dāng)他們重新打開(kāi)頁(yè)面時(shí)可能會(huì)：1. 都看到圖片順時(shí)針旋轉(zhuǎn)了90度；2. 都看到圖片逆時(shí)針旋轉(zhuǎn)了90度；3. 其他情況。對(duì)于1、2兩種情況，都是可以接受的，小夫妻若來(lái)投訴那只能如實(shí)相告讓他們自己回去猜拳，不關(guān)Facebook的事兒。因?yàn)?、2既滿足一致性（兩人在并發(fā)修改發(fā)生后都一直看到一致相同的內(nèi)容），又滿足defined（內(nèi)容是其中一人寫入的完整數(shù)據(jù)）。對(duì)于3會(huì)有哪些其他情況呢？如果這事兒發(fā)生在單臺(tái)電腦的本地硬盤（相當(dāng)于兩人同時(shí)打開(kāi)一個(gè)圖片軟件、編輯同一個(gè)圖片、然后并發(fā)提交保存），若不加鎖讓其串行，則可能導(dǎo)致數(shù)據(jù)碎片，以簡(jiǎn)單的代碼為例：

File file = new File("D:/temp.txt");FileOutputStream fos1 = new FileOutputStream(file);FileOutputStream fos2 = new FileOutputStream(file);fos1.write('1');fos1.write('2');fos1.write('3');fos2.write('a');fos2.write('b');fos2.write('c');fos1.close();fos2.close();

it知識(shí)庫(kù)：經(jīng)典論文翻譯導(dǎo)讀之《Google File System》，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。