下面的是我對GFS的體悟：
1.系統架設故障是經常發生的。
2.所處理的文件級別很大，上G級別的文件是常事，而且文件大概爲100M左右。
3.大多數的文件是採用append的方式追加到文件結尾的，而不是採用覆蓋寫的方式，採用這種方式是爲了提高寫的效率。
4.將應用和文件系統綜合考慮，做成的這樣的一個GFS 使我們的處理更加靈活。
整個GFS並沒有採用標準的ＡＰＩ形式，比如POSIX，但是仍然支持目錄這種分層的結構。他支持的API有 create,delete,open,close,read,write這些方法。
Master設計
GFS採用中心化管理的方式,這樣將複雜的設計集中在master即可，這樣做也是分佈式系統普遍採用的一個最最簡單，最最容易的設計，如果採用了去中心化的設計，系統的寫性能會提高很多，但是讀性能就會犧牲，比如dynamo。
Master存放的是namespace，訪問控制信息，文件到chunk的映射。還有chunk所在的位置。
Client設計
對於GFS這種大數據應用場景，Client不需要cache 文件數據，因爲數據太大，cache太佔用空間。Client只cache住chunk的metadata，也就是位置信息，當cache過期，或者文件需要被打開的時候。否則Client不用和Master進行交互，節省了一次與Master的交互。
Chunk大小的設計與一致性
對於Chunk大小設計爲64M，爲了減少Master的負擔，因爲首先文件普遍是大文件，如果blocksize 範圍在KB 級別的，那麼將會導致大量的請求與master進行交互，而且將會產生大量的元數據，Master根本就hold不住。
Chunk的存放位置
Master會在開始的時候輪詢所有的ChunkServer，這種操作一直存在，目的有兩個，監控每個節點的狀態，第二個得到所有的Chunk的存放位置，並保持實時。
Operation Log
這個日誌對Master 非常重要，他有多個副本，因爲如果數據丟失的話，或者機器出現故障，是可以通過Operation Log來重新還原數據的。 Operation Log記錄了對metadata的改動，及其時間戳。它定義了併發執行操作的順序。 oplog有多個副本，而且必須等所有的oplog完成之後，才返回。
對於google的集羣而言，機架內的服務器之間的通信能夠達到100M/s，所以延遲非常小。
數據流
當數據寫入到Chunkserver的時候，數據流並不是按照控制流流動的，爲了減少網絡IO瓶頸，數據會先發送到最近的節點S1，然後發送到離S1最近的節點S2，然後是離S2最近的S3。
<script type=text/javascript charset=utf-8 src="http://static.bshare.cn/b/buttonLite.js#style=-1&uuid=&pophcol=3&lang=zh"></script>
<script type=text/javascript charset=utf-8 src="http://static.bshare.cn/b/bshareC0.js"></script>
閱讀(69) | 評論(0) | 轉發(0) |
相關熱門文章
給主人留下些什麼吧！~~
評論熱議