今天開始看《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會從舊的塊中讀取資料。因此這個由快取的超時時間和檔案的重新開啟而受限制。（為什麼會受限制？是因為讀取的時候都要驗證過檔名和塊索引生成的金鑰嗎？）