1、HTML靜態(tài)化

其實大家都知道，效率最高、消耗最小的就是純靜態(tài)化的html頁面，所以我們盡可能使我們的網(wǎng)站上的頁面采納靜態(tài)頁面來實現(xiàn)，這個最簡潔的方法其實也是最有效的方法。但是對于大量內(nèi)容并且頻繁更新的網(wǎng)站，我們無法全部手動去挨個實現(xiàn)，于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng)CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實現(xiàn)的，信息發(fā)布系統(tǒng)可以實現(xiàn)最簡潔的信息錄入自動生成靜態(tài)頁面，還能具備頻道管理、權(quán)限管理、自動抓取等功能，對于一個大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不行少的。

除了門戶和信息發(fā)布類型的網(wǎng)站，對于交互性要求很高的社區(qū)類型網(wǎng)站來說，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內(nèi)的帖子、文章進(jìn)展實時的靜態(tài)化，有更新的時候再重新靜態(tài)化也是大量運用的策略，像Mop的大雜燴就是運用了這樣的策略，網(wǎng)易社區(qū)等也是如此。

同時，html靜態(tài)化也是某些緩存策略運用的手段，對于系統(tǒng)中頻繁運用數(shù)據(jù)庫查詢但是內(nèi)容更新很小的應(yīng)用，可以考慮運用html靜態(tài)化來實現(xiàn)，比方論壇中論壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進(jìn)展后臺管理并且存儲再數(shù)據(jù)庫中，這些信息其實大量被前臺程序調(diào)用，但是更新頻率很小，可以考慮將這局部內(nèi)容進(jìn)展后臺更新的時候進(jìn)展靜態(tài)化，這樣防止了大量的數(shù)據(jù)庫訪問懇求。

2、圖片效勞器別離

大家知道，對于Web效勞器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進(jìn)展別離，這是根本上大型網(wǎng)站都會采納的策略，他們都有獨立的圖片效勞器，甚至很多臺圖片效勞器。這樣的架構(gòu)可以降低供應(yīng)頁面訪問懇求的效勞器系統(tǒng)壓力，并且可以保證系統(tǒng)不會因為圖片問題而崩潰，在應(yīng)用效勞器和圖片效勞器上，可以進(jìn)展不同的配置優(yōu)化，比方apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率。

3、數(shù)據(jù)庫集群和庫表散列

大型網(wǎng)站都有困難的應(yīng)用，這些應(yīng)用必需運用數(shù)據(jù)庫，那么在面對大量訪問的時候，數(shù)據(jù)庫的瓶頸很快就能顯現(xiàn)出來，這時一臺數(shù)據(jù)庫將很快無法滿意應(yīng)用，于是我們須要運用數(shù)據(jù)庫集群或者庫表散列。

在數(shù)據(jù)庫集群方面，很多數(shù)據(jù)庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL供應(yīng)的Master/Slave也是類似的方案，您運用了什么樣的DB，就參考相應(yīng)的解決方案來實施即可。

上面提到的數(shù)據(jù)庫集群由于在架構(gòu)、本錢、擴(kuò)張性方面都會受到所采納DB類型的限制，于是我們須要從應(yīng)用程序的角度來考慮改善系統(tǒng)架構(gòu)，庫表散列是常用并且最有效的解決方案。我們在應(yīng)用程序中安裝業(yè)務(wù)和應(yīng)用或者功能模塊將數(shù)據(jù)庫進(jìn)展別離，不同的模塊對應(yīng)不同的數(shù)據(jù)庫或者表，再依據(jù)確定的策略對某個頁面或者功能進(jìn)展更小的數(shù)據(jù)庫散列，比方用戶表，依據(jù)用戶ID進(jìn)展表散列，這樣就能夠低本錢的提升系統(tǒng)的性能并且有很好的擴(kuò)展性。sohu的論壇就是采納了這樣的架構(gòu)，將論壇的用戶、設(shè)置、帖子等信息進(jìn)展數(shù)據(jù)庫別離，然后對帖子、用戶依據(jù)板塊和ID進(jìn)展散列數(shù)據(jù)庫和表，最終可以在配置文件中進(jìn)展簡潔的配置便能讓系統(tǒng)隨時增加一臺低本錢的數(shù)據(jù)庫進(jìn)來補(bǔ)充系統(tǒng)性能。

4、緩存

緩存一詞搞技術(shù)的都接觸過，很多地方用到緩存。網(wǎng)站架構(gòu)和網(wǎng)站開發(fā)中的緩存也是特別重要。這里先講解并描述最根本的兩種緩存。高級和分布式的緩存在后面講解并描述。

架構(gòu)方面的緩存，對Apache比擬熟識的人都能知道Apache供應(yīng)了自己的緩存模塊，也可以運用外加的Squid模塊進(jìn)展緩存，這兩種方式均可以有效的提高Apache的訪問響應(yīng)實力。

