google file system

網上有不少很好的翻譯，本篇文章不再逐字逐句翻譯，簡單整理一下文章的内容。

都說經典的文章的，過段時日回頭看看，會有不一樣的感受。先留個坑吧。

1.基本互動流程

gfs是如何的運作的，和用戶端的互動流程如上。具體的各個環節如下：

1）client根據需要讀取或者寫入的檔案，offset向master發起請求，請求從master擷取相關資訊，如持有租約的資料集，以及資料集的位置。如果暫時沒有資料集獲得租約，master就進行授權，确定一個持有租約資料集。

對于一個chunk，gfs上儲存有多份的副本。所謂租約，相當于一個主節點的憑證。是指在對一個chunk進行修改的時候，需要通過master授予租約的方式确定主節點，由主節點維護寫入順序，來保證chunk在各個副本的一緻性。

2）master傳回資料集位置資訊。用戶端緩存這些資訊。當資料集不可通路，或者主replica不再持有租約的時候，才會再次和master發生互動。

chunk的位置的資訊儲存在master的記憶體當中。每次啟動的時候會初始化一次，後續通過與chunkserver的心跳來維護chunk的資訊，由chunkserver上報chunk的資訊。

3）client将資料傳輸到所有的資料集所在的chunkserver上，按就近的方式傳輸資料。chunkserver用LRU buffer來緩存資料，直到資料已經得到利用或者過期。

先傳輸資料，之後再進行寫入操作。同時資料傳輸的方式是鍊式傳輸，由一台伺服器傳輸給另外一台最近的伺服器。

4）所有的chuckserver都擷取到資料之後，client對主chunkserver發起寫入請求。主chunkserver通過一個連續的編号确定修改一個修改序列。

5）主資料集所在chunkserver将這樣的執行順序，發送給其他的chunkserver，其他的chunkserver以同樣的順序執行操作。

6）其他chunkserver響應主資料集所在chunkserver請求，以表示已經完成相應操作。

7）主chunkserver回複用戶端。如果用戶端收到了錯誤傳回，會通過重試的方式來處理。

2.master的職能

1）中繼資料維護

master記憶體中維護了檔案和chunk的檔案路徑(namespace)，檔案到chunk的映射，chunk各資料集的位置資訊。前兩種資訊通過日志來持久化到本地，也會複制到遠端機器作為備份。

2）namespace的鎖粒度

檔案是通過檔案系統的樹狀結構來組織的，每次對namespace進行修改，會擷取檔案父目錄路徑每一層的讀鎖，以及所需要的修改檔案的寫鎖。

3）資料集分布

提供基于機架級别的資料集隔離。

• 這應該算不上是gfs的特征？應該類似一種配置性的政策？

資料集會傾向于放置到使用率低于平均水準的chunkserver，同時盡量保證chunkserver的“最近建立資料集數”不會太高。其實就是在分布資料集時候考慮負載均衡。

4）清理政策

惰性删除，會對需要delete的檔案标記删除，經過一定的期限之後進行删除。

定期對chunk namespace掃描，對于master識别的孤立的chunk，即不可達的chunk，删除記憶體中對應的中繼資料。

chunkserver通過心跳上報該chunkserver所擁有的chunk，對于沒有在master中記錄的chunk，通過心跳的方式回傳chunkserver。

5）舊資料集檢測

chunk通過版本号來确定是否是最新的。master每次授予租約給chunk，都會遞增其版本号，并通知其他的資料集修改。

master定期對chunk的掃描中，對版本号過舊的chunk的資料集标記為不可見。

• 處理方式是标記删除，然後從其他副本中複制？全量複制，或者是能夠通過增量複制的方式在舊的資料集上處理？