偉人說：“人多力量大。”

尼古拉斯趙四說：“沒有什麼事，是一頓飯解決不了的！！！如果有，那就兩頓。”

研發說：“需求太多，人手不夠。”

專家說：“人手不夠，那就協調資源，攢人頭。”

釋義：一人拾柴火不旺，眾人拾柴火焰高。一人難挑千斤擔，眾人能移萬座山。

運維說：“一臺機器不夠；一個服務扛不住壓力。”

專家說：“一臺機器不夠，那就多申請幾台；一個服務扛不住壓力，那就多部署幾個。”

釋義：一箭易斷，十箭難折。一根線容易斷，萬根線能拉船。

從事互聯網開發時間久了，參加大大小小的會議，時不時總會討論或爭執類似“人手不夠、機器不夠、服務扛不住”等一類的資源問題，但是到最後解決方案，貌似都是進行資源協調。如果人手不夠，就協調資源攢人頭；如果機器不夠，就協調資源加幾台；如果一個服務扛不住壓力，那就協調資源多部署幾個。

所有的一切都離不開：攢、加 ... ... ，總之就是考慮如何從 1 到 N 。

拜讀 GFS 的論文，熟讀 N 篇系列文章，靜下來想想 GFS 架構設計，多少都透了著一絲“眾人拾柴火焰高、人多就是力量大”的想法，接下來就一起對 GFS 認識認識。

認識

到底是個啥？GFS 是一個把大量廉價的普通機器，聚在一起，充分讓每台廉價的機器發揮光和熱，具有高可用、高性能、高可靠、可擴展的分散式文件系統。

解剖

善於發現美。如上圖所示，GFS 架構的參與角色，主要分為 GFS master（主伺服器）、GFS chunkserver（塊存儲伺服器）、GFS client（客戶端）。

我們姑且認為 GFS master 是古代的皇上，統籌全局，運籌帷幄。主要負責掌控管理所有的文件系統的元數據，包括文件和塊的命名空間，從文件到塊的映射，每個塊所在的節點位置（說白了，要維護哪個文件存在哪些文件伺服器上的元數據信息）；並且定期通過心跳機制與每一個 GFS chunkserver 通信，向其發送指令並收集其狀態。

我們姑且認為 GFS chunkserver 是宰相，因為宰相肚子裡面能撐船，主要提供 chunks 數據塊的存儲服務，以文件的形式存儲於 chunkserver 上，能夠海納百川，有容乃大。

我們姑且認為 GFS client 是使者，對外提供一套類似傳統文件系統的 API 介面，對內主要與皇帝通信來獲取元數據；然後直接和宰相交互來進行所有的數據操作。

好奇

背後如何運轉？懵懂 GFS 架構設計的參與角色主要有皇上、諸多宰相、諸多使者構成，但是他們之間是如何協作運轉的呢？

我要寫入一個文件，GFS 架構背後流轉是咋回事？如上圖所示，主要分為 7 大步驟進行。

第一步：GFS client 向 GFS master 查詢待寫入的 chunk 的 GFS chunkserver（宰相）信息；

釋義：使者請求皇上要發起寫數據操作，皇上會告訴使者找哪幾個宰相去辦理。

第二步：GFS master 返回 GFS chunkserver 列表，其中返回的 chunkserver 分為 1 主 2 從；

釋義：皇上告訴使者去找  Primary 主宰相 + AB 兩個從宰相（主宰相有話語權，從宰相聽從主宰相的命令）。

第三步：GFS client 將數據發送至 GFS chunkserver，chunkserver 會緩存這些數據，此時數據並不落盤；

釋義：使者把數據發送給所有宰相，宰相先把數據緩存一下，並不塞到肚子里。

第四步：GFS client 向主 GFS chunkserver 發起同步寫入請求；

釋義：使者告訴 Primary 主宰相可以把數據吞到肚子里了；

第五步：主 GFS chunkserver 將數據寫入本地磁碟並通知其他從 GFS chunkserver 將數據數據落盤；

釋義：Primary 主宰相開始把數據吞到肚子里，並通知 AB 兩個從宰相將數據吞到肚子里；

第六步：主 GFS chunkserver 等待所有從 GFS chunkserver 的數據處理響應；

釋義：Primary 主宰相等待 AB 兩個從宰相數據處理響應結果；

第七步：主 GFS chunkserver 給 GFS 客戶端返回數據寫入成功響應。

釋義：Primary 主宰相告訴使者本次的數據寫入成功了。

結論：想要誰存找皇上；數據存儲找宰相；1主兩從存三份。

我要讀取一個文件，GFS 架構背後又是怎麼流轉的呢？懵懂了寫文件的運轉流程，那讀文件的流轉就相對簡單了不少。

第一步：GFS client 從本地緩存，看文件存儲在哪些 chunk-server 上；

使者從自己緩存中找找文件是由哪些宰相負責；

第二步：如果 GFS client 本地緩存沒有找到，就向 GFS master 查詢文件所在位置；

使者從自己緩存中找不到文件是由哪些宰相負責，就請求皇上查詢有哪些宰相負責存儲；

第三步：GFS master 返回 GFS chunkserver 列表給 GFS client；

皇上返回存儲文件的宰相列表給使者；

第四步：從返回的 chunk-server 里讀文件，返回給 GFS client。

使者找離自己最近的宰相發出讀請求，然後宰相內容返回給使者。

結論：要最快查緩存；緩存沒有找皇上；數據就找近宰相。

反思

架構這麼設計為什麼？是不是在耍流氓！

GFS master 為什麼是單點？簡單就是美！

GFS chunk 塊大小為什麼選擇 64M 呢？

GFS 的高可用、高性能、高可靠是怎麼保證的？

最後，再多說兩句。谷哥“三駕馬車”的出現，才真正把我們帶入了大數據時代，而 GFS 作為其中一架寶車，能夠把大量廉價的普通機器，聚在一起，充分讓每台廉價的機器發揮光和熱，不但降低了運營成本，而且經受了業界實際生產的考驗，本次只是 GFS 管中窺豹，只見得其中一斑，GFS 背後還有很多值得我們學習的地方，慢慢去體會。

好了，如果感覺這篇文章有點意思，請多多分享轉發吧。