網(wǎng)站程序開發(fā)方面的緩存，Linux上供應(yīng)的MemoryCache是常用的緩存接口，可以在web開發(fā)中運用，比方用Java開發(fā)的時候就可以調(diào)用MemoryCache對一些數(shù)據(jù)進(jìn)展緩存和通訊共享，一些大型社區(qū)運用了這樣的架構(gòu)。另外，在運用web語言開發(fā)的時候，各種語言根本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟識，信任也確定有。

5、鏡像

鏡像是大型網(wǎng)站常采納的提高性能和數(shù)據(jù)平安性的方式，鏡像的技術(shù)可以解決不同網(wǎng)絡(luò)接入商和地域帶來的用戶訪問速度差異，比方ChinaNet和EduNet之間的差異就促使了很多網(wǎng)站在教化網(wǎng)內(nèi)搭建鏡像站點，數(shù)據(jù)進(jìn)展定時更新或者實時更新。在鏡像的細(xì)微環(huán)節(jié)技術(shù)方面，這里不闡述太深，有很多專業(yè)的現(xiàn)成的解決架構(gòu)和產(chǎn)品可選。也有廉價的通過軟件實現(xiàn)的思路，比方Linux上的rsync等工具。

6、負(fù)載均衡

負(fù)載均衡將是大型網(wǎng)站解決高負(fù)荷訪問和大量并發(fā)懇求采納的終極解決方法。

負(fù)載均衡技術(shù)開展了多年，有很多專業(yè)的效勞供應(yīng)商和產(chǎn)品可以選擇，我個人接觸過一些解決方法，其中有兩個架構(gòu)可以給大家做參考。

7、硬件四層交換

第四層交換運用第三層和第四層信息包的報頭信息，依據(jù)應(yīng)用區(qū)間識別業(yè)務(wù)流，將整個區(qū)間段的業(yè)務(wù)流安排到相宜的應(yīng)用效勞器進(jìn)展處理。第四層交換功能就象是虛IP，指向物理效勞器。它傳輸?shù)臉I(yè)務(wù)聽從的協(xié)議多種多樣，有、、Telnet或其他協(xié)議。這些業(yè)務(wù)在物理效勞器根底上，須要困難的載量平衡算法。在IP世界，業(yè)務(wù)類型由終端TCP或UDP端口地址來確定，在第四層交換中的應(yīng)用區(qū)間那么由源端和終端IP地址、TCP和UDP端口共同確定。

在硬件四層交換產(chǎn)品領(lǐng)域，有一些知名的產(chǎn)品可以選擇，比方Alteon、F5等，這些產(chǎn)品很昂貴，但是物有所值，能夠供應(yīng)特別優(yōu)秀的性能和很敏捷的管理實力。Yahoo中國當(dāng)時接近2000臺效勞器運用了三四臺Alteon就搞定了。

8、軟件四層交換

大家知道了硬件四層交換機(jī)的原理后，基于OSI模型來實現(xiàn)的軟件四層交換也就應(yīng)運而生，這樣的解決方案實現(xiàn)的原理一樣，不過性能稍差。但是滿意確定量的壓力還是游刃有余的，有人說軟件實現(xiàn)方式其實更敏捷，處理實力完全看你配置的熟識實力。

軟件四層交換我們可以運用Linux上常用的LVS來解決，LVS就是LinuxVirtualServer，他供應(yīng)了基于心跳線heartbeat的實時災(zāi)難應(yīng)對解決方案，提高系統(tǒng)的魯棒性，同時可供了敏捷的虛擬VIP配置和管理功能，可以同時滿意多種應(yīng)用需求，這對于分布式的系統(tǒng)來說必不行少。

一個典型的運用負(fù)載均衡的策略就是，在軟件或者硬件四層交換的根底上搭建squid集群，這種思路在很多大型網(wǎng)站包括搜尋引擎上被采納，這樣的架構(gòu)低本錢、高性能還有很強(qiáng)的擴(kuò)張性，隨時往架構(gòu)里面增減節(jié)點都特別簡潔。這樣的架構(gòu)我打算空了特地具體整理一下和大家探討。

對于大型網(wǎng)站來說，前面提到的每個方法可能都會被同時運用到，我這里介紹得比擬淺顯，具體實現(xiàn)過程中很多細(xì)微環(huán)節(jié)還須要大家漸漸熟識和體會，有時一個很小的squid參數(shù)或者apache參數(shù)設(shè)置，對于系統(tǒng)性能的影響就會很大，希望大家一起探討，到達(dá)拋磚引玉之效。用squid做webcacheserver，而apache在squid的后面供應(yīng)真正的web效勞。當(dāng)然運用這樣的架構(gòu)必須要保證主頁上大局部都是靜態(tài)頁面。這就須要程序員的協(xié)作將頁面在反應(yīng)給客戶端之前將頁面全部轉(zhuǎn)換成靜態(tài)頁面。根本看出sina和sohu對于頻道等欄目都用了一樣的技術(shù)，即squid來監(jiān)聽這些IP的80端口，而真正的webserver來監(jiān)聽另外一個端口。從用戶的感覺上來說不會有任何的區(qū)分，而相對于將webserver干脆和客戶端連在一起的方式，這樣的方式明顯的節(jié)約的帶寬和效勞器。用戶訪問的速度感覺也會更快。帶寬：4000M/S(參考)

