分布式系統工程實作：GFS&Bigtable設計的優勢，網際網路營銷

　　目前，知名度比較高的通用存儲系統包括：Google GFS&Bigtable，Amazon Dynamo，Microsoft Azure存儲系統及Yahoo PNUTS。其中，GFS&Bigtable，Azure存儲系統及Yahoo PNUTS都有總控節點，Amazon Dynamo采用去中心化的P2P設計。

　　Amazon Dynamo看起來很優美，比如Dynamo論文中提到的技術比較酷，Dynamo沒有中心節點，可以支援更大的系統規模。然而，Dynamo不是我心目中的理想架構，因為Dynamo有一緻性的問題，系統設計複雜但解決的問題有限。如果需要保證一緻性，就必須要求同一時刻對同一份資料隻有一個更新節點，Dynamo顯然不符合要求，可能出現資料丢失等不一緻的情況。雖然對于很多場景能夠通過沖突合并來解決，另外，Dynamo由于采用一緻性Hash的方法進行資料分布，資料不是連續存儲的，不能支援高效的掃描操作，是以資料模型隻能是簡單的<Key, Value>模型，不能支援類似資料倉庫這種需要掃描某個使用者且單個使用者資料量可能特别大的應用場景。總之，去中心化的系統一般有兩個問題：1,一緻性問題；2,順序掃描效率低下。

　　GFS和Bigtable兩層的設計是一個幾乎完美的組合。GFS本質上是一個弱一緻性系統，可能出現重複記錄、記錄亂序等各種問題（後續有文章專門分析原因），Bigtable是GFS之上的一個索引層，為了服務百PB級别的應用，采用兩級的B+樹索引結構。GFS保證成功的記錄至少寫入一次并由Bigtable記錄索引，由于Bigtable是一個強一緻性系統，整個系統對外表現為強一緻性系統。為了保證Bigtable的強一緻性，同一時刻同一份資料隻能被一台機器服務，且Bigtable論文中的Tablet Server對每個Tablet是沒有備份的。當Tablet Server當機時，由于隻需要排序很少的記錄檔并且加載服務的Tablet的索引，當機恢複可以做到一分鐘以内。Bigtable分裂和遷移到隻需要修改或者加載索引資料，是以效率很高，整個系統的擴充性很好。GFS&Bigtable架構廣受質疑之處主要展現在兩個方面：

　　1. GFS&Bigtable架構實時性不好。

　　2. Bigtable Tablet Server的單點問題。

　　第一個對Bigtable實時性的質疑，大體有兩個原因：第一點是由于Bigtable的Tablet和GFS的Chunk可能不在一台機器上，讀取操作可能要走網絡；第二點是由于Bigtable每次随機讀取都需要讀取一塊資料，比如16K, 32K或者64K。第一點可以通過本地化政策來解決，第二點由于磁盤的尋道時間一般為8~10ms，讀取一整塊的overhead不會太高，且Bigtable系統内部的Block Cache和Key-Value Cache可以解決很多問題。開源的HBase和Hypertable由于缺少大規模應用環境還不夠穩定，實時性确實做得不好，不過這不是架構本身的問題，而是架構的複雜性導緻的實作問題。

　　第二個對Bigtable的質疑，我們可以通過多資料中心的Replication來解決：同一個資料中心内部的Bigtable系統保證強一緻性，機房之間通過回放記錄檔進行資料同步，保證最終一緻性。同一時刻隻有一個叢集提供寫服務，其它叢集提供讀服務。當然，對應用方來說仍然是一整套系統，當某台Tablet Server當機時，隻影響短時間部分資料的寫服務，讀服務如果不要求強一緻性不受影響。

　　描述CAP理論時我們經常會說，Dynamo是AP的系統，Bigtable是CA的系統。然而，Bigtable的分區可容忍性做得也還不錯：Bigtable在機房斷電，機房之間網絡故障時仍然可以對外提供服務。假設在三個機房部署了三套Bigtable叢集，且采用三機房五節點的方式部署了Chubby服務，任何一個機房斷電或者某兩個機房之間網絡故障系統仍然能夠對外服務。多個機房同時故障或者三個機房被分成三個區的情況理論上有可能，工程上可以認為不可能。是以，不要為了滿足CAP理論上的特性而設計系統，業務需求才是本質。

　　總之，GFS&Bigtable設計在可擴充性，容錯，負載平衡等各方面都有很大的優勢，并且叢集越大優勢越明顯，問題是整套系統過于複雜，對工程師，應用環境，管理層忍耐力都是一個考驗。