一、設計預期

設計預期往往針對系統的應用場景，是系統在不同選擇間做balance的重要依據，對於理解GFS在系統設計時為何做出現有的決策至關重要。所以我們應重點關注：

• 失效是常態
• 主要針對大檔案
• 讀操作：大規模流式讀取、小規模隨機讀取
• 寫操作：大規模順序追加寫，寫入後很少修改
• 高效明確定義的並行追加寫
• 穩定高效地網路頻寬

二、整體設計

1、系統架構

GFS主要由以下三個系統模組組成：

• Master：管理元資料、整體協調系統活動
• ChunkServer：儲存維護資料塊（Chunk），讀寫檔案資料
• Client：向Master請求元資料，並根據元資料訪問對應ChunkServer的Chunk

2、設計要點

1）Chunk尺寸

由於GFS主要面向大檔案儲存和大規模讀寫操作，所以其選擇了遠大於一般檔案系統的64MB的Chunk尺寸。

好處：

• 減少元資料量，便於客戶端預讀快取，減少客戶端訪問Master的次數，減小Master負載；
• 減少元資料量，Master可以將元資料放在記憶體中；
• 客戶端短時間內工作集落在同一Chunk上的概率更高，減少客戶端訪問不同ChunkServer建立TCP連線的次數，從而減少網路負載。

壞處：

• 易產生資料碎片；
• 小檔案佔用Chunk少，對小檔案的頻繁訪問會集中在少數ChunkServer上，從而產生小檔案訪問熱點。

可能的解決方案：

• 增大小檔案複製引數；
• 客戶端間互傳資料。

2）元資料儲存方式

Master儲存的元資料包括：名稱空間、檔案和Chunk的對應關係、Chunk位置資訊。

名稱空間、檔案和Chunk的對應關係的儲存方式：

• 記憶體：真實資料；
• 磁碟：定期Checkpoint（壓縮B樹）和上次CheckPoint後的操作日誌；
• 多機備份：Checkpoint檔案和操作日誌。

Chunk位置資訊的儲存方式：

• 記憶體：真實資料
• 磁碟：不持久儲存

系統啟動和新Chunk伺服器加入時從Chunk伺服器獲取。避免了Master與ChunkServer之間的資料同步，只有Chunk伺服器才能最終確定Chunk是否在它的硬碟上。

3）一致性模型

名稱空間修改：原子性和正確性

檔案資料修改（之後詳細解釋）：

• 修改失敗：不一致
• 序列隨機寫：一致且已定義
• 並行隨機寫：非原子寫，一致但未定義
• 序列/並行追加寫（推薦）：少量不一致，保證已定義

三、詳細設計

1、系統互動設計

1）重要原則

最小化所有操作與Master的互動。

2）快取機制

最小化讀取操作與Master的互動：

客戶端訪問Chunk前從Master獲取元資料的過程中，會預取和快取部分Chunk的元資料，從而減少與Master的互動。

2）租約機制

最小化變更操作與Master的互動：

Master收到變更操作請求後

• 選擇一個Chunk副本發放定時租約作為主Chunk並返回給客戶端；
• 客戶端與主Chunk進行通訊進行變更操作；
• 租約超時前，對該Chunk的變更操作都由主Chunk進行序列化控制。

3）資料流與控制流分離

資料推送與控制操作同時進行。

資料流：管道方式按最優化的Chunk伺服器鏈推送，以最大化頻寬，最小化延時（全雙工交換網路，每臺機器進出頻寬最大化）；

控制流：

• 主ChunkServer確定二級副本接收完畢後，對所有變更操作分配連續序列號（序號確定操作順序）；
• 按序修改本地資料；
• 請求二級副本按序修改；
• 所有副本修改完成成功，否則失敗重做。

4）非原子寫操作

一次寫入資料過大，可能被客戶端分為多個寫操作，這些寫操作序號可能不連續，被其他併發寫操作打斷或覆蓋，出現數據一致但未定義的狀態。

5）原子記錄追加

追加寫時GFS推薦的寫入方式，應重點研究。

a. 原子記錄追加：客戶端指定寫入資料，GFS返回真實寫入偏移量。

b. 追加寫的過程：

• 追加操作會使Chunk超過尺寸
  • 填充當前Chunk；
  • 通知二級副本做同樣操作；
  • 通知客戶機向新Chunk追加；
• 追加操作不會使Chunk超過尺寸
  • 主Chunk追加資料；
  • 通知二級副本寫在相同位置上；
  • 成功 - 返回偏移； 失敗 - 再次操作。

c. 追加結果：失敗的追加操作可能導致Chunk間位元組級別不一致，但當最終追加成功後，所有副本在返回的偏移位置一致已定義，之後的追加操作不受影響。如下圖所示：

d. 冗餘資料處理：對於追加寫產生的冗餘資料