效勞器數(shù)量：60臺左右

Web效勞器：Ligd,Apache,nginx

應(yīng)用效勞器：Tomcat

其他：Python,Java,MogileFS、ImageMagick等關(guān)于Squid與TomcatSquid與Tomcat好像在Web2.0站點的架構(gòu)中較少看到。我首先是對Squid有點疑問，對此阿華的說明是"目前短暫還沒找到效率比Squid高的緩存系統(tǒng)，原來命中率的確很差，后來在Squid前又裝了層Ligd,基于url做hash,同一個圖片始終會到同一臺squid去，所以命中率徹底提高了"對于應(yīng)用效勞器層的Tomcat，現(xiàn)在Yupoo!技術(shù)人員也在漸漸用其他輕量級的東西替代，而YPWS/YPFS現(xiàn)在已經(jīng)用Python進(jìn)綻開發(fā)了。名次說明：YPWS--YupooWebServerYPWS是用Python開發(fā)的一個小型Web效勞器，供應(yīng)根本的Web效勞外，可以增加針對用戶、圖片、外鏈網(wǎng)站顯示的邏輯推斷，可以安裝于任何有空閑資源的效勞器中，遇到性能瓶頸時便利橫向擴(kuò)展。YPFS--Yupoo與YPWS類似，YPFS也是基于這個Web效勞器上開發(fā)的圖片上傳效勞器。

【Updated:有網(wǎng)友留言質(zhì)疑Python的效率，Yupoo老大劉平陽在del.icio.us上寫到"YPWS用Python自己寫的，每臺機(jī)器每秒可以處理294個懇求,現(xiàn)在壓力幾乎都在10％以下"】圖片處理層接下來的ImageProcessServer負(fù)責(zé)處理用戶上傳的圖片。運用的軟件包也是ImageMagick，在上次存儲升級的同時，對于銳化的比率也調(diào)整過了(我個人感覺，效果的確好了很多)。〞Magickd“是圖像處理的一個遠(yuǎn)程接口效勞，可以安裝在任何有空閑CPU資源的機(jī)器上，類似Memcached的效勞方式。我們知道Flickr的縮略圖功能原來是用ImageMagick軟件包的，后來被雅虎收購后出于版權(quán)緣由而不用了〔?〕；EXIF與IPTCFlicke是用Perl抽取的，我是特別建議Yupoo!針對EXIF做些文章，這也是潛在產(chǎn)生受益的一個重點。圖片存儲層原來Yupoo!的存儲采納了磁盤陣列柜，基于NFS方式的，隨著數(shù)據(jù)量的增大，〞Yupoo!開發(fā)部從07年6月份就開場著手探討一套大容量的、能滿意Yupoo!今后開展須要的、平安牢靠的存儲系統(tǒng)“，看來Yupoo!系統(tǒng)比擬有信念，也是滿懷期盼的，終歸這要支撐以TB計算的海量圖片的存儲和管理。我們知道，一張圖片除了原圖外，還有不同尺寸的，這些圖片統(tǒng)一存儲在MogileFS中。對于其他局部，常見的Web2.0網(wǎng)站必需軟件都能看到，如MySQL、Memcached、Ligd等。Yupoo!一方面采納不少相比照擬成熟的開源軟件，一方面也在自行開發(fā)定制適合自己的架構(gòu)組件。這也是一個Web2.0公司所必須要走的一個途徑。特別感謝一下Yupoo!阿華對于技術(shù)信息的共享，技術(shù)是共通的。下一個能爆料是哪家?--EOF--ligd+squid這套緩存是放在另外一個機(jī)房作為cdn的一個節(jié)點運用的，圖中沒描繪清晰，給大家?guī)聿槐懔恕?/p>

squid前端用ligd沒用nginx，主要是用了這么久，沒出啥大問題，所以就沒想其他的了。

URLHash的擴(kuò)展性的確不好，能做的就是不輕易去增減效勞器，我們目前是5臺效勞器做一組hash.我們現(xiàn)在用Python寫的WebServer，在效率方面，我可以給個測試數(shù)據(jù)，依據(jù)目前的訪問日志模擬訪問測試的結(jié)果是1臺ypws,平均每秒處理294個懇求(加載全部的邏輯推斷)。

