1.GFS的架構
先來對這張圖，也就是讀取流程做一下解釋。
<1>client在把應用程序要讀寫的文件根據文件名和偏移量，根據chunk的大小轉換成文件的chunk index；
<2>client將filename和chunk index發送給master，master通過查找，返回相應的chunk handle（chunk標識/chunk句柄）和位置；
<3>client使用filename和chunk handle最爲key，緩存這些數據；
<4>client向相應的chunkserver發起請求，發送的信息是chunk handle和byte range（字節範圍）；
<5>client對該chunk的後續讀取操作中，client不會與master交互，除非client本身的cache信息過期了，或者這個文件重新打開了。
（1）GFS的組成
GFS由一個master（元數據服務器），多個chunkserver（塊服務器），多個client（客戶端）組成。
（2）master
<1>master負責管理所有文件系統的元數據（包括namespace，訪問控制信息，文件到chunk的映射，當前chunk的位置信息等），同時掌握整個系統內的chunkserver情況。
<2>master控制系統級別的活動。包括有：chunk的分配和管理、孤點chunk的垃圾回收機制、chunk在chunkserver之間的移動。
<3>master和chunkserver之間通過心跳包傳遞信息和狀態。
思考：爲什麼設計單個master?
<1>單個master簡化了設計，master可以基於全局角度管理chunk的存放；
<2>單個master保證了數據的一致性。
單個master的缺點：
單個master，很容易造成讀寫是系統的瓶頸，因此，必須儘量減少master的讀寫操作，避免它成爲瓶頸。client不會通過master做數據的讀寫，client和master交互，只是得到chunk index和chunk的存儲位置，並在client緩存這些信息，在後續操作中都使用這些信息。只有client緩存的信息過期了或者這個文件重新打開了，client纔會和master重新交互以獲取新的信息。GFS對master進行遠程備份，當master宕機時，通過operator log，簡單可靠的恢復master的狀態。
master的特點：
master在啓動時和chunkserver加入集羣時，向每一個chunkserver詢問他的chunk信息，master非持久化保存chunk的位置信息。
原因有二：
(1)減少master和chunkserver的同步；
(2)chunk的位置信息只有chunkserver有義務知道，master可以定期訪問chunkserver獲取最新的位置信息。
（3）chunkserver
GFS下，每一個文件都拆成固定大小的chunk(塊)。每一個塊都由master根據塊創建的時間產生一個全局唯一的以後不會改變的64位的chunkhandle標誌。chunkserver在本地磁盤用Linux文件系統保存塊，並根據chunk handle和byte range，通過Liunx文件系統讀寫這些塊的數據。出於可靠性考慮，每一個塊都會在不同的chunkserver上保存，默認備份3份。
思考：爲什麼每塊的大小是64M？
<1>減少client和master的通訊的需求；
<2>降低了master需要保存的元數據的數量，允許將元數據的保存在內存中；
<3>64M是一個經驗值，大文件切割成64M能保證最大額傳輸效率。
GFS下，如果是小型文件，切塊後可能只有一個或者兩個chunk塊，保存這些塊的chunkserver在大量客戶端訪問時就會成爲焦點，可以通過增加備份數量來解決這個問題。但是這個問題不用擔心，因爲GFS是處理超大文件的。
