《Google File System》讀書筆記（1）

今天開始看《Google File System》，因爲只是爲了完善我本身的分佈式文件系統以及時間的限制，並不會深度的研究，只是大體的過一遍瞭解谷歌公司在分佈式文件系統上的設計模式，取長補短（大概）

因爲我是邊讀邊記錄，因此幾乎沒有整理，都只是零散的知識點和設計要點。

---

GFS的設計是經過觀察應用程序的工做負載和當前-預期的技術環境來推進的

GFS中將組件的故障設置爲常態，所以設計需求要在常態的組件故障中保障應用程序服務能繼續可用。所以，系統中的持續監控，錯誤檢測，容錯和自動恢復都是必須的。

GFS在設計中有許多假設：

1.運行時常常出現因爲廉價的服務器致使組件錯誤，所以GFS須要不斷監視本身檢測錯誤以及容錯和自動恢復 ——————持續監控，錯誤檢測，容錯和自動恢復機制

2.存儲幾百萬個100M左右的文件，所以須要適量的存儲大文件，而且必須支持小文件，可是不須要對小文件進行優化。 ——————造成文件塊，每塊文件64M

3.工做負載來自大型流讀取以及小型隨機讀取。大型流讀取一般一次讀取數百KB或者1M或更高，來自同一客戶端的連續操做一般是讀取文件的連續區域。小的隨機讀取一般在某個任意便宜出讀取幾KB。注重性能的應用程序一般對小文件進行批處理和排序，以便在文件中連續讀取而不是屢次跳躍 ———————對讀寫的優化，W+R>E,讀一次成功就能夠，寫必需要寫三次，容許同時讀，但不能同時寫，寫操做是原子操做

4.高持續的帶寬 ———持久化鏈接

元數據：包括文件命名空間，訪問控制信息，從文件到塊的映射以及塊當前的位置，他還控制系統範圍的活動，例如租約的管理孤立塊的垃圾收集以及塊服務器之間的塊遷移，主設備定義與每一個塊進行心跳檢測，以便爲其提供指令和收集狀態

文件數據不緩存，客戶端只緩存元數據

master永遠不會和client產生文件傳輸的交互，client只會經過master獲知那些chunk-server，而後直接與chunk-server進行交互

client與master的交互：

1.client將應用程序中的文件名的字節偏移轉換爲文件中的塊索引

2.client向master發送包含文件名和塊索引的請求
⚠️：client一般會在同一個請求中請求多個塊

3.master迴應相應的塊句柄和chunk-server位置
⚠️：master一般會在回覆的那些塊信息後面再跟上一些塊信息

4.client使用文件名和塊索引做爲密鑰緩存此信息
⚠️：該信息有生存時間，在信息過時或者從新打開此文件以前，client對同一文件的讀取都不須要再從新通過master

5.client向最近的chunk-server發送請求，請求指定塊句柄和該塊中的字節範圍

塊大小爲64M：這比以前的分佈式文件塊大小要大得多，每一個塊副本都做爲普通linux文件存儲在服務器上，惰性空間分配避免了因爲內部碎片形成的浪費空間。 大塊的優勢：

1.減小了client與master交互的須要，在同一個塊上的讀寫只須要向master請求一次便可
2.經過保持與塊的持久TCP鏈接來減小網絡消耗
3.減小了master中的元數據的大小，使得master能夠將元數據存儲在內存中
複製代碼

大塊的缺點：

1.若是是小文件可能只有一個塊，若是有多個client同時訪問該文件，會致使該文件成爲熱點，致使存儲該塊的服務器過載
複製代碼

出現的問題：當GFS被批處理隊列系統使用時，可執行文件做爲單塊文件寫入GFS，而後同事在數百臺計算機上啓動，存儲此可執行文件的服務器因數百個併發請求而過載

解決辦法：經過存儲具備更高複製因子的可執行文件並使批處理隊列系統錯開應用程序啓動時間來解決

潛在的長期解決方案：容許客戶在這種狀況下從其餘地方讀取數據（不向最近chunk-server請求，向空閒的其餘地區的chunk-server發起請求，請求壓力方面的負載均衡

master主要存儲三種類型的元數據：文件名和塊命名空間，從文件到塊的映射以及每一個塊的副本的位置。全部元數據都保存在master的內存中，前兩種類型（名稱空間和文件到塊的映射）也經過將變化記錄存儲到主服務器本地磁盤上，而且在遠程計算機上覆制操做日誌來保持文件持久性。而master不會持久化每一個塊的位置信息，他會在master啓動時或chunk-server接入時主動向chunk-server詢問其塊信息

不將塊位置信息存儲在master的好處：

1.消除了master服務器加入/離開集羣，更更名稱，失敗，從新請求等等問題時解決了master和塊服務器的同步問題
2.chunk-server的塊可能本身消失（磁盤損壞），操做員重命名這個塊服務器名稱。這種狀況下在master維護該信息是沒有意義的
複製代碼

master會有周期性掃描chunk-server，用於實現塊垃圾收集以及chunk-server故障時從新複製，以及塊遷移以平衡塊服務器之間的負載和磁盤空間使用（會自動將文件移動到磁盤壓力小的chunk-server上

master爲每一個64MB的塊維護少於64字節的元數據，大部分塊都已滿，由於大多數文件具備多個塊，只有最後一個塊能夠部分填充。文件命名空間數據一般須要每一個文件少於64字節，由於它使用前綴壓縮緊湊地存儲文件名。若是須要支持更大的文件系統，爲主機添加額外內存是一個很小的代價，經過將元數據存儲在內存中得到簡單性，可靠性，高性能和靈活性。

master會有心跳監視chunk-server狀態

操做日誌是GFS的核心，操做日誌是元數據的惟一持久記錄，並且還充當併發操做順序的邏輯

只有當日志記錄持久化完成後纔開始進行後續的操做，不然會丟失塊的操做

master經過重播操做來回復其文件系統狀態，爲了最小化啓動時間，日誌大小有規定，當超過必定大小的時候會從新生成新的日誌文件。並且恢復的時候是檢查最新的檢查點，並在此基礎上恢復最新的幾條操做記錄（更前面的操做記錄是系統正常時候的操做記錄，必定是成功執行的），檢查點採用緊湊的B樹形式，能夠直接映射到內存，用於命名空間的查找而無需額外的解析，進一步加快了系統恢復速度並提升了可用性

這裏對日誌的構建不清楚
複製代碼

構建日誌檢查點並恢復的操做是在一個新的線程中進行的，這樣能夠在系統從新構建的同時接收新的操做日誌

檢查點的代碼會跳過不完整的檢查點

GFS爲了保證統一而進行的操做：

1.文件命名空間突變（例：文件建立）是原子操做。命名空間鎖保證原子性和正確性
複製代碼

每次修改文件塊都會同時修改他的版本號，若是出現文件塊副本版本號不對應，則該文件塊未垃圾文件塊

因爲客戶端保存了塊位置信息，致使client會從舊的塊中讀取數據。所以這個由緩存的超時時間和文件的從新打開而受限制。（爲何會受限制？是由於讀取的時候都要驗證過文件名和塊索引生成的密鑰嗎？）