在牢靠性上，還不沒具體的數(shù)據(jù)，目前運行1個多月還沒有任何異樣。lvs每個節(jié)點上都裝nginx，主要是為了反向代理及處理靜態(tài)內(nèi)容，不過apache已顯得不是那么必需，打算漸漸去掉。我們處理圖片都是即時的，我們目前半數(shù)以上的效勞器都裝了magickd效勞，用來分擔(dān)圖片處理懇求。每天數(shù)以千萬計的Blog內(nèi)容中，實時的熱點是什么?Tailrank這個Web2.0Startup致力于答復(fù)這個問題。特地爆料網(wǎng)站架構(gòu)的ToddHoff對KevinBurton進(jìn)展了采訪。于是我們能了解一下Tailrank架構(gòu)的一些信息。每小時索引2400萬的Blog與Feed，內(nèi)容處理實力為160-200Mbps，IO寫入大約在10-15MBps。每個月要處理52T之多的原始數(shù)據(jù)。Tailrank所用的爬蟲現(xiàn)在已經(jīng)成為一個獨立產(chǎn)品：spinn3r。效勞器硬件目前大約15臺效勞器，CPU是64位的Opteron。每臺主機(jī)上掛兩個SATA盤，做RAID0。據(jù)我所知，國內(nèi)很多Web2.0公司也用的是類似的方式，SATA盤容量達(dá)，低廉價格，堪稱不二之選。操作系統(tǒng)用的是DebianLinux。Web效勞器用Apache2.0，Squid做反向代理效勞器。數(shù)據(jù)庫Tailrank用MySQL數(shù)據(jù)庫，聯(lián)邦數(shù)據(jù)庫形式。存儲引擎用InnoDB，數(shù)據(jù)量500GB。KevinBurton也指出了MySQL5在修了一些多核模式下互斥鎖的問題(ThisBug?)。到數(shù)據(jù)庫的JDBC驅(qū)動連接池用lbpool做負(fù)載均衡。MySQLSlave或者M(jìn)aster的復(fù)制用MySQLSlaveSync來輕松完成。不過即使這樣，還要花費20％的時間來折騰DB。其他開放的軟件任何一套系統(tǒng)都離不開相宜的Profiling工具，Tailrank也不利外，針對Java程序的Benchmark用Benchmark4j。Log工具用Log5j(不是Log4j)。Tailrank所用的大局部工具都是開放的。Tailrank的一個比擬大的競爭對手是Techmeme，雖然二者短暫看面對內(nèi)容的側(cè)重點有所不同。其實，最大的對手還是自己，當(dāng)須要挖掘的信息量越來越大，假如精準(zhǔn)并剛好的呈現(xiàn)給用戶內(nèi)容的本錢會越來越高。從現(xiàn)在來看，Tailrank離預(yù)期目標(biāo)還差的很遠(yuǎn)。期盼羅馬早日建成YouTube架構(gòu)學(xué)習(xí)關(guān)鍵字:YouTube原文:YouTubeArchitecture

YouTube開展快速，每天超過1億的視頻點擊量，但只有很少人在維護(hù)站點和確保伸縮性。

平臺

Apache

Python

Linux(SuSe)

MySQL

psyco，一個動態(tài)的Python到C的編譯器

ligd代替Apache做視頻查看

狀態(tài)

支持每天超過1億的視頻點擊量

成立于2005年2月

于2006年3月到達(dá)每天3千萬的視頻點擊量

于2006年7月到達(dá)每天1億的視頻點擊量

2個系統(tǒng)管理員，2個伸縮性軟件架構(gòu)師

2個軟件開發(fā)工程師，2個網(wǎng)絡(luò)工程師，1個DBA

處理飛速增長的流量Java代碼while

(true)

{

identify_and_fix_bottlenecks();

drink();

sleep();

notice_new_bottleneck();

}

每天運行該循環(huán)屢次

Web效勞器

1，NetScaler用于負(fù)載均衡和靜態(tài)內(nèi)容緩存

2，運用mod_fast_cgi運行Apache

3，運用一個Python應(yīng)用效勞器來處理懇求的路由

4，應(yīng)用效勞器與多個數(shù)據(jù)庫和其他信息源交互來獲得數(shù)據(jù)和格式化html頁面

5，一般可以通過添加更多的機(jī)器來在Web層提高伸縮性

6，Python的Web層代碼通常不是性能瓶頸，大局部時間堵塞在RPC

7，Python允許快速而敏捷的開發(fā)和部署

8，通常每個頁面效勞少于100毫秒的時間

9，運用psyco(一個類似于JIT編譯器的動態(tài)的Python到C的編譯器)來優(yōu)化內(nèi)部循環(huán)

10，對于像加密等密集型CPU活動，運用C擴(kuò)展

11，對于一些開銷昂貴的塊運用預(yù)先生成并緩存的html