• Chunk尺寸不足時的填充資料
• 追加失敗時產生的重複內容

可在插入資料時附帶記錄級別的Checksum或唯一識別符號，在客戶端讀取資料時進行校驗過濾。

6）快照

使用COW技術，瞬間完成。快照實現的過程：

• 收回檔案所有Chunk的租約；
• 操作元資料完成元資料拷貝；
• 客戶端要寫入該檔案的Chunk時，Master通知該Chunk所在ChunkServer進行本地拷貝；
• 發放租約給拷貝Chunk；
• 返回拷貝Chunk的位置資訊。

2、Master節點設計

1）名稱空間管理

多操作並行，名稱空間鎖保證執行順序，檔案操作需獲得父目錄讀鎖和目標檔案/目錄寫鎖。

2）副本位置

Chunk跨機架分佈：

好處 -

• 防止整個機架破壞造成資料失效
• 綜合利用多機架整合頻寬（機架出入頻寬可能小於機架上機器的總頻寬，所以應最大化每臺機架的頻寬利用率）；

壞處 - 寫操作需跨機架通訊。

3）Chunk管理

a. 建立操作，主要考慮：

• 平衡硬碟使用率；
• 限制單ChunkServer短期建立次數（建立開銷雖小，但每次建立往往意味著大量的後續寫入）；
• 跨機架分佈。

b. 重複制，即有效副本不足時，通過複製增加副本數。優先考慮：

• 副本數量和複製因數相差多的；
• live（未被刪除）檔案的；
• 阻塞客戶機處理的

Chunk進行重複制。策略與建立類似。

c. 重負載均衡，通過調整副本位置，平衡格機負載。策略與建立類似。新ChunkServer將被逐漸填滿。

4）垃圾回收

惰性回收空間：刪除操作僅在檔名後新增隱藏標記，Master在常規掃描中刪除超時隱藏檔案的元資料，並通知對應ChunkServer刪除Chunk。

好處 -

• 與建立失敗的無效Chunk一致的處理方式；
• 批量執行開銷分散，Master相對空閒時進行；
• 刪除操作一定時間內可逆轉。

壞處 - 不便於使用者進行儲存空間調優。

解決方案 - 再次刪除加速回收，不同名稱空間不同複製回收策略。

5）過期失效副本檢測

過期檢測：Master維護Chunk級別版本號，新租約增加Chunk版本號，並通知所有副本更新版本號，過期Chunk會因版本號過舊被檢測。

3、容錯機制設計

1）高可用性

主要的提高可用性的機制：

• 元件快速恢復
• Chunk複製
• Master伺服器複製
  • Checkpoint和操作日誌多機備份；
  • Master程序失效重啟，硬體失效則新機器重啟Master程序；
  • “影子”Master，通過操作日誌“模仿”主Master操作，元資料版本稍慢。作用 - 分擔一定負載、失效期暫時接管。

2）資料完整性

ChunkServer獨立維護CheckSum檢驗副本完整性。原因：

• 跨Chunk伺服器比較副本開銷大；
• 追加操作造成的的byte級別不一致，導致無法通過比較副本判斷完整性。

Chunk讀取和Chunk伺服器空閒時，進行CheckSum校驗，發現損壞Chunk上報Master，進行重複制。

Checksum校驗的開銷：

• Checksum讀取開銷；
• Checksum校驗計算開銷。

但整體開銷可以接受，特別是對追加寫操作。

覆蓋寫與追加寫的Checksum計算開銷比較。兩者的關鍵區別在於不完整塊的CheckSum計算：

• 追加寫 - 對最後一個不完整塊，在寫入後進行增量的CheckSum計算。New CheckSum由Old CheckSum和新資料算出，未對原有資料重新計算，原有資料損壞，依然可以發現；
• 覆蓋寫 - 對第一個和最後一個不完整塊，在寫之前進行CheckSum校驗。否則，覆蓋寫只能重新對整塊計算CheckSum，若寫操作未覆蓋部分存在損壞資料，新CheckSum將從包含損壞資料的Chunk算出，之後再也無法校驗出該損壞資料。

四、總結

本文是我在閱讀論文《The Google File System》時記下的筆記，對論文的各部分內容進行了梳理。

系統設計過程往往就是在各種因素間根據目標需求權衡利弊的過程。分散式系統設計需要權衡的問題存在許多共性，GFS在設計過程中基於分散式環境的特點，做的許多重要決策對於其他分散式系統開發具有指導性的意義。

所以，我盡力把覺得有趣的設計要點進行了提煉，並對重要細節進行了重點分析，特別是各種權衡帶來的好處和壞處，以及針對最終選擇帶來的壞處的彌補方案。

如果這篇文章在梳理自己思路的同時，能為感興趣的朋友們提供一點點幫助，那也算做了件有意義的事情了！