探索googleappengine背后的奧秘

《探索googleappengine背后的奧秘》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、1.Google的核心技術(shù)按：此為客座博文系列。投稿人吳朱華曾在IBM中國研究院從事與云計算相關(guān)的研究，現(xiàn)在正致力于研究云計算技術(shù)。本系列文章基于公開資料對GoogleAppEngine的實現(xiàn)機(jī)制這個話題進(jìn)行深度探討。在切入GoogleAppEngine之前，首先會對Google的核心技術(shù)和其整體架構(gòu)進(jìn)行分析，以幫助大家之后更好地理解GoogleAppEngine的實現(xiàn)。本篇將主要介紹Google的十個核心技術(shù)，而且可以分為四大類：·分布式基礎(chǔ)設(shè)施：GFS、Chubby和ProtocolBuffer?！し植际酱笠?guī)

2、模數(shù)據(jù)處理：MapReduce和Sawzall。·分布式數(shù)據(jù)庫技術(shù)：BigTable和數(shù)據(jù)庫Sharding。·數(shù)據(jù)中心優(yōu)化技術(shù)：數(shù)據(jù)中心高溫化、12V電池和服務(wù)器整合。1.1分布式基礎(chǔ)設(shè)施1.1.1GFS由于搜索引擎需要處理海量的數(shù)據(jù)，所以Google的兩位創(chuàng)始人LarryPage和SergeyBrin在創(chuàng)業(yè)初期設(shè)計一套名為"BigFiles"的文件系統(tǒng)，而GFS（全稱為"GoogleFileSystem"）這套分布式文件系統(tǒng)則是"BigFiles"的延續(xù)。首先，介紹它的架構(gòu)，GFS主要分為兩類節(jié)點：·Mast

3、er節(jié)點：主要存儲與數(shù)據(jù)文件相關(guān)的元數(shù)據(jù)，而不是Chunk（數(shù)據(jù)塊）。元數(shù)據(jù)包括一個能將64位標(biāo)簽映射到數(shù)據(jù)塊的位置及其組成文件的表格，數(shù)據(jù)塊副本位置和哪個進(jìn)程正在讀寫特定的數(shù)據(jù)塊等。還有Master節(jié)點會周期性地接收從每個Chunk節(jié)點來的更新（"Heart-beat"）來讓元數(shù)據(jù)保持最新狀態(tài)。·Chunk節(jié)點：顧名思義，肯定用來存儲Chunk，數(shù)據(jù)文件通過被分割為每個默認(rèn)大小為64MB的Chunk的方式存儲，而且每個Chunk有唯一一個64位標(biāo)簽，并且每個Chunk都會在整個分布式系統(tǒng)被復(fù)制多次，默認(rèn)為3次。

4、下圖就是GFS的架構(gòu)圖：圖1.GFS的架構(gòu)圖（參片[15]）接著，在設(shè)計上，GFS主要有八個特點：·大文件和大數(shù)據(jù)塊：數(shù)據(jù)文件的大小普遍在GB級別，而且其每個數(shù)據(jù)塊默認(rèn)大小為64MB，這樣做的好處是減少了元數(shù)據(jù)的大小，能使Master節(jié)點能夠非常方便地將元數(shù)據(jù)放置在內(nèi)存中以提升訪問效率?！げ僮饕蕴砑訛橹鳎阂驗槲募苌俦粍h減或者覆蓋，通常只是進(jìn)行添加或者讀取操作，這樣能充分考慮到硬盤線性吞吐量大和隨機(jī)讀寫慢的特點?！ぶС秩蒎e：首先，雖然當(dāng)時為了設(shè)計方便，采用了單Master的方案，但是整個系統(tǒng)會保證每個Master

5、都會有其相對應(yīng)的復(fù)制品，以便于在Master節(jié)點出現(xiàn)問題時進(jìn)行切換。其次，在Chunk層，GFS已經(jīng)在設(shè)計上將節(jié)點失敗視為常態(tài)，所以能非常好地處理Chunk節(jié)點失效的問題?！じ咄掏铝浚弘m然其單個節(jié)點的性能無論是從吞吐量還是延遲都很普通，但因為其支持上千的節(jié)點，所以總的數(shù)據(jù)吞吐量是非常驚人的?！けＷo(hù)數(shù)據(jù)：首先，文件被分割成固定尺寸的數(shù)據(jù)塊以便于保存，而且每個數(shù)據(jù)塊都會被系統(tǒng)復(fù)制三份?！U(kuò)展能力強(qiáng)：因為元數(shù)據(jù)偏小，使得一個Master節(jié)點能控制上千個存數(shù)據(jù)的Chunk節(jié)點?！ぶС謮嚎s：對于那些稍舊的文件，可以通過對它

6、進(jìn)行壓縮，來節(jié)省硬盤空間，并且壓縮率非常驚人，有時甚至接近90%?！び脩艨臻g：雖然在用戶空間運行在運行效率方面稍差，但是更便于開發(fā)和測試，還有能更好利用Linux的自帶的一些POSIXAPI?，F(xiàn)在Google內(nèi)部至少運行著200多個GFS集群，最大的集群有幾千臺服務(wù)器，并且服務(wù)于多個Google服務(wù)，比如Google搜索。但由于GFS主要為搜索而設(shè)計，所以不是很適合新的一些Google產(chǎn)品，比YouTube、Gmail和更強(qiáng)調(diào)大規(guī)模索引和實時性的Caffeine搜索引擎等，所以Google已經(jīng)在開發(fā)下一代GFS，

7、代號為"Colossus"，并且在設(shè)計方面有許多不同，比如：支持分布式Master節(jié)點來提升高可用性并能支撐更多文件，Chunk節(jié)點能支持1MB大小的chunk以支撐低延遲應(yīng)用的需要。1.1.2Chubby簡單的來說，Chubby屬于分布式鎖服務(wù)，通過Chubby，一個分布式系統(tǒng)中的上千個client都能夠?qū)τ谀稠椯Y源進(jìn)行"加鎖"或者"解鎖"，常用于BigTable的協(xié)作工作，在實現(xiàn)方面是通過對文件的創(chuàng)建操作來實現(xiàn)"加鎖"，并基于著名科學(xué)家LeslieLamport的Paxos算法。1.1.3ProtocolBu

8、fferProtocolBuffer，是Google內(nèi)部使用一種語言中立、平臺中立和可擴(kuò)展的序列化結(jié)構(gòu)化數(shù)據(jù)的方式，并提供Java、C++和Python這三種語言的實現(xiàn)，每一種實現(xiàn)都包含了相應(yīng)語言的編譯器以及庫文件，而且它是一種二進(jìn)制的格式，所以其速度是使用XML進(jìn)行數(shù)據(jù)交換的10倍左右。它主要用于兩個方面：其一是RPC通信，它可用于分布式應(yīng)用之間或者異構(gòu)環(huán)境下的通信。其