12，數(shù)據(jù)庫里運用行級緩存

13，緩存完整的Python對象

14，有些數(shù)據(jù)被計算出來并發(fā)送給各個程序，所以這些值緩存在本地內(nèi)存中。這是個運用不當(dāng)?shù)牟呗?。?yīng)用效勞器里最快的緩存將預(yù)先計算的值發(fā)送給全部效勞器也花不了多少時間。只需弄一個代理來監(jiān)聽更改，預(yù)料算，然后發(fā)送。

視頻效勞

1，花費包括帶寬，硬件和能源消耗

2，每個視頻由一個迷你集群來host，每個視頻被超過一臺機(jī)器持有

3，運用一個集群意味著：

-更多的硬盤來持有內(nèi)容意味著更快的速度

-failover。假如一臺機(jī)器出故障了，另外的機(jī)器可以接著效勞

-在線備份

4，運用ligd作為Web效勞器來供應(yīng)視頻效勞：

-Apache開銷太大

-運用epoll來等待多個fds

-從單進(jìn)程配置轉(zhuǎn)變?yōu)槎噙M(jìn)程配置來處理更多的連接

5，大局部流行的內(nèi)容移到CDN：

-CDN在多個地方備份內(nèi)容，這樣內(nèi)容離用戶更近的時機(jī)就會更高

-CDN機(jī)器常常內(nèi)存缺乏，因為內(nèi)容太流行以致很少有內(nèi)容進(jìn)出內(nèi)存的顛簸

6，不太流行的內(nèi)容(每天1-20閱讀次數(shù))在很多colo站點運用YouTube效勞器

-長尾效應(yīng)。一個視頻可以有多個播放，但是很多視頻正在播放。隨機(jī)硬盤塊被訪問

-在這種狀況下緩存不會很好，所以花錢在更多的緩存上可能沒太大意義。

-調(diào)整RAID限制并留意其他低級問題

-調(diào)整每臺機(jī)器上的內(nèi)存，不要太多也不要太少

視頻效勞關(guān)鍵點

1，保持簡潔和廉價

2，保持簡潔網(wǎng)絡(luò)路徑，在內(nèi)容和用戶間不要有太多設(shè)備

3，運用常用硬件，昂貴的硬件很難找到幫助文檔

4，運用簡潔而常見的工具，運用構(gòu)建在Linux里或之上的大局部工具

5，很好的處理隨機(jī)查找(SATA，tweaks)

縮略圖效勞

1，做到高效令人驚異的難

2，每個視頻也許4張縮略圖，所以縮略圖比視頻多很多

3，縮略圖僅僅host在幾個機(jī)器上

4，持有一些小東西所遇到的問題：

-OS級別的大量的硬盤查找和inode和頁面緩存問題

-單書目文件限制，特殊是Ext3，后來移到多分層的構(gòu)造。內(nèi)核2.6的最近改良可能讓Ext3允許大書目，但在一個文件系統(tǒng)里存儲大量文件不是個好辦法

-每秒大量的懇求，因為Web頁面可能在頁面上顯示60個縮略圖

-在這種高負(fù)載下Apache表現(xiàn)的特別糟糕

-在Apache前端運用squid，這種方式工作了一段時間，但是由于負(fù)載接著增加而以失敗告終。它讓每秒300個懇求變?yōu)?0個

-嘗試運用ligd但是由于運用單線程它陷于逆境。遇到多進(jìn)程的問題，因為它們各自保持自己單獨的緩存

-如此多的圖片以致一臺新機(jī)器只能接收24小時

-重啟機(jī)器須要6-10小時來緩存

5，為了解決全部這些問題YouTube開場運用Google的BigTable，一個分布式數(shù)據(jù)存儲：

-防止小文件問題，因為它將文件收集到一起

-快，錯誤容忍

-更低的延遲，因為它運用分布式多級緩存，該緩存與多個不同collocation站點工作

-更多信息參考GoogleArchitecture，GoogleTalkArchitecture和BigTable

數(shù)據(jù)庫

1，早期

-運用MySQL來存儲元數(shù)據(jù)，如用戶，tags和描述

-運用一整個10硬盤的RAID10來存儲數(shù)據(jù)

-依靠于信用卡所以YouTube租用硬件

-YouTube經(jīng)過一個常見的革命：單效勞器，然后單master和多readslaves，然后數(shù)據(jù)庫分區(qū)，然后sharding方式

-苦痛與備份延遲。master數(shù)據(jù)庫是多線程的并且運行在一個大機(jī)器上所以它可以處理很多工作，slaves是單線程的并且通常運行在小一些的效勞器上并且備份是異步的，所以slaves會遠(yuǎn)遠(yuǎn)落后于master

-更新引起緩存失效，硬盤的慢I/O導(dǎo)致慢備份

