閱讀GFS的一點總結

        這是我第一次閱讀學術論文，文章中充斥的一些學術名詞給個人閱讀帶來了一些困難，由於此前沒有接觸過這方面的內容，在同窗的幫助下，查閱了一些資料，終於對GFS有了一點認識，寫出這一些感悟，文章措辭不嚴謹之處，但願諒解。

        提到分佈式系統，就算是外行人的我都知道Google的三駕馬車，GFS正是之一。GFS是一個大型的分佈式文件系統，它爲Google 的雲計算提供海量的存儲，成爲全部核心技術的底層。GFS將整個系統的節點分爲三類：Client（客戶端）、Master（主服務器）和Chunk Server（數據塊服務器）。Client是GFS提供給應用程序的訪問接口，它是一組專用接口，以庫文件的形式提供。應用程序直接調用這些庫函數，並與該庫連接在一塊兒。Master是GFS的管理節點，在邏輯上只有一個，它保存系統的元數據，負責整個文件系統的管理，是GFS文件系統中的核心。Chunk Server負責具體的存儲工做。數據以文件的形式存儲在Chunk Server上，Chunk Server的個數能夠有多個，它的數目直接決定了GFS的規模。GFS將文件按照固定大小進行分塊，默認是64MB，每一塊稱爲一個Chunk，每一個Chunk都有一個對應的索引號，且是惟一不變的。

      與傳統的分佈式系統同樣，GFS 一樣追求高性能、高可靠性、高可用性，但同時 Google 基於自身的生產環境、技術環境，有一些自身獨有的特色。首先，組件失效是常態化的，而非意外。在 GFS 成百上千的集羣中，隨時隨地均可能發生故障致使機器沒法恢復，因此，有必定的容災、自動恢復能力是必需要整合在 GFS 中的。其次，文件巨大，GB 級別的數據很是廣泛。第三，絕大多數文件的寫操做都是追加，而非修改，一般的文件場景是順序寫，且順序讀。第四，應用程序和文件系統 API 的協同設計提升了整個系統的靈活性。

      一個GFS集羣由一個master和大量的chunkserver構成，並被許多Client訪問，只要資源和可靠性容許，chunkserver和client能夠運行在同一個機器上。與每一個應用相聯的GFS客戶代碼實現了文件系統的API並與master和chunkserver通訊以表明應用程序讀和寫數據 。client與master的交換隻限於對metadata的操做，全部數據方面的通訊都直接和chunkserver聯繫 。client和chunkserver都不緩存文件數據,因爲數據太多沒法緩存。不緩存數據簡化了客戶程序和整個系統，由於沒必要考慮緩存的一致性問題，但用戶緩存metadata。Chunkserver 也沒必要緩存文件，由於塊是做爲本地文件存儲的。只有一個master也極大的簡化了設計並使得master能夠根據全局狀況做出先進的塊放置和複製決定。可是咱們必需要將ma ster對讀和寫的參與減至最少，這樣它纔不會成爲系統的瓶頸。Client歷來不會從master讀和寫文件數據。client只是詢問master它應該和哪一個chunkserver聯繫。client在一段限定的時間內將這些信息緩存，在後續的操做中client直接和chunkserver交互。

      當今的時代，是大數據的時代，截止到2012年,數據量已經從TB級別躍升到PB、EB乃至ZB級別，人類生產的全部印刷材料的數據量是200PB,全人類歷史上說過的全部話的數據量大約是5EB，而到了2020年,全世界所產生的數據規模將達到今天的44倍，所以，能夠說沒有GFS就沒有今天的大數據時代。

     以上就是一隻菜雞對一篇論文的簡單認識，若有錯誤之處，但願大佬們幫忙指正。