偉人說：“人多力量大，”
尼古拉斯趙四說：“沒有什么事，是一頓飯解決不了的！！！如果有，那就兩頓，”
研發說：“需求太多，人手不夠，”
專家說：“人手不夠，那就協調資源，攢人頭，”
釋義：一人拾柴火不旺，眾人拾柴火焰高，一人難挑千斤擔，眾人能移萬座山，
運維說：“一臺機器不夠；一個服務扛不住壓力，”
專家說：“一臺機器不夠，那就多申請幾臺；一個服務扛不住壓力，那就多部署幾個，”
釋義：一箭易斷，十箭難折，一根線容易斷，萬根線能拉船，
從事互聯網開發時間久了，參加大大小小的會議，時不時總會討論或爭執類似“人手不夠、機器不夠、服務扛不住”等一類的資源問題，但是到最后解決方案，貌似都是進行資源協調，如果人手不夠，就協調資源攢人頭；如果機器不夠，就協調資源加幾臺；如果一個服務扛不住壓力，那就協調資源多部署幾個，
所有的一切都離不開：攢、加 ... ... ，總之就是考慮如何從 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 背后還有很多值得我們學習的地方，慢慢去體會，
好了，如果感覺這篇文章有點意思，請多多分享轉發吧，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/19683.html
標籤：大數據
上一篇：flink 一分鐘入門篇
下一篇：谷歌 MapReduce 初探