-運用備份架構(gòu)須要花費大量的money來獲得增加的寫性能

-YouTube的一個解決方案是通過把數(shù)據(jù)分成兩個集群來將傳輸分出優(yōu)先次序：一個視頻查看池和一個一般的集群

2，后期

-數(shù)據(jù)庫分區(qū)

-分成shards，不同的用戶指定到不同的shards

-擴(kuò)散讀寫

-更好的緩存位置意味著更少的IO

-導(dǎo)致硬件削減30%

-備份延遲降低到0

-現(xiàn)在可以隨意提升數(shù)據(jù)庫的伸縮性

數(shù)據(jù)中心策略

1，依靠于信用卡，所以最初只能運用受管主機(jī)供應(yīng)商

2，受管主機(jī)供應(yīng)商不能供應(yīng)伸縮性，不能限制硬件或運用良好的網(wǎng)絡(luò)協(xié)議

3，YouTube改為運用colocationarrangement。現(xiàn)在YouTube可以自定義全部東西并且協(xié)定自己的契約

4，運用5到6個數(shù)據(jù)中心加CDN

5，視頻來自隨意的數(shù)據(jù)中心，不是最近的匹配或其他什么。假如一個視頻足夠流行那么移到CDN

6，依靠于視頻帶寬而不是真正的延遲。可以來自任何colo

7，圖片延遲很嚴(yán)峻，特殊是當(dāng)一個頁面有60張圖片時

8，運用BigTable將圖片備份到不同的數(shù)據(jù)中心，代碼查看誰是最近的

學(xué)到的東西

1，Stallfortime。創(chuàng)建性和風(fēng)險性的技巧讓你在短期內(nèi)解決問題而同時你會發(fā)覺長期的解決方案

2，Proioritize。找出你的效勞中核心的東西并對你的資源分出優(yōu)先級別

3，Pickyourbattles。別怕將你的核心效勞分出去。YouTube運用CDN來分布它們最流行的內(nèi)容。創(chuàng)立自己的網(wǎng)絡(luò)將花費太多時間和太多money

4，Keepitsimple！簡潔允許你更快的重新架構(gòu)來回應(yīng)問題

5，Shard。Sharding幫助隔離存儲，CPU，內(nèi)存和IO，不僅僅是獲得更多的寫性能

6，Constantiterationonbottlenecks：

-軟件：DB，緩存

-OS：硬盤I/O

-硬件：內(nèi)存，RAID

7，Yousucceedasateam。擁有一個跨越條律的了解整個系統(tǒng)并知道系統(tǒng)內(nèi)部是什么樣的團(tuán)隊，如安裝打印機(jī)，安裝機(jī)器，安裝網(wǎng)絡(luò)等等的人。Withagoodteamallthingsarepossible。Google架構(gòu)學(xué)習(xí)關(guān)鍵字:Google原文：GoogleArchitecture

Google是伸縮性的王者。Google始終的目標(biāo)就是構(gòu)建高性能高伸縮性的根底組織來支持它們的產(chǎn)品。

平臺

Linux

大量語言：Python，Java，C++

狀態(tài)

在2006年大約有450,000臺廉價效勞器

在2005年Google索引了80億Web頁面，現(xiàn)在沒有人知道數(shù)目

目前在Google有超過200個GFS集群。一個集群可以有1000或者甚至5000臺機(jī)器。成千上萬的機(jī)器從運行著50000字節(jié)存儲的GFS集群獲得數(shù)據(jù)，集群總的讀寫吞吐量可以到達(dá)每秒40兆字節(jié)

目前在Google有6000個MapReduce程序，而且每個月都寫成百個新程序

BigTable伸縮存儲幾十億的URL，幾百千千兆的衛(wèi)星圖片和幾億用戶的參數(shù)選擇

堆棧

Google形象化它們的根底組織為三層架構(gòu)：

1，產(chǎn)品：搜尋，廣告，email，地圖，視頻，閑聊，博客

2，分布式系統(tǒng)根底組織：GFS，MapReduce和BigTable

3，計算平臺：一群不同的數(shù)據(jù)中心里的機(jī)器

4，確保公司里的人們部署起來開銷很小

5，花費更多的錢在防止丟失日志數(shù)據(jù)的硬件上，其他類型的數(shù)據(jù)那么花費較少

可信任的存儲機(jī)制GFS(Google)

1，可信任的伸縮性存儲是任何程序的核心需求。GFS就是Google的核心存儲平臺

2，Google-大型分布式構(gòu)造化日志文件系統(tǒng)，Google在里面扔了大量的數(shù)據(jù)

3，為什么構(gòu)建GFS而不是利用已有的東西？因為可以自己限制一切并且這個平臺與別的不一樣，Google須要：

-跨數(shù)據(jù)中心的高牢靠性

-成千上萬的網(wǎng)絡(luò)節(jié)點的伸縮性

-大讀寫帶寬的需求

-支持大塊的數(shù)據(jù)，可能為上千兆字節(jié)

-高效的跨節(jié)點操作分發(fā)來削減瓶頸

4，系統(tǒng)有Master和Chunk效勞器

-Master效勞器在不同的數(shù)據(jù)文件里保持元數(shù)據(jù)。數(shù)據(jù)以64MB為單位存儲在文件系統(tǒng)中?？蛻舳伺cMaster效勞器溝通來在文件上做元數(shù)據(jù)操作并且找到包含用戶須要數(shù)據(jù)的那些Chunk效勞器

-Chunk效勞器在硬盤上存儲實際數(shù)據(jù)。每個Chunk效勞器跨越3個不同的Chunk效勞器備份以創(chuàng)立冗余來防止效勞器崩潰。一旦被Master效勞器指明，客戶端程序就會干脆從Chunk效勞器讀取文件

6，一個上線的新程序可以運用已有的GFS集群或者可以制作自己的GFS集群

7，關(guān)鍵點在于有足夠的根底組織來讓人們對自己的程序有所選擇，GFS可以調(diào)整來適應(yīng)個別程序的需求

運用MapReduce來處理數(shù)據(jù)

1，現(xiàn)在你已經(jīng)有了一個很好的存儲系統(tǒng)，你該怎樣處理如此多的數(shù)據(jù)呢？比方你有很多TB的數(shù)據(jù)存儲在1000臺機(jī)器上。數(shù)據(jù)庫不能伸縮或者伸縮到這種級別花費極大，這就是MapReduce出現(xiàn)的緣由

2，MapReduce是一個處理和生成大量數(shù)據(jù)集的編程模型和相關(guān)實現(xiàn)。用戶指定一個map方法來處理一個鍵/值對來生成一個中間的鍵/值對，還有一個reduce方法來合并全部關(guān)聯(lián)到同樣的中間鍵的中間值。很多真實世界的任務(wù)都可以運用這種模型來表現(xiàn)。以這種風(fēng)格來寫的程序會自動并行的在一個大量機(jī)器的集群里運行。運行時系統(tǒng)照看輸入數(shù)據(jù)劃分、程序在機(jī)器集之間執(zhí)行的調(diào)度、機(jī)器失敗處理和必需的內(nèi)部機(jī)器溝通等細(xì)微環(huán)節(jié)。這允許程序員沒有多少并行和分布式系統(tǒng)的經(jīng)驗就可以很簡潔運用一個大型分布式系統(tǒng)資源

3，為什么運用MapReduce？

-跨越大量機(jī)器分割任務(wù)的好方式

-處理機(jī)器失敗

-可以與不同類型的程序工作，例如搜尋和廣告。幾乎任何程序都有map和reduce類型的操作。你可以預(yù)先計算有用的數(shù)據(jù)、查詢字?jǐn)?shù)統(tǒng)計、對TB的數(shù)據(jù)排序等等

4，MapReduce系統(tǒng)有三種不同類型的效勞器

-Master效勞器安排用戶任務(wù)到Map和Reduce效勞器。它也跟蹤任務(wù)的狀態(tài)

-Map效勞器接收用戶輸入并在其根底上處理map操作。結(jié)果寫入中間文件

-Reduce效勞器接收Map效勞器產(chǎn)生的中間文件并在其根底上處理reduce操作

5，例如，你想在全部Web頁面里的字?jǐn)?shù)。你將存儲在GFS里的全部頁面拋入MapReduce。這將在成千上萬臺機(jī)器上同時進(jìn)展并且全部的調(diào)整、工作調(diào)度、失敗處理和數(shù)據(jù)傳輸將自動完成

-步驟類似于：GFS->Map->Shuffle->Reduction->StoreResultsbackintoGFS

-在MapReduce里一個map操作將一些數(shù)據(jù)映射到另一個中，產(chǎn)生一個鍵值對，在我們的例子里就是字和字?jǐn)?shù)

-Shuffling操作聚集鍵類型

-Reduction操作計算全部鍵值對的綜合并產(chǎn)生最終的結(jié)果

6，Google索引操作管道有大約20個不同的map和reduction。

7，程序可以特別小，如20到50行代碼

8，一個問題是落伍者。落伍者是一個比其他程序慢的計算，它堵塞了其他程序。落伍者可能因為緩慢的IO或者臨時的CPU不能運用而發(fā)生。解決方案是運行多個同樣的計算并且當(dāng)一個完成后殺死全部其他的

9，數(shù)據(jù)在Map和Reduce效勞器之間傳輸時被壓縮了。這可以節(jié)約帶寬和I/O。

在BigTable里存儲構(gòu)造化數(shù)據(jù)

1，BigTable是一個大伸縮性、錯誤容忍、自管理的系統(tǒng)，它包含千千兆的內(nèi)存和10000的存儲。它可以每秒鐘處理百萬的讀寫

2，BigTable是一個構(gòu)建于GFS之上的分布式哈希機(jī)制。它不是關(guān)系型數(shù)據(jù)庫。它不支持join或者SQL類型查詢

3，它供應(yīng)查詢機(jī)制來通過鍵訪問構(gòu)造化數(shù)據(jù)。GFS存儲存儲不透亮的數(shù)據(jù)而很多程序需求有構(gòu)造化數(shù)據(jù)

4，商業(yè)數(shù)據(jù)庫不能到達(dá)這種級別的伸縮性并且不能在成千上萬臺機(jī)器上工作

5，通過限制它們自己的低級存儲系統(tǒng)Google得到更多的限制權(quán)來改良它們的系統(tǒng)。例如，假如它們想讓跨數(shù)據(jù)中心的操作更簡潔這個特性，它們可以內(nèi)建它

6，系統(tǒng)運行時機(jī)器可以自由的增刪而整個系統(tǒng)保持工作

7，每個數(shù)據(jù)條目存儲在一個格子里，它可以通過一個行key和列key或者時間戳來訪問

8，每一行存儲在一個或多個tablet中。一個tablet是一個64KB塊的數(shù)據(jù)序列并且格式為SSTable

9，BigTable有三種類型的效勞器：

-Master效勞器安排tablet效勞器，它跟蹤tablet在哪里并且假如須要那么重新安排任務(wù)

-Tablet效勞器為tablet處理讀寫懇求。當(dāng)tablet超過大小限制(通常是100MB-200MB)時它們拆開tablet。當(dāng)一個Tablet效勞器失敗時，那么100個Tablet效勞器各自選擇一個新的tablet然后系統(tǒng)復(fù)原。

-Lock效勞器形成一個分布式鎖效勞。像翻開一個tablet來寫、Master調(diào)整和訪問限制檢查等都須要互斥

10，一個locality組可以用來在物理上將相關(guān)的數(shù)據(jù)存儲在一起來得到更好的locality選擇

11，tablet盡可能的緩存在RAM里

硬件

1，當(dāng)你有很多機(jī)器時你怎樣組織它們來使得運用和花費有效？

2，運用特別廉價的硬件

3，A1,000-foldcomputerpowerincreasecanbehadfora33timeslowercostifyouyouuseafailure-proneinfrastructureratherthananinfrastructurebuiltonhighlyreliablecomponents.Youmustbuildreliabilityontopofunreliabilityforthisstrategytowork.

4，Linux，in-houserackdesign，PC主板，低端存儲

5，Priceperwattageonperformancebasisisn'tgettingbetter.Havehugepowerandcoolingissues

6，運用一些collocation和Google自己的數(shù)據(jù)中心

其他

1，快速更改而不是等待QA

2，庫是構(gòu)建程序的卓越方式

3，一些程序作為效勞供應(yīng)

4，一個根底組織處理程序的版本，這樣它們可以發(fā)布而不用膽怯 會破壞什么東西

Google將來的方向

1，支持地理位置分布的集群

2，為全部數(shù)據(jù)創(chuàng)立一個單獨的全局名字空間。當(dāng)前的數(shù)據(jù)由集群別離

3，更多和更好的自動化數(shù)據(jù)遷移和計算

4，解決當(dāng)運用網(wǎng)絡(luò)劃分來做廣袤區(qū)域的備份時的一樣性問題(例如保持效勞即使一個集群離線維護(hù)或由于一些損耗問題)

學(xué)到的東西

1，根底組織是有競爭性的優(yōu)勢。特殊是對Google而言。Google可以很快很廉價的推出新效勞，并且伸縮性其他人很難到達(dá)。很多公司實行完全不同的方式。很多公司認(rèn)為根底組織開銷太大。Google認(rèn)為自己是一個系統(tǒng)工程公司，這是一個新的對待軟件構(gòu)建的方式

2，跨越多個數(shù)據(jù)中心仍舊是一個未解決的問題。大局部網(wǎng)站都是一個或者最多兩個數(shù)據(jù)中心。我們不得不成認(rèn)怎樣在一些數(shù)據(jù)中心之間完整的分布網(wǎng)站是很須要技巧的

3，假如你自己沒有時間從零開場重新構(gòu)建全部這些根底組織你可以看看Hadoop。Hadoop是這里很多同樣的辦法的一個開源實現(xiàn)

4，平臺的一個優(yōu)點是初級開發(fā)人員可以在平臺的根底上快速并且放心的創(chuàng)立健全的程序。假如每個工程都須要創(chuàng)建同樣的分布式根底組織的輪子，那么你將陷入逆境因為知道怎樣完成這項工作的人相對較少

5，協(xié)同工作不始終是擲