來(lái)至 書(shū)客網(wǎng)www.8211.cn

?

一、 web2.0網(wǎng)站常用可用性功能模塊分析

二、 Flickr的幕后故事

三、 YouTube 的架構(gòu)擴(kuò)展

四、 mixi.jp：使用開(kāi)源軟件搭建的可擴(kuò)展SNS網(wǎng)站

五、 Technorati的后臺(tái)數(shù)據(jù)庫(kù)架構(gòu)

六、 通過(guò)了解MySpace的六次重構(gòu)經(jīng)歷,來(lái)認(rèn)識(shí)分布式系統(tǒng)到底該如何創(chuàng)建

七、 從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法

八、 說(shuō)說(shuō)大型高并發(fā)高負(fù)載網(wǎng)站的系統(tǒng)架構(gòu)

一、 web2.0 網(wǎng)站常用可用性功能模塊分析

Web 2.0網(wǎng)站是指將傳統(tǒng)的網(wǎng)站構(gòu)架（平臺(tái)、內(nèi)容源、用戶(hù)、傳播方式等）轉(zhuǎn)化到以用戶(hù)為核心的網(wǎng)站構(gòu)架上來(lái)，包括一系列體現(xiàn)web2.0概念的元素、定位和創(chuàng)意。web2.0網(wǎng)站在構(gòu)架上須體現(xiàn)兩大宗旨，即強(qiáng)大的后臺(tái)系統(tǒng)和簡(jiǎn)單的前臺(tái)頁(yè)面，也即提供良好的用戶(hù)體驗(yàn)，體現(xiàn)以人為本，技術(shù)服務(wù)人類(lèi)的宗旨。

web2.0網(wǎng)站常用功能塊通常包括以下幾大項(xiàng)：

1. Tag 標(biāo)簽功能塊

Tag(中文叫做"標(biāo)簽") 是一種新的組織和管理在線(xiàn)信息的方式。它不同于傳統(tǒng)的、針對(duì)文件本身的關(guān)鍵字檢索，而是一種模糊化、智能化的分類(lèi)。

　　網(wǎng)頁(yè)使用Tag標(biāo)簽的好處：

為頁(yè)面設(shè)置一個(gè)或者多個(gè)Tag標(biāo)簽可以引導(dǎo)讀者相關(guān)文章，為別人帶去流量同理也為自己帶來(lái)流量。

可以幫助讀者及時(shí)了解一些未知的概念和知識(shí)點(diǎn)，提高用戶(hù)體驗(yàn)。

Tag是人的意志和趨向的體現(xiàn)，Tag可以幫助你找到興趣相投的人。

　　基于以上優(yōu)勢(shì)，Tag標(biāo)簽代替了傳統(tǒng)的分類(lèi)法，成為web2.0網(wǎng)站使用率最高的功能塊（與其說(shuō)是功能塊倒不如說(shuō)是一種內(nèi)容導(dǎo)航和內(nèi)容組織形式）。

　　一句話(huà)：Tag標(biāo)簽是一種更靈活的分類(lèi)方法，功能在于引導(dǎo)，特點(diǎn)是無(wú)處不在，體現(xiàn)智能性、模糊性和趨向性。

2. RSS 訂閱功能塊

RSS是在線(xiàn)共享內(nèi)容的一種簡(jiǎn)易方式（也叫聚合內(nèi)容，Really Simple Syndication）。通常在時(shí)效性比較強(qiáng)的內(nèi)容上使用RSS訂閱能更快速獲取信息，網(wǎng)站提供RSS輸出，有利于讓用戶(hù)獲取網(wǎng)站內(nèi)容的最新更新。網(wǎng)絡(luò)用戶(hù)可以在客戶(hù)端借助于支持RSS的聚合工具軟件（例如SharpReader,NewzCrawler、FeedDemon），在不打開(kāi)網(wǎng)站內(nèi)容頁(yè)面的情況下閱讀支持RSS輸出的網(wǎng)站內(nèi)容。

RSS訂閱的方式：

訂閱到客戶(hù)端軟件如周伯通、遨游瀏覽器RSS閱讀、Foxmail RSS閱讀等，此方式使用者較多

訂閱到在線(xiàn)閱讀（聚合類(lèi)）門(mén)戶(hù)網(wǎng)站如Google Reader，Yahoo Reader，抓蝦、Gougou等，省去了安裝RSS閱讀器的麻煩

訂閱到在線(xiàn)單用戶(hù)聚合器如Lilina等，比較靈活

RSS訂閱功能的最大好處是定向投遞，也就是說(shuō)RSS機(jī)制更能體現(xiàn)用戶(hù)的意愿和個(gè)性，獲取信息的方式也最直接和簡(jiǎn)單，這是RSS訂閱功能備受青睞的一大主要原因。

3. 推薦和收藏功能塊

　　說(shuō)到推薦功能，不僅web2.0網(wǎng)站在大量使用，傳統(tǒng)的以cms平臺(tái)為代表的內(nèi)容模式的網(wǎng)站也在大量使用，推薦功能主要是指向一些網(wǎng)摘或者聚合類(lèi)門(mén)戶(hù)網(wǎng)站推薦自己所瀏覽到的網(wǎng)頁(yè)。當(dāng)然，一種變相的推薦就是閱讀者的自我收藏行為，在共享的模式下也能起到推薦的作用。

　　比較有名的推薦目標(biāo)有以del.icio.us為代表的網(wǎng)摘類(lèi)網(wǎng)站包括國(guó)內(nèi)比較有名氣的365key、和訊網(wǎng)摘、新浪vivi、天極網(wǎng)摘等。這里值得一提的是前段時(shí)間曾涌現(xiàn)了大批網(wǎng)摘類(lèi)網(wǎng)站，但他們堅(jiān)持活下來(lái)的好像沒(méi)有幾個(gè)了，推薦使用前面提到的這幾個(gè)網(wǎng)摘門(mén)戶(hù)，人氣基本上是使最旺的。

4. 評(píng)論和留言功能塊

web2.0強(qiáng)調(diào)參與性，強(qiáng)調(diào)發(fā)揮用戶(hù)的主導(dǎo)作用，這里的參與性除了所謂的訂閱、推薦功能外更多地體現(xiàn)在用戶(hù)對(duì)內(nèi)容的評(píng)價(jià)和態(tài)度，這就要靠評(píng)論功能塊來(lái)完成。一個(gè)典型的web2.0網(wǎng)站或者說(shuō)一個(gè)能體現(xiàn)人氣的web2.0網(wǎng)站都會(huì)花大量篇幅來(lái)體現(xiàn)用戶(hù)的觀點(diǎn)和視覺(jué)。這里尤其要提到web2.0中的帶頭老大web blog，評(píng)論功能已經(jīng)成為博客主人與瀏覽者交流的主要陣地，是體現(xiàn)網(wǎng)站人氣的最直觀因素。

　　評(píng)論功能塊應(yīng)用在博客系統(tǒng)中實(shí)際上已經(jīng)和博客內(nèi)容相分離，而更好的應(yīng)用恰恰是一些以點(diǎn)評(píng)為主的web2.0網(wǎng)站比如豆瓣、點(diǎn)評(píng)網(wǎng)等，這里的評(píng)論功能塊直接制造了內(nèi)容也極大地體現(xiàn)了網(wǎng)站的人氣，所以說(shuō)評(píng)論功能塊是web2.0網(wǎng)站最有力的武器。

5. 站內(nèi)搜索功能塊

　　搜索是信息來(lái)源最直接的方式之一，無(wú)論你的網(wǎng)站是否打上web2.0的烙印，搜索對(duì)于一個(gè)體系龐大、內(nèi)容豐富的大型網(wǎng)站都是非常必要的。Tag標(biāo)簽在某種程度上起到搜索的作用，它能夠有效聚合以此Tag為關(guān)鍵詞的內(nèi)容，但這種情況的前提是此Tag標(biāo)簽對(duì)瀏覽者是可見(jiàn)的，也就是說(shuō)當(dāng)Tag標(biāo)簽擺在瀏覽者的眼前時(shí)才成立，而對(duì)于那些瀏覽者想要的信息卻沒(méi)有Tag標(biāo)簽來(lái)引導(dǎo)時(shí)搜索就是達(dá)到此目的的最好方法。

　　對(duì)于web2.0網(wǎng)站，站內(nèi)搜索以標(biāo)題或者Tag為搜索域都能起到好的效果，但本人不建議使用內(nèi)容搜索域，因?yàn)檫@不符合搜索的高效性原則。同時(shí)，具有突出關(guān)鍵詞的內(nèi)容往往都可以用Tag標(biāo)簽來(lái)引導(dǎo)，因此使用內(nèi)容域來(lái)搜索實(shí)際上是一種浪費(fèi)服務(wù)器資源的行為，而且搜索結(jié)果的準(zhǔn)確性將大打折扣。

6. 群組功能塊

　　我為什么要把群組作為web2.0網(wǎng)站的功能塊來(lái)分析呢，因?yàn)槿航M是web2.0網(wǎng)站的一大特點(diǎn)，也是web2.0所要體現(xiàn)的服務(wù)宗旨所在。一個(gè)web2.0網(wǎng)站，博客也好、播客也好、點(diǎn)評(píng)也好，抑或是網(wǎng)摘、聚合門(mén)戶(hù)，他們都強(qiáng)調(diào)人的參與性。物以類(lèi)聚、人以群分，每個(gè)參與者都有自己的興趣趨向，web2.0網(wǎng)站的另一主要功能就是幫助這些人找到同樣興趣的人并形成一個(gè)活躍的群體，這是web2.0網(wǎng)站的根本。

總結(jié)：web2.0網(wǎng)站倡導(dǎo)的是集體創(chuàng)作、共享資源，靠的是人氣，體現(xiàn)的是參與性，一個(gè)沒(méi)有參與性的web2.0網(wǎng)站都不足以成為web2.0。以上提到的這幾個(gè)功能塊就是以吸引用戶(hù)參與和引導(dǎo)用戶(hù)參與為目的的，真正的web2.0不是什么深?yuàn)W的東西，只有一點(diǎn)，那就是如何讓瀏覽者沸騰起來(lái)。

二、 Flickr 的幕后故事

我們都看到 Flickr 的成功，而又有多少"精英"們了解過(guò) Flickr 背后的過(guò)程是多么充滿(mǎn)艱險(xiǎn)。

Flickr 是全 CGI 的動(dòng)態(tài)構(gòu)架，并以一種 .gne 的腳本作為 CGI 程序語(yǔ)言。不管網(wǎng)站制作菜鳥(niǎo)還是高手都會(huì)疑惑：gne 是哪種程序語(yǔ)言？答案：gne 不是一種語(yǔ)言，Flickr 是以極為經(jīng)典的 PHP + MySQL 方式實(shí)現(xiàn)的，在被 Yahoo 收購(gòu)服務(wù)器搬入美國(guó)之前，使用了 21 臺(tái)（69.90.111.101-121） Apache/PHP 做 Web、23 臺(tái)圖片服務(wù)器、另有 MySQL 服務(wù)器組成的數(shù)據(jù)庫(kù)集群的服務(wù)器數(shù)量未知。現(xiàn)在估計(jì)使用的是 Yahoo 的負(fù)載均衡系統(tǒng)，對(duì)外只有一個(gè) Web 的 IP 和圖片服務(wù)器的 IP 了。

　　那為何 .php 的文件要改成 .gne 呢？以往有大型網(wǎng)站為向后兼容性考慮，隱藏以程序語(yǔ)言命名的腳本文件擴(kuò)展名，比如 Baidu 隱藏了 .php（Google 的 http 服務(wù)器是自己寫(xiě)的，整合了腳本程序，個(gè)別頁(yè)面是 .py--Python）；還有一些網(wǎng)站是改成自己網(wǎng)站名相關(guān)的擴(kuò)展名，如 MSN 的群組則是 .msnw，榕樹(shù)下是 .rs。

　　那 Flickr 的 gne 是什么意思？我在維基百科的 Flickr 條目上找到了答案(中文 Flickr 條目上沒(méi)有寫(xiě)明) 。原來(lái) GNE 是 Game NeverEnding 的縮寫(xiě)，Flickr 的開(kāi)發(fā)者 Ludicorp 在 2002-2004 年一直在開(kāi)發(fā)這套以 Game NerverEnding 為名稱(chēng)的大型多人在線(xiàn)角色扮演游戲--一套基于瀏覽器的 Web 游戲系統(tǒng)，個(gè)人以為應(yīng)該就是當(dāng)年九城的虛擬城市。但是開(kāi)發(fā)近 3 年后該計(jì)劃不得不破產(chǎn)，最終只發(fā)布了一個(gè) Beta 版，而 Ludicorp 將這套系統(tǒng)稍加移植，就有了 Flickr。呵呵，原來(lái) gne 是一個(gè)項(xiàng)目的名稱(chēng)。關(guān)于 GNE 的一些連接：http://del.icio.us/schee/gne。

　　早期的 Flickr 想做成在類(lèi)似聊天室的地方讓網(wǎng)友分享、交流自己的照片，注重社區(qū)形式和保護(hù)照片不被外部引用（見(jiàn)徐子涵2004年的文章），可能是看到了 Hello 的模式吧。但是聰明的 Flickr 團(tuán)隊(duì)不久就改變了策略，淡化了傳統(tǒng)的社區(qū)形式--如聊天室、而加強(qiáng)了現(xiàn)在使其功成名就的 Tag 組織形式，一種更自由更隨興更輕松好玩的大社區(qū)形式，或者叫它廣義社區(qū)吧，我隨便叫的，可能太學(xué)究，看著別太在意就是了。另外，將原來(lái)照片只能在 Flash 內(nèi)瀏覽的限制區(qū)除了，并大力推薦用戶(hù)將照片引用到自己的 Blog，這無(wú)疑對(duì)于挑戰(zhàn)傳統(tǒng)相冊(cè)系統(tǒng)有決定性意義。減少 Flash 后的網(wǎng)頁(yè)更多地引進(jìn)了新興的 Ajax 技術(shù)，使界面操作變得非常 Cool。

　　這就是 Flickr 的歷史，清晰地看到了他們對(duì)于優(yōu)秀產(chǎn)品的執(zhí)著。有了技術(shù)和經(jīng)驗(yàn)積累，加上不斷堅(jiān)持，總有一天時(shí)來(lái)運(yùn)轉(zhuǎn)，你的產(chǎn)品會(huì)成為新潮流的里程碑。

　　還有一句話(huà)要告訴 Yupoo 等：把 Flickr 想成一個(gè)有 Tag 功能的在線(xiàn)相冊(cè)就已經(jīng)錯(cuò)遠(yuǎn)了；復(fù)制粘貼者們想當(dāng)然將 Flickr 去其糟粕取其精華，結(jié)果無(wú)關(guān)緊要的拿來(lái)了，將令人激動(dòng)的優(yōu)點(diǎn)都去掉了，結(jié)果剩下什么？

三、 YouTube 的架構(gòu)擴(kuò)展

在西雅圖擴(kuò)展性的技術(shù)研討會(huì)上，YouTube 的 Cuong Do 做了關(guān)于 YouTube Scalability 的報(bào)告。視頻內(nèi)容在 Google Video 上有(地址)，可惜國(guó)內(nèi)用戶(hù)看不到。

Kyle Cordes 對(duì)這個(gè)視頻中的內(nèi)容做了介紹。里面有不少技術(shù)性的內(nèi)容。值得分享一下。(Kyle Cordes 的介紹是本文的主要來(lái)源)

簡(jiǎn)單的說(shuō) YouTube 的數(shù)據(jù)流量, "一天的YouTube流量相當(dāng)于發(fā)送750億封電子郵件.", 2006 年中就有消息說(shuō)每日 PV 超過(guò) 1 億,現(xiàn)在? 更夸張了,"每天有10億次下載以及6,5000次上傳", 真假姑且不論, 的確是超乎尋常的海量. 國(guó)內(nèi)的互聯(lián)網(wǎng)應(yīng)用,但從數(shù)據(jù)量來(lái)看,怕是只有 51.com 有這個(gè)規(guī)模. 但技術(shù)上和 YouTube 就沒(méi)法子比了.

1. Web 服務(wù)器

YouTube 出于開(kāi)發(fā)速度的考慮，大部分代碼都是 Python 開(kāi)發(fā)的。Web 服務(wù)器有部分是 Apache， 用 FastCGI 模式。對(duì)于視頻內(nèi)容則用 Lighttpd 。據(jù)我所知，MySpace 也有部分服務(wù)器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(國(guó)內(nèi)用 Lighttpd 站點(diǎn)不多，豆瓣用的比較舒服。by Fenng)

2. 視頻

視頻的縮略圖(Thumbnails)給服務(wù)器帶來(lái)了很大的挑戰(zhàn)。每個(gè)視頻平均有4個(gè)縮略圖，而每個(gè) Web 頁(yè)面上更是有多個(gè)，每秒鐘因?yàn)檫@個(gè)帶來(lái)的磁盤(pán) IO 請(qǐng)求太大。YouTube 技術(shù)人員啟用了單獨(dú)的服務(wù)器群組來(lái)承擔(dān)這個(gè)壓力，并且針對(duì) Cache 和 OS 做了部分優(yōu)化。另一方面，縮略圖請(qǐng)求的壓力導(dǎo)致 Lighttpd 性能下降。通過(guò) Hack Lighttpd 增加更多的 worker 線(xiàn)程很大程度解決了問(wèn)題。而最新的解決方案是起用了 Google 的 BigTable， 這下子從性能、容錯(cuò)、緩存上都有更好表現(xiàn)。看人家這收購(gòu)的，好鋼用在了刀刃上。

出于冗余的考慮，每個(gè)視頻文件放在一組迷你 Cluster 上，所謂 "迷你 Cluster" 就是一組具有相同內(nèi)容的服務(wù)器。最火的視頻放在 CDN 上，這樣自己的服務(wù)器只需要承擔(dān)一些"漏網(wǎng)"的隨即訪(fǎng)問(wèn)即可。YouTube 使用簡(jiǎn)單、廉價(jià)、通用的硬件，這一點(diǎn)和 Google 風(fēng)格倒是一致。至于維護(hù)手段，也都是常見(jiàn)的工具，如 rsync, SSH 等，只不過(guò)人家更手熟罷了。

3. 數(shù)據(jù)庫(kù)

YouTube 用 MySQL 存儲(chǔ)元數(shù)據(jù)--用戶(hù)信息、視頻信息什么的。數(shù)據(jù)庫(kù)服務(wù)器曾經(jīng)一度遇到 SWAP 顛簸的問(wèn)題，解決辦法是刪掉了 SWAP 分區(qū)! 管用。

最初的 DB 只有 10 塊硬盤(pán)，RAID 10 ，后來(lái)追加了一組 RAID 1。夠省的。這一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,參見(jiàn)這里). 在擴(kuò)展性方面，路線(xiàn)也是和其他站點(diǎn)類(lèi)似，復(fù)制，分散 IO。最終的解決之道是"分區(qū)",這個(gè)不是數(shù)據(jù)庫(kù)層面的表分區(qū)，而是業(yè)務(wù)層面的分區(qū)(在用戶(hù)名字或者 ID 上做文章,應(yīng)用程序控制查找機(jī)制)

YouTube 也用 Memcached.

很想了解一下國(guó)內(nèi) Web 2.0 網(wǎng)站的數(shù)據(jù)信息,有誰(shuí)可以提供一點(diǎn) ?

四、 mixi.jp ：使用開(kāi)源軟件搭建的可擴(kuò)展SNS網(wǎng)站

Mixi目前是日本排名第三的網(wǎng)站，全球排名42，主要提供SNS服務(wù)：日記，群組，站內(nèi)消息，評(píng)論，相冊(cè)等等，是日本最大的SNS網(wǎng)站。Mixi從2003年12月份開(kāi)始開(kāi)發(fā)，由現(xiàn)在它的CTO - Batara Kesuma一個(gè)人焊，焊了四個(gè)月，在2004年2月份開(kāi)始上線(xiàn)運(yùn)行。兩個(gè)月后就注冊(cè)了1w用戶(hù)，日訪(fǎng)問(wèn)量60wPV。在隨后的一年里，用戶(hù)增長(zhǎng)到了21w，第二年，增長(zhǎng)到了200w。到今年四月份已經(jīng)增長(zhǎng)到370w注冊(cè)用戶(hù)，并且還在以每天1.5w人的注冊(cè)量增長(zhǎng)。這些用戶(hù)中70%是活躍用戶(hù)（活躍用戶(hù)：三天內(nèi)至少登錄一次的用戶(hù)），平均每個(gè)用戶(hù)每周在線(xiàn)時(shí)間為將近3個(gè)半小時(shí)。

下面我們來(lái)看它的技術(shù)架構(gòu)。Mixi采用開(kāi)源軟件作為架構(gòu)的基礎(chǔ)：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前為止已經(jīng)有100多臺(tái)MySQL數(shù)據(jù)庫(kù)服務(wù)器，并且在以每月10多臺(tái)的速度增長(zhǎng)。Mixi的數(shù)據(jù)庫(kù)連接方式采用的是每次查詢(xún)都進(jìn)行連接，而不是持久連接。數(shù)據(jù)庫(kù)大多數(shù)是以InnoDB方式運(yùn)行。Mixi解決擴(kuò)展問(wèn)題主要依賴(lài)于對(duì)數(shù)據(jù)庫(kù)的切分。

首先進(jìn)行垂直切分，按照表的內(nèi)容將不同的表劃分到不同的數(shù)據(jù)庫(kù)中。然后是水平切分，根據(jù)用戶(hù)的ID將不同用戶(hù)的內(nèi)容再劃分的不同的數(shù)據(jù)庫(kù)中，這是比較通常的做法，也很管用。劃分的關(guān)鍵還是在于應(yīng)用中的實(shí)現(xiàn)，需要將操作封裝在在數(shù)據(jù)層，而盡量不影響業(yè)務(wù)層。當(dāng)然完全不改變邏輯層也不可能，這時(shí)候最能檢驗(yàn)以前的設(shè)計(jì)是否到位，如果以前設(shè)計(jì)的不錯(cuò)，那創(chuàng)建連接的時(shí)候傳個(gè)表名，用戶(hù)ID進(jìn)去差不多就解決問(wèn)題了，而以前如果sql代碼到處飛，或者數(shù)據(jù)層封裝的不太好的話(huà)那就累了。

這樣做了以后并不能從根本上解決問(wèn)題，尤其是對(duì)于像mixi這種SNS網(wǎng)站，頁(yè)面上往往需要引用大量的用戶(hù)信息，好友信息，圖片，文章信息，跨表，跨庫(kù)操作相當(dāng)多。這個(gè)時(shí)候就需要發(fā)揮memcached的作用了，用大內(nèi)存把這些不變的數(shù)據(jù)全都緩存起來(lái)，而當(dāng)修改時(shí)就通知cache過(guò)期，這樣應(yīng)用層基本上就可以解決大部分問(wèn)題了，只會(huì)有很小一部分請(qǐng)求穿透應(yīng)用層，用到數(shù)據(jù)庫(kù)。Mixi的經(jīng)驗(yàn)是平均每個(gè)頁(yè)面的加載時(shí)間在0.02秒左右（當(dāng)然根據(jù)頁(yè)面大小情況不盡相似），可以說(shuō)明這種做法是行之有效的。Mixi一共在32臺(tái)機(jī)器上有緩存服務(wù)器，每個(gè)Cache Server 2G內(nèi)存，這些Cache Server與App Server裝在一起。因?yàn)镃ache Server對(duì)CPU消耗不大，而有了Cache Server的支援，App Server對(duì)內(nèi)存要求也不是太高，所以可以和平共處，更有效的利用資源。

圖片的處理就顯得相對(duì)簡(jiǎn)單的多了。對(duì)于mixi而言，圖像主要有兩部分：一部分是經(jīng)常要使用到的，像用戶(hù)頭像，群組的頭像等等，大概有100多GB，它們被Squid和CDN所緩存，命中率相對(duì)比較高；另一部分是用戶(hù)上傳的大量照片，它們的個(gè)體訪(fǎng)問(wèn)量相對(duì)而言比較小，命中率也比較低，使用Cache不劃算，所以對(duì)于這些照片的策略是直接在用戶(hù)上傳的時(shí)候分發(fā)到到圖片存儲(chǔ)服務(wù)器上，在用戶(hù)訪(fǎng)問(wèn)的時(shí)候直接進(jìn)行訪(fǎng)問(wèn)，當(dāng)然圖片的位置需要在數(shù)據(jù)庫(kù)中進(jìn)行記錄，不然找不到放在哪臺(tái)服務(wù)器上就郁悶了。

五、 Technorati 的后臺(tái)數(shù)據(jù)庫(kù)架構(gòu)

Technorati (現(xiàn)在被阻尼了, 可能你訪(fǎng)問(wèn)不了)的 Dorion Carroll 在 2006 MySQL 用戶(hù)會(huì)議 上介紹了一些關(guān)于 Technorati 后臺(tái)數(shù)據(jù)庫(kù)架構(gòu)的情況.

基本情況

目前處理著大約 10Tb 核心數(shù)據(jù), 分布在大約 20 臺(tái)機(jī)器上.通過(guò)復(fù)制, 多增加了 100Tb 數(shù)據(jù), 分布在 200 臺(tái)機(jī)器上. 每天增長(zhǎng)的數(shù)據(jù) 1TB. 通過(guò) SOA 的運(yùn)用, 物理與邏輯的訪(fǎng)問(wèn)相隔離,　似乎消除了數(shù)據(jù)庫(kù)的瓶頸. 值得一提的是, 該擴(kuò)展過(guò)程始終是利用普通的硬件與開(kāi)源軟件來(lái)完成的. 畢竟 , Web 2.0 站點(diǎn)都不是燒錢(qián)的主. 從數(shù)據(jù)量來(lái)看，這絕對(duì)是一個(gè)相對(duì)比較大的 Web 2.0 應(yīng)用.

Tag 是 Technorati 最為重要的數(shù)據(jù)元素. 爆炸性的 Tag 增長(zhǎng)給 Technorati 帶來(lái)了不小的挑戰(zhàn).

2005 年 1 月的時(shí)候, 只有兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器, 一主一從. 到了 06 年一月份, 已經(jīng)是一主一從, 6 臺(tái) MyISAM 從數(shù)據(jù)庫(kù)用來(lái)對(duì)付查詢(xún), 3 臺(tái) MyISAM 用作異步計(jì)算.

一些核心的處理方法:

1) 根據(jù)實(shí)體(tags/posttags)) 進(jìn)行分區(qū)

衡量數(shù)據(jù)訪(fǎng)問(wèn)方法，讀和寫(xiě)的平衡.然后通過(guò)不同的維度進(jìn)行分區(qū)．( Technorati 數(shù)據(jù)更新不會(huì)很多, 否則會(huì)成為數(shù)據(jù)庫(kù)災(zāi)難)

2) 合理利用 InnoDB 與 MyISAM

InnoDB 用于數(shù)據(jù)完整性/寫(xiě)性能要求比較高的應(yīng)用. MyISAM 適合進(jìn)行 OLAP 運(yùn)算. 物盡其用.

3) MySQL 復(fù)制

復(fù)制數(shù)據(jù)到從主數(shù)據(jù)庫(kù)到輔數(shù)據(jù)庫(kù)上,平衡分布查詢(xún)與異步計(jì)算, 另外一個(gè)功能是提供冗余

可以看一下，書(shū)客網(wǎng)www.8211.cn

?

六、 通過(guò)了解MySpace 的六次重構(gòu)經(jīng)歷,來(lái)認(rèn)識(shí)分布式系統(tǒng)到底該如何創(chuàng)建.

在每個(gè)里程碑，站點(diǎn)負(fù)擔(dān)都會(huì)超過(guò)底層系統(tǒng)部分組件的最大載荷，特別是數(shù)據(jù)庫(kù)和存儲(chǔ)系統(tǒng)。接著，功能出現(xiàn)問(wèn)題，用戶(hù)失聲尖叫。最后，技術(shù)團(tuán)隊(duì)必須為此修訂系統(tǒng)策略。

　　雖然自2005年早期，站點(diǎn)賬戶(hù)數(shù)超過(guò)7百萬(wàn)后，系統(tǒng)架構(gòu)到目前為止保持了相對(duì)穩(wěn)定，但MySpace仍然在為SQL Server支持的同時(shí)連接數(shù)等方面繼續(xù)攻堅(jiān)，Benedetto說(shuō)，"我們已經(jīng)盡可能把事情做到最好"。

1. 里程碑一：50 萬(wàn)賬戶(hù)

　　按Benedetto 的說(shuō)法，MySpace最初的系統(tǒng)很小，只有兩臺(tái)Web服務(wù)器和一個(gè)數(shù)據(jù)庫(kù)服務(wù)器。那時(shí)使用的是Dell雙CPU、4G內(nèi)存的系統(tǒng)。

　　單個(gè)數(shù)據(jù)庫(kù)就意味著所有數(shù)據(jù)都存儲(chǔ)在一個(gè)地方，再由兩臺(tái)Web服務(wù)器分擔(dān)處理用戶(hù)請(qǐng)求的工作量。但就像MySpace后來(lái)的幾次底層系統(tǒng)修訂時(shí)的情況一樣，三服務(wù)器架構(gòu)很快不堪重負(fù)。此后一個(gè)時(shí)期內(nèi)，MySpace基本是通過(guò)添置更多Web服務(wù)器來(lái)對(duì)付用戶(hù)暴增問(wèn)題的。

　　但到在2004年早期，MySpace用戶(hù)數(shù)增長(zhǎng)到50萬(wàn)后，數(shù)據(jù)庫(kù)服務(wù)器也已開(kāi)始汗流浹背。

　　但和Web服務(wù)器不同，增加數(shù)據(jù)庫(kù)可沒(méi)那么簡(jiǎn)單。如果一個(gè)站點(diǎn)由多個(gè)數(shù)據(jù)庫(kù)支持，設(shè)計(jì)者必須考慮的是，如何在保證數(shù)據(jù)一致性的前提下，讓多個(gè)數(shù)據(jù)庫(kù)分擔(dān)壓力。

　　在第二代架構(gòu)中，MySpace運(yùn)行在3個(gè)SQL Server數(shù)據(jù)庫(kù)服務(wù)器上--一個(gè)為主，所有的新數(shù)據(jù)都向它提交，然后由它復(fù)制到其他兩個(gè)；另兩個(gè)全力向用戶(hù)供給數(shù)據(jù)，用以在博客和個(gè)人資料欄顯示。這種方式在一段時(shí)間內(nèi)效果很好--只要增加數(shù)據(jù)庫(kù)服務(wù)器，加大硬盤(pán)，就可以應(yīng)對(duì)用戶(hù)數(shù)和訪(fǎng)問(wèn)量的增加。

2. 里程碑二：1-2 百萬(wàn)賬戶(hù)

MySpace注冊(cè)數(shù)到達(dá)1百萬(wàn)至2百萬(wàn)區(qū)間后，數(shù)據(jù)庫(kù)服務(wù)器開(kāi)始受制于I/O容量--即它們存取數(shù)據(jù)的速度。而當(dāng)時(shí)才是2004年中，距離上次數(shù)據(jù)庫(kù)系統(tǒng)調(diào)整不過(guò)數(shù)月。用戶(hù)的提交請(qǐng)求被阻塞，就像千人樂(lè)迷要擠進(jìn)只能容納幾百人的夜總會(huì)，站點(diǎn)開(kāi)始遭遇"主要矛盾"，Benedetto說(shuō)，這意味著MySpace永遠(yuǎn)都會(huì)輕度落后于用戶(hù)需求。

"有人花5分鐘都無(wú)法完成留言，因此用戶(hù)總是抱怨說(shuō)網(wǎng)站已經(jīng)完蛋了。"他補(bǔ)充道。

　　這一次的數(shù)據(jù)庫(kù)架構(gòu)按照垂直分割模式設(shè)計(jì)，不同的數(shù)據(jù)庫(kù)服務(wù)于站點(diǎn)的不同功能，如登錄、用戶(hù)資料和博客。于是，站點(diǎn)的擴(kuò)展性問(wèn)題看似又可以告一段落了，可以歇一陣子。

　　垂直分割策略利于多個(gè)數(shù)據(jù)庫(kù)分擔(dān)訪(fǎng)問(wèn)壓力，當(dāng)用戶(hù)要求增加新功能時(shí)，MySpace將投入新的數(shù)據(jù)庫(kù)予以支持它。賬戶(hù)到達(dá)2百萬(wàn)后，MySpace還從存儲(chǔ)設(shè)備與數(shù)據(jù)庫(kù)服務(wù)器直接交互的方式切換到SAN（Storage Area Network，存儲(chǔ)區(qū)域網(wǎng)絡(luò)）--用高帶寬、專(zhuān)門(mén)設(shè)計(jì)的網(wǎng)絡(luò)將大量磁盤(pán)存儲(chǔ)設(shè)備連接在一起，而數(shù)據(jù)庫(kù)連接到SAN。這項(xiàng)措施極大提升了系統(tǒng)性能、正常運(yùn)行時(shí)間和可靠性，Benedetto說(shuō)。

3. 里程碑三：3 百萬(wàn)賬戶(hù)

　　當(dāng)用戶(hù)繼續(xù)增加到3百萬(wàn)后，垂直分割策略也開(kāi)始難以為繼。盡管站點(diǎn)的各個(gè)應(yīng)用被設(shè)計(jì)得高度獨(dú)立，但有些信息必須共享。在這個(gè)架構(gòu)里，每個(gè)數(shù)據(jù)庫(kù)必須有各自的用戶(hù)表副本--MySpace授權(quán)用戶(hù)的電子花名冊(cè)。這就意味著一個(gè)用戶(hù)注冊(cè)時(shí)，該條賬戶(hù)記錄必須在9個(gè)不同數(shù)據(jù)庫(kù)上分別創(chuàng)建。但在個(gè)別情況下，如果其中某臺(tái)數(shù)據(jù)庫(kù)服務(wù)器臨時(shí)不可到達(dá)，對(duì)應(yīng)事務(wù)就會(huì)失敗，從而造成賬戶(hù)非完全創(chuàng)建，最終導(dǎo)致此用戶(hù)的該項(xiàng)服務(wù)無(wú)效。

　　另外一個(gè)問(wèn)題是，個(gè)別應(yīng)用如博客增長(zhǎng)太快，那么專(zhuān)門(mén)為它服務(wù)的數(shù)據(jù)庫(kù)就有巨大壓力。

2004年中，MySpace面臨Web開(kāi)發(fā)者稱(chēng)之為"向上擴(kuò)展"對(duì)"向外擴(kuò)展"（譯者注：Scale Up和Scale Out，也稱(chēng)硬件擴(kuò)展和軟件擴(kuò)展）的抉擇--要么擴(kuò)展到更大更強(qiáng)、也更昂貴的服務(wù)器上，要么部署大量相對(duì)便宜的服務(wù)器來(lái)分擔(dān)數(shù)據(jù)庫(kù)壓力。一般來(lái)說(shuō)，大型站點(diǎn)傾向于向外擴(kuò)展，因?yàn)檫@將讓它們得以保留通過(guò)增加服務(wù)器以提升系統(tǒng)能力的后路。

　　但成功地向外擴(kuò)展架構(gòu)必須解決復(fù)雜的分布式計(jì)算問(wèn)題，大型站點(diǎn)如Google、Yahoo和Amazon.com，都必須自行研發(fā)大量相關(guān)技術(shù)。以Google為例，它構(gòu)建了自己的分布式文件系統(tǒng)。

　　另外，向外擴(kuò)展策略還需要大量重寫(xiě)原來(lái)軟件，以保證系統(tǒng)能在分布式服務(wù)器上運(yùn)行。"搞不好，開(kāi)發(fā)人員的所有工作都將白費(fèi)"，Benedetto說(shuō)。

　　因此，MySpace首先將重點(diǎn)放在了向上擴(kuò)展上，花費(fèi)了大約1個(gè)半月時(shí)間研究升級(jí)到32CPU服務(wù)器以管理更大數(shù)據(jù)庫(kù)的問(wèn)題。Benedetto說(shuō)，"那時(shí)候，這個(gè)方案看似可能解決一切問(wèn)題。"如穩(wěn)定性，更棒的是對(duì)現(xiàn)有軟件幾乎沒(méi)有改動(dòng)要求。

　　糟糕的是，高端服務(wù)器極其昂貴，是購(gòu)置同樣處理能力和內(nèi)存速度的多臺(tái)服務(wù)器總和的很多倍。而且，站點(diǎn)架構(gòu)師預(yù)測(cè)，從長(zhǎng)期來(lái)看，即便是巨型數(shù)據(jù)庫(kù)，最后也會(huì)不堪重負(fù)，Benedetto說(shuō)，"換句話(huà)講，只要增長(zhǎng)趨勢(shì)存在，我們最后無(wú)論如何都要走上向外擴(kuò)展的道路。"

　　因此，MySpace最終將目光移到分布式計(jì)算架構(gòu)--它在物理上分布的眾多服務(wù)器，整體必須邏輯上等同于單臺(tái)機(jī)器。拿數(shù)據(jù)庫(kù)來(lái)說(shuō)，就不能再像過(guò)去那樣將應(yīng)用拆分，再以不同數(shù)據(jù)庫(kù)分別支持，而必須將整個(gè)站點(diǎn)看作一個(gè)應(yīng)用。現(xiàn)在，數(shù)據(jù)庫(kù)模型里只有一個(gè)用戶(hù)表，支持博客、個(gè)人資料和其他核心功能的數(shù)據(jù)都存儲(chǔ)在相同數(shù)據(jù)庫(kù)。

　　既然所有的核心數(shù)據(jù)邏輯上都組織到一個(gè)數(shù)據(jù)庫(kù)，那么MySpace必須找到新的辦法以分擔(dān)負(fù)荷--顯然，運(yùn)行在普通硬件上的單個(gè)數(shù)據(jù)庫(kù)服務(wù)器是無(wú)能為力的。這次，不再按站點(diǎn)功能和應(yīng)用分割數(shù)據(jù)庫(kù)，MySpace開(kāi)始將它的用戶(hù)按每百萬(wàn)一組分割，然后將各組的全部數(shù)據(jù)分別存入獨(dú)立的SQL Server實(shí)例。目前，MySpace的每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器實(shí)際運(yùn)行兩個(gè)SQL Server實(shí)例，也就是說(shuō)每臺(tái)服務(wù)器服務(wù)大約2百萬(wàn)用戶(hù)。Benedetto指出，以后還可以按照這種模式以更小粒度劃分架構(gòu)，從而優(yōu)化負(fù)荷分擔(dān)。

　　當(dāng)然，還是有一個(gè)特殊數(shù)據(jù)庫(kù)保存了所有賬戶(hù)的名稱(chēng)和密碼。用戶(hù)登錄后，保存了他們其他數(shù)據(jù)的數(shù)據(jù)庫(kù)再接管服務(wù)。特殊數(shù)據(jù)庫(kù)的用戶(hù)表雖然龐大，但它只負(fù)責(zé)用戶(hù)登錄，功能單一，所以負(fù)荷還是比較容易控制的。

4. 里程碑四：9 百萬(wàn)到1 千7 百萬(wàn)賬戶(hù)

2005年早期，賬戶(hù)達(dá)到9百萬(wàn)后，MySpace開(kāi)始用Microsoft的C#編寫(xiě)ASP.NET程序。C#是C語(yǔ)言的最新派生語(yǔ)言，吸收了C++和Java的優(yōu)點(diǎn)，依托于Microsoft .NET框架（Microsoft為軟件組件化和分布式計(jì)算而設(shè)計(jì)的模型架構(gòu)）。ASP.NET則由編寫(xiě)Web站點(diǎn)腳本的ASP技術(shù)演化而來(lái)，是Microsoft目前主推的Web站點(diǎn)編程環(huán)境。

　　可以說(shuō)是立竿見(jiàn)影， MySpace馬上就發(fā)現(xiàn)ASP.NET程序運(yùn)行更有效率，與ColdFusion相比，完成同樣任務(wù)需消耗的處理器能力更小。據(jù)技術(shù)總監(jiān)Whitcomb說(shuō)，新代碼需要150臺(tái)服務(wù)器完成的工作，如果用ColdFusion則需要246臺(tái)。Benedetto還指出，性能上升的另一個(gè)原因可能是在變換軟件平臺(tái)，并用新語(yǔ)言重寫(xiě)代碼的過(guò)程中，程序員復(fù)審并優(yōu)化了一些功能流程。

　　最終，MySpace開(kāi)始大規(guī)模遷移到ASP.NET。即便剩余的少部分ColdFusion代碼，也從Cold-Fusion服務(wù)器搬到了ASP.NET，因?yàn)樗麄兊玫搅薆lueDragon.NET（喬治亞州阿爾法利塔New Atlanta Communications公司的產(chǎn)品，它能將ColdFusion代碼自動(dòng)重新編譯到Microsoft平臺(tái)）的幫助。

　　賬戶(hù)達(dá)到1千萬(wàn)時(shí)，MySpace再次遭遇存儲(chǔ)瓶頸問(wèn)題。SAN的引入解決了早期一些性能問(wèn)題，但站點(diǎn)目前的要求已經(jīng)開(kāi)始周期性超越SAN的I/O容量--即它從磁盤(pán)存儲(chǔ)系統(tǒng)讀寫(xiě)數(shù)據(jù)的極限速度。

　　原因之一是每數(shù)據(jù)庫(kù)1百萬(wàn)賬戶(hù)的分割策略，通常情況下的確可以將壓力均分到各臺(tái)服務(wù)器，但現(xiàn)實(shí)并非一成不變。比如第七臺(tái)賬戶(hù)數(shù)據(jù)庫(kù)上線(xiàn)后，僅僅7天就被塞滿(mǎn)了，主要原因是佛羅里達(dá)一個(gè)樂(lè)隊(duì)的歌迷瘋狂注冊(cè)。

　　某個(gè)數(shù)據(jù)庫(kù)可能因?yàn)槿魏卧?#xff0c;在任何時(shí)候遭遇主要負(fù)荷，這時(shí)，SAN中綁定到該數(shù)據(jù)庫(kù)的磁盤(pán)存儲(chǔ)設(shè)備簇就可能過(guò)載。"SAN讓磁盤(pán)I/O能力大幅提升了，但將它們綁定到特定數(shù)據(jù)庫(kù)的做法是錯(cuò)誤的。"Benedetto說(shuō)。

　　最初，MySpace通過(guò)定期重新分配SAN中數(shù)據(jù)，以讓其更為均衡的方法基本解決了這個(gè)問(wèn)題，但這是一個(gè)人工過(guò)程，"大概需要兩個(gè)人全職工作。"Benedetto說(shuō)。

長(zhǎng)期解決方案是遷移到虛擬存儲(chǔ)體系上，這樣，整個(gè)SAN被當(dāng)作一個(gè)巨型存儲(chǔ)池，不再要求每個(gè)磁盤(pán)為特定應(yīng)用服務(wù)。MySpace目前采用了一種新型SAN設(shè)備--來(lái)自加利福尼亞州弗里蒙特的3PARdata。

　　在3PAR的系統(tǒng)里，仍能在邏輯上按容量劃分?jǐn)?shù)據(jù)存儲(chǔ)，但它不再被綁定到特定磁盤(pán)或磁盤(pán)簇，而是散布于大量磁盤(pán)。這就使均分?jǐn)?shù)據(jù)訪(fǎng)問(wèn)負(fù)荷成為可能。當(dāng)數(shù)據(jù)庫(kù)需要寫(xiě)入一組數(shù)據(jù)時(shí)，任何空閑磁盤(pán)都可以馬上完成這項(xiàng)工作，而不再像以前那樣阻塞在可能已經(jīng)過(guò)載的磁盤(pán)陣列處。而且，因?yàn)槎鄠€(gè)磁盤(pán)都有數(shù)據(jù)副本，讀取數(shù)據(jù)時(shí)，也不會(huì)使SAN的任何組件過(guò)載。

　　當(dāng)2005年春天賬戶(hù)數(shù)達(dá)到1千7百萬(wàn)時(shí)，MySpace又啟用了新的策略以減輕存儲(chǔ)系統(tǒng)壓力，即增加數(shù)據(jù)緩存層--位于Web服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器之間，其唯一職能是在內(nèi)存中建立被頻繁請(qǐng)求數(shù)據(jù)對(duì)象的副本，如此一來(lái)，不訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)也可以向Web應(yīng)用供給數(shù)據(jù)。換句話(huà)說(shuō)，100個(gè)用戶(hù)請(qǐng)求同一份資料，以前需要查詢(xún)數(shù)據(jù)庫(kù)100次，而現(xiàn)在只需1次，其余都可從緩存數(shù)據(jù)中獲得。當(dāng)然如果頁(yè)面變化，緩存的數(shù)據(jù)必須從內(nèi)存擦除，然后重新從數(shù)據(jù)庫(kù)獲取--但在此之前，數(shù)據(jù)庫(kù)的壓力已經(jīng)大大減輕，整個(gè)站點(diǎn)的性能得到提升。

　　緩存區(qū)還為那些不需要記入數(shù)據(jù)庫(kù)的數(shù)據(jù)提供了驛站，比如為跟蹤用戶(hù)會(huì)話(huà)而創(chuàng)建的臨時(shí)文件--Benedetto坦言他需要在這方面補(bǔ)課，"我是數(shù)據(jù)庫(kù)存儲(chǔ)狂熱分子，因此我總是想著將萬(wàn)事萬(wàn)物都存到數(shù)據(jù)庫(kù)。"但將像會(huì)話(huà)跟蹤這類(lèi)的數(shù)據(jù)也存到數(shù)據(jù)庫(kù)，站點(diǎn)將陷入泥沼。

　　增加緩存服務(wù)器是"一開(kāi)始就應(yīng)該做的事情，但我們成長(zhǎng)太快，以致于沒(méi)有時(shí)間坐下來(lái)好好研究這件事情。"Benedetto補(bǔ)充道。

5. 里程碑五：2 千6 百萬(wàn)賬戶(hù)

2005年中期，服務(wù)賬戶(hù)數(shù)達(dá)到2千6百萬(wàn)時(shí)，MySpace切換到了還處于beta測(cè)試的SQL Server 2005。轉(zhuǎn)換何太急？主流看法是2005版支持64位處理器。但Benedetto說(shuō)，"這不是主要原因，盡管這也很重要；主要還是因?yàn)槲覀儗?duì)內(nèi)存的渴求。"支持64位的數(shù)據(jù)庫(kù)可以管理更多內(nèi)存。

　　更多內(nèi)存就意味著更高的性能和更大的容量。原來(lái)運(yùn)行32位版本的SQL Server服務(wù)器，能同時(shí)使用的內(nèi)存最多只有4G。切換到64位，就好像加粗了輸水管的直徑。升級(jí)到SQL Server 2005和64位Windows Server 2003后，MySpace每臺(tái)服務(wù)器配備了32G內(nèi)存，后于2006年再次將配置標(biāo)準(zhǔn)提升到64G。

　　意外錯(cuò)誤

　　如果沒(méi)有對(duì)系統(tǒng)架構(gòu)的歷次修改與升級(jí)，MySpace根本不可能走到今天。但是，為什么系統(tǒng)還經(jīng)常吃撐著了？很多用戶(hù)抱怨的"意外錯(cuò)誤"是怎么引起的呢？

　　原因之一是MySpace對(duì)Microsoft的Web技術(shù)的應(yīng)用已經(jīng)進(jìn)入連Microsoft自己也才剛剛開(kāi)始探索的領(lǐng)域。比如11月，超出SQL Server最大同時(shí)連接數(shù)，MySpace系統(tǒng)崩潰。Benedetto說(shuō)，這類(lèi)可能引發(fā)系統(tǒng)崩潰的情況大概三天才會(huì)出現(xiàn)一次，但仍然過(guò)于頻繁了，以致惹人惱怒。一旦數(shù)據(jù)庫(kù)罷工，"無(wú)論這種情況什么時(shí)候發(fā)生，未緩存的數(shù)據(jù)都不能從SQL Server獲得，那么你就必然看到一個(gè)'意外錯(cuò)誤'提示。"他解釋說(shuō)。

　　去年夏天，MySpace的Windows 2003多次自動(dòng)停止服務(wù)。后來(lái)發(fā)現(xiàn)是操作系統(tǒng)一個(gè)內(nèi)置功能惹的禍--預(yù)防分布式拒絕服務(wù)攻擊（黑客使用很多客戶(hù)機(jī)向服務(wù)器發(fā)起大量連接請(qǐng)求，以致服務(wù)器癱瘓）。MySpace和其他很多頂級(jí)大站點(diǎn)一樣，肯定會(huì)經(jīng)常遭受攻擊，但它應(yīng)該從網(wǎng)絡(luò)級(jí)而不是依靠Windows本身的功能來(lái)解決問(wèn)題--否則，大量MySpace合法用戶(hù)連接時(shí)也會(huì)引起服務(wù)器反擊。

"我們花了大約一個(gè)月時(shí)間尋找Windows 2003服務(wù)器自動(dòng)停止的原因。"Benedetto說(shuō)。最后，通過(guò)Microsoft的幫助，他們才知道該怎么通知服務(wù)器："別開(kāi)槍，是友軍。"

　　緊接著是在去年7月某個(gè)周日晚上，MySpace總部所在地洛杉磯停電，造成整個(gè)系統(tǒng)停運(yùn)12小時(shí)。大型Web站點(diǎn)通常要在地理上分布配置多個(gè)數(shù)據(jù)中心以預(yù)防單點(diǎn)故障。本來(lái)，MySpace還有其他兩個(gè)數(shù)據(jù)中心以應(yīng)對(duì)突發(fā)事件，但Web服務(wù)器都依賴(lài)于部署在洛杉磯的SAN。沒(méi)有洛杉磯的SAN，Web服務(wù)器除了懇求你耐心等待，不能提供任何服務(wù)。

Benedetto說(shuō)，主數(shù)據(jù)中心的可靠性通過(guò)下列措施保證：可接入兩張不同電網(wǎng)，另有后備電源和一臺(tái)儲(chǔ)備有30天燃料的發(fā)電機(jī)。但在這次事故中，不僅兩張電網(wǎng)失效，而且在切換到備份電源的過(guò)程中，操作員燒掉了主動(dòng)力線(xiàn)路。

2007年中，MySpace在另兩個(gè)后備站點(diǎn)上也建設(shè)了SAN。這對(duì)分擔(dān)負(fù)荷大有幫助--正常情況下，每個(gè)SAN都能負(fù)擔(dān)三分之一的數(shù)據(jù)訪(fǎng)問(wèn)量。而在緊急情況下，任何一個(gè)站點(diǎn)都可以獨(dú)立支撐整個(gè)服務(wù)，Benedetto說(shuō)。

MySpace仍然在為提高穩(wěn)定性?shī)^斗，雖然很多用戶(hù)表示了足夠信任且能原諒偶現(xiàn)的錯(cuò)誤頁(yè)面。

"作為開(kāi)發(fā)人員，我憎惡Bug，它太氣人了。"Dan Tanner這個(gè)31歲的德克薩斯軟件工程師說(shuō)，他通過(guò)MySpace重新聯(lián)系到了高中和大學(xué)同學(xué)。"不過(guò)，MySpace對(duì)我們的用處很大，因此我們可以原諒偶發(fā)的故障和錯(cuò)誤。" Tanner說(shuō)，如果站點(diǎn)某天出現(xiàn)故障甚至崩潰，恢復(fù)以后他還是會(huì)繼續(xù)使用。

　　這就是為什么Drew在論壇里咆哮時(shí)，大部分用戶(hù)都告訴他應(yīng)該保持平靜，如果等幾分鐘，問(wèn)題就會(huì)解決的原因。Drew無(wú)法平靜，他寫(xiě)道，"我已經(jīng)兩次給MySpace發(fā)郵件，而它說(shuō)一小時(shí)前還是正常的，現(xiàn)在出了點(diǎn)問(wèn)題……完全是一堆廢話(huà)。"另一個(gè)用戶(hù)回復(fù)說(shuō)，"畢竟它是免費(fèi)的。"Benedetto坦承100%的可靠性不是他的目標(biāo)。"它不是銀行，而是一個(gè)免費(fèi)的服務(wù)。"他說(shuō)。

　　換句話(huà)說(shuō)，MySpace的偶發(fā)故障可能造成某人最后更新的個(gè)人資料丟失，但并不意味著網(wǎng)站弄丟了用戶(hù)的錢(qián)財(cái)。"關(guān)鍵是要認(rèn)識(shí)到，與保證站點(diǎn)性能相比，丟失少許數(shù)據(jù)的故障是可接受的。"Benedetto說(shuō)。所以，MySpace甘冒丟失2分鐘到2小時(shí)內(nèi)任意點(diǎn)數(shù)據(jù)的危險(xiǎn)，在SQL Server配置里延長(zhǎng)了"checkpoint"操作--它將待更新數(shù)據(jù)永久記錄到磁盤(pán)--的間隔時(shí)間，因?yàn)檫@樣做可以加快數(shù)據(jù)庫(kù)的運(yùn)行。

Benedetto說(shuō)，同樣，開(kāi)發(fā)人員還經(jīng)常在幾個(gè)小時(shí)內(nèi)就完成構(gòu)思、編碼、測(cè)試和發(fā)布全過(guò)程。這有引入Bug的風(fēng)險(xiǎn)，但這樣做可以更快實(shí)現(xiàn)新功能。而且，因?yàn)檫M(jìn)行大規(guī)模真實(shí)測(cè)試不具可行性，他們的測(cè)試通常是在僅以部分活躍用戶(hù)為對(duì)象，且用戶(hù)對(duì)軟件新功能和改進(jìn)不知就里的情況下進(jìn)行的。因?yàn)槭聦?shí)上不可能做真實(shí)的加載測(cè)試，他們做的測(cè)試通常都是針對(duì)站點(diǎn)。

"我們犯過(guò)大量錯(cuò)誤，"Benedetto說(shuō)，"但到頭來(lái)，我認(rèn)為我們做對(duì)的還是比做錯(cuò)的多。"

?

七、 從LiveJournal 后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法

LiveJournal 是99年始于校園中的項(xiàng)目，幾個(gè)人出于愛(ài)好做了這樣一個(gè)應(yīng)用，以實(shí)現(xiàn)以下功能：

博客，論壇 社會(huì)性網(wǎng)絡(luò)，找到朋友 聚合，把朋友的文章聚合在一起

LiveJournal采用了大量的開(kāi)源軟件，甚至它本身也是一個(gè)開(kāi)源軟件。

在上線(xiàn)后，LiveJournal實(shí)現(xiàn)了非常快速的增長(zhǎng)：

2004年4月份：280萬(wàn)注冊(cè)用戶(hù)。 2005年4月份：680萬(wàn)注冊(cè)用戶(hù)。 2005年8月份：790萬(wàn)注冊(cè)用戶(hù)。 達(dá)到了每秒鐘上千次的頁(yè)面請(qǐng)求及處理。 使用了大量MySQL服務(wù)器。 使用了大量通用組件。

二、LiveJournal 架構(gòu)現(xiàn)狀概況

三、從LiveJournal 發(fā)展中學(xué)習(xí)

LiveJournal從1臺(tái)服務(wù)器發(fā)展到100臺(tái)服務(wù)器，這其中經(jīng)歷了無(wú)數(shù)的傷痛，但同時(shí)也摸索出了解決這些問(wèn)題的方法，通過(guò)對(duì)LiveJournal的學(xué)習(xí)，可以讓我們避免LJ曾經(jīng)犯過(guò)的錯(cuò)誤，并且從一開(kāi)始就對(duì)系統(tǒng)進(jìn)行良好的設(shè)計(jì)，以避免后期的痛苦。

下面我們一步一步看LJ發(fā)展的腳步。 計(jì)算機(jī)電子書(shū)

1 、一臺(tái)服務(wù)器

一臺(tái)別人捐助的服務(wù)器，LJ最初就跑在上面，就像Google開(kāi)始時(shí)候用的破服務(wù)器一樣，值得我們尊敬。這個(gè)階段，LJ的人以驚人的速度熟悉的Unix的操作管理，服務(wù)器性能出現(xiàn)過(guò)問(wèn)題，不過(guò)還好，可以通過(guò)一些小修小改應(yīng)付過(guò)去。在這個(gè)階段里L(fēng)J把CGI升級(jí)到了FastCGI。

最終問(wèn)題出現(xiàn)了，網(wǎng)站越來(lái)越慢，已經(jīng)無(wú)法通過(guò)優(yōu)過(guò)化來(lái)解決的地步，需要更多的服務(wù)器，這時(shí)LJ開(kāi)始提供付費(fèi)服務(wù)，可能是想通過(guò)這些錢(qián)來(lái)購(gòu)買(mǎi)新的服務(wù)器，以解決當(dāng)時(shí)的困境。

毫無(wú)疑問(wèn)，當(dāng)時(shí)LJ存在巨大的單點(diǎn)問(wèn)題，所有的東西都在那臺(tái)服務(wù)器的鐵皮盒子里裝著。

2 、兩臺(tái)服務(wù)器

用付費(fèi)服務(wù)賺來(lái)的錢(qián)LJ買(mǎi)了兩臺(tái)服務(wù)器：一臺(tái)叫做Kenny的Dell 6U機(jī)器用于提供Web服務(wù)，一臺(tái)叫做Cartman的Dell 6U服務(wù)器用于提供數(shù)據(jù)庫(kù)服務(wù)。

LJ有了更大的磁盤(pán)，更多的計(jì)算資源。但同時(shí)網(wǎng)絡(luò)結(jié)構(gòu)還是非常簡(jiǎn)單，每臺(tái)機(jī)器兩塊網(wǎng)卡，Cartman通過(guò)內(nèi)網(wǎng)為Kenny提供MySQL數(shù)據(jù)庫(kù)服務(wù)。

暫時(shí)解決了負(fù)載的問(wèn)題，新的問(wèn)題又出現(xiàn)了：

原來(lái)的一個(gè)單點(diǎn)變成了兩個(gè)單點(diǎn)。 沒(méi)有冷備份或熱備份。 網(wǎng)站速度慢的問(wèn)題又開(kāi)始出現(xiàn)了，沒(méi)辦法，增長(zhǎng)太快了。 Web服務(wù)器上CPU達(dá)到上限，需要更多的Web服務(wù)器。

3 、四臺(tái)服務(wù)器

又買(mǎi)了兩臺(tái)，Kyle和Stan，這次都是1U的，都用于提供Web服務(wù)。目前LJ一共有3臺(tái)Web服務(wù)器和一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。這時(shí)需要在3臺(tái)Web服務(wù)器上進(jìn)行負(fù)載均橫。

LJ把Kenny用于外部的網(wǎng)關(guān)，使用mod_backhand進(jìn)行負(fù)載均橫。

然后問(wèn)題又出現(xiàn)了：

單點(diǎn)故障。數(shù)據(jù)庫(kù)和用于做網(wǎng)關(guān)的Web服務(wù)器都是單點(diǎn)，一旦任何一臺(tái)機(jī)器出現(xiàn)問(wèn)題將導(dǎo)致所有服務(wù)不可用。雖然用于做網(wǎng)關(guān)的Web服務(wù)器可以通過(guò)保持心跳同步迅速切換，但還是無(wú)法解決數(shù)據(jù)庫(kù)的單點(diǎn)，LJ當(dāng)時(shí)也沒(méi)做這個(gè)。 網(wǎng)站又變慢了，這次是因?yàn)镮O和數(shù)據(jù)庫(kù)的問(wèn)題，問(wèn)題是怎么往應(yīng)用里面添加數(shù)據(jù)庫(kù)呢？

4 、五臺(tái)服務(wù)器

又買(mǎi)了一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。在兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上使用了數(shù)據(jù)庫(kù)同步(Mysql支持的Master-Slave模式)，寫(xiě)操作全部針對(duì)主數(shù)據(jù)庫(kù)（通過(guò)Binlog，主服務(wù)器上的寫(xiě)操作可以迅速同步到從服務(wù)器上），讀操作在兩個(gè)數(shù)據(jù)庫(kù)上同時(shí)進(jìn)行(也算是負(fù)載均橫的一種吧)。

實(shí)現(xiàn)同步時(shí)要注意幾個(gè)事項(xiàng)：

讀操作數(shù)據(jù)庫(kù)選擇算法處理，要選一個(gè)當(dāng)前負(fù)載輕一點(diǎn)的數(shù)據(jù)庫(kù)。 在從數(shù)據(jù)庫(kù)服務(wù)器上只能進(jìn)行讀操作 準(zhǔn)備好應(yīng)對(duì)同步過(guò)程中的延遲，處理不好可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)同步的中斷。只需要對(duì)寫(xiě)操作進(jìn)行判斷即可，讀操作不存在同步問(wèn)題。

5 、更多服務(wù)器

有錢(qián)了，當(dāng)然要多買(mǎi)些服務(wù)器。部署后快了沒(méi)多久，又開(kāi)始慢了。這次有更多的Web服務(wù)器，更多的數(shù)據(jù)庫(kù)服務(wù)器，存在 IO與CPU爭(zhēng)用。于是采用了BIG-IP作為負(fù)載均衡解決方案。

6 、現(xiàn)在我們?cè)谀睦?#xff1a;

現(xiàn)在服務(wù)器基本上夠了，但性能還是有問(wèn)題，原因出在架構(gòu)上。

數(shù)據(jù)庫(kù)的架構(gòu)是最大的問(wèn)題。由于增加的數(shù)據(jù)庫(kù)都是以Slave模式添加到應(yīng)用內(nèi)，這樣唯一的好處就是將讀操作分布到了多臺(tái)機(jī)器，但這樣帶來(lái)的后果就是寫(xiě)操作被大量分發(fā)，每臺(tái)機(jī)器都要執(zhí)行，服務(wù)器越多，浪費(fèi)就越大，隨著寫(xiě)操作的增加，用于服務(wù)讀操作的資源越來(lái)越少。 計(jì)算機(jī)電子書(shū)

由一臺(tái)分布到兩臺(tái)

最終效果

現(xiàn)在我們發(fā)現(xiàn)，我們并不需要把這些數(shù)據(jù)在如此多的服務(wù)器上都保留一份。服務(wù)器上已經(jīng)做了RAID，數(shù)據(jù)庫(kù)也進(jìn)行了備份，這么多的備份完全是對(duì)資源的浪費(fèi)，屬于冗余極端過(guò)度。那為什么不把數(shù)據(jù)分布存儲(chǔ)呢？

問(wèn)題發(fā)現(xiàn)了，開(kāi)始考慮如何解決。現(xiàn)在要做的就是把不同用戶(hù)的數(shù)據(jù)分布到不同的服務(wù)器上進(jìn)行存儲(chǔ)，以實(shí)現(xiàn)數(shù)據(jù)的分布式存儲(chǔ)，讓每臺(tái)機(jī)器只為相對(duì)固定的用戶(hù)服務(wù)，以實(shí)現(xiàn)平行的架構(gòu)和良好的可擴(kuò)展性。

為了實(shí)現(xiàn)用戶(hù)分組，我們需要為每一個(gè)用戶(hù)分配一個(gè)組標(biāo)記，用于標(biāo)記此用戶(hù)的數(shù)據(jù)存放在哪一組數(shù)據(jù)庫(kù)服務(wù)器中。每組數(shù)據(jù)庫(kù)由一個(gè)master及幾個(gè)slave組成，并且slave的數(shù)量在2-3臺(tái)，以實(shí)現(xiàn)系統(tǒng)資源的最合理分配，既保證數(shù)據(jù)讀操作分布，又避免數(shù)據(jù)過(guò)度冗余以及同步操作對(duì)系統(tǒng)資源的過(guò)度消耗。

由一臺(tái)（一組）中心服務(wù)器提供用戶(hù)分組控制。所有用戶(hù)的分組信息都存儲(chǔ)在這臺(tái)機(jī)器上，所有針對(duì)用戶(hù)的操作需要先查詢(xún)這臺(tái)機(jī)器得到用戶(hù)的組號(hào)，然后再到相應(yīng)的數(shù)據(jù)庫(kù)組中獲取數(shù)據(jù)。

這樣的用戶(hù)架構(gòu)與目前LJ的架構(gòu)已經(jīng)很相像了。

在具體的實(shí)現(xiàn)時(shí)需要注意幾個(gè)問(wèn)題：

在數(shù)據(jù)庫(kù)組內(nèi)不要使用自增ID，以便于以后在數(shù)據(jù)庫(kù)組之間遷移用戶(hù)，以實(shí)現(xiàn)更合理的I/O，磁盤(pán)空間及負(fù)載分布。 將userid，postid存儲(chǔ)在全局服務(wù)器上，可以使用自增，數(shù)據(jù)庫(kù)組中的相應(yīng)值必須以全局服務(wù)器上的值為準(zhǔn)。全局服務(wù)器上使用事務(wù)型數(shù)據(jù)庫(kù)InnoDB。計(jì)算機(jī)電子書(shū) 在數(shù)據(jù)庫(kù)組之間遷移用戶(hù)時(shí)要萬(wàn)分小心，當(dāng)遷移時(shí)用戶(hù)不能有寫(xiě)操作。

7 、現(xiàn)在我們?cè)谀睦?/strong>

問(wèn)題：

一個(gè)全局主服務(wù)器，掛掉的話(huà)所有用戶(hù)注冊(cè)及寫(xiě)操作就掛掉。 每個(gè)數(shù)據(jù)庫(kù)組一個(gè)主服務(wù)器，掛掉的話(huà)這組用戶(hù)的寫(xiě)操作就掛掉。 數(shù)據(jù)庫(kù)組從服務(wù)器掛掉的話(huà)會(huì)導(dǎo)致其它服務(wù)器負(fù)載過(guò)大。

對(duì)于Master-Slave模式的單點(diǎn)問(wèn)題，LJ采取了Master-Master模式來(lái)解決。所謂Master-Master實(shí)際上是人工實(shí)現(xiàn)的，并不是由MySQL直接提供的，實(shí)際上也就是兩臺(tái)機(jī)器同時(shí)是Master，也同時(shí)是Slave，互相同步。

Master-Master實(shí)現(xiàn)時(shí)需要注意：

一個(gè)Master出錯(cuò)后恢復(fù)同步，最好由服務(wù)器自動(dòng)完成。 數(shù)字分配，由于同時(shí)在兩臺(tái)機(jī)器上寫(xiě)，有些ID可能會(huì)沖突。

解決方案：

奇偶數(shù)分配ID，一臺(tái)機(jī)器上寫(xiě)奇數(shù)，一臺(tái)機(jī)器上寫(xiě)偶數(shù) 通過(guò)全局服務(wù)器進(jìn)行分配(LJ采用的做法)。

Master-Master模式還有一種用法，這種方法與前一種相比，仍然保持兩臺(tái)機(jī)器的同步，但只有一臺(tái)機(jī)器提供服務(wù)（讀和寫(xiě)），在每天晚上的時(shí)候進(jìn)行輪換，或者出現(xiàn)問(wèn)題的時(shí)候進(jìn)行切換。

8 、現(xiàn)在我們?cè)谀睦?/strong>

現(xiàn)在插播一條廣告，MyISAM VS InnoDB。

使用InnoDB：

支持事務(wù) 需要做更多的配置，不過(guò)值得，可以更安全的存儲(chǔ)數(shù)據(jù)，以及得到更快的速度。

使用MyISAM：

記錄日志（LJ用它來(lái)記網(wǎng)絡(luò)訪(fǎng)問(wèn)日志） 存儲(chǔ)只讀靜態(tài)數(shù)據(jù)，足夠快。 并發(fā)性很差，無(wú)法同時(shí)讀寫(xiě)數(shù)據(jù)（添加數(shù)據(jù)可以） MySQL非正常關(guān)閉或死機(jī)時(shí)會(huì)導(dǎo)致索引錯(cuò)誤，需要使用myisamchk修復(fù)，而且當(dāng)訪(fǎng)問(wèn)量大時(shí)出現(xiàn)非常頻繁。

9 、緩存

去年我寫(xiě)過(guò)一篇文章介紹memcached ，它就是由LJ的團(tuán)隊(duì)開(kāi)發(fā)的一款緩存工具，以key-value的方式將數(shù)據(jù)存儲(chǔ)到分布的內(nèi)存中。LJ緩存的數(shù)據(jù)：

12臺(tái)獨(dú)立服務(wù)器（不是捐贈(zèng)的） 28個(gè)實(shí)例 30GB總?cè)萘?90-93%的命中率（用過(guò)squid的人可能知道，squid內(nèi)存加磁盤(pán)的命中率大概在70-80%）

如何建立緩存策略？

想緩存所有的東西？那是不可能的，我們只需要緩存已經(jīng)或者可能導(dǎo)致系統(tǒng)瓶頸的地方，最大程度的提交系統(tǒng)運(yùn)行效率。通過(guò)對(duì)MySQL的日志的分析我們可以找到緩存的對(duì)象。 計(jì)算機(jī)電子書(shū)

緩存的缺點(diǎn)？

沒(méi)有完美的事物，緩存也有缺點(diǎn)： 增大開(kāi)發(fā)量，需要針對(duì)緩存處理編寫(xiě)特殊的代碼。 管理難度增加，需要更多人參與系統(tǒng)維護(hù)。 當(dāng)然大內(nèi)存也需要錢(qián)。

10 、Web 訪(fǎng)問(wèn)負(fù)載均衡

在數(shù)據(jù)包級(jí)別使用BIG-IP，但BIG-IP并不知道我們內(nèi)部的處理機(jī)制，無(wú)法判斷由哪臺(tái)服務(wù)器對(duì)這些請(qǐng)求進(jìn)行處理。反向代理并不能很好的起到作用，不是已經(jīng)夠快了，就是達(dá)不到我們想要的效果。

所以，LJ又開(kāi)發(fā)了Perlbal 。特點(diǎn)：

快，小，可管理的http web 服務(wù)器/代理 可以在內(nèi)部進(jìn)行轉(zhuǎn)發(fā) 使用Perl開(kāi)發(fā) 單線(xiàn)程，異步，基于事件，使用epoll , kqueue 支持Console管理與http遠(yuǎn)程管理，支持動(dòng)態(tài)配置加載 多種模式：web服務(wù)器，反向代理，插件 支持插件：GIF/PNG互換？

11 、MogileFS

LJ使用開(kāi)源的MogileFS 作為分布式文件存儲(chǔ)系統(tǒng)。MogileFS使用非常簡(jiǎn)單，它的主要設(shè)計(jì)思想是：

文件屬于類(lèi)（類(lèi)是最小的復(fù)制單位） 跟蹤文件存儲(chǔ)位置 在不同主機(jī)上存儲(chǔ) 使用MySQL集群統(tǒng)一存儲(chǔ)分布信息 大容易廉價(jià)磁盤(pán)

到目前為止就這么多了，更多文檔可以在http://www.danga.com/words/ 找到。Danga.com 和LiveJournal.com 的同學(xué)們拿這個(gè)文檔參加了兩次MySQL Con，兩次OS Con，以及眾多的其它會(huì)議，無(wú)私的把他們的經(jīng)驗(yàn)分享出來(lái)，值得我們學(xué)習(xí)。在web2.0時(shí)代快速開(kāi)發(fā)得到大家越來(lái)越多的重視，但良好的設(shè)計(jì)仍是每一個(gè)應(yīng)用的基礎(chǔ)，希望web2.0們?cè)诔砷L(zhǎng)為T(mén)op500網(wǎng)站的路上，不要因?yàn)榧軜?gòu)阻礙了網(wǎng)站的發(fā)展。 計(jì)算機(jī)電子書(shū)

八、 說(shuō)說(shuō)大型高并發(fā)高負(fù)載網(wǎng)站的系統(tǒng)架構(gòu)

我在Cernet做過(guò)撥號(hào)接入平臺(tái)的搭建，而后在Yahoo3721負(fù)載搜索引擎前端平臺(tái)開(kāi)發(fā)，又在貓撲處理過(guò)大型社區(qū)貓撲大雜燴的架構(gòu)升級(jí)等工作，同時(shí)自己接觸和開(kāi)發(fā)過(guò)不少大中型網(wǎng)站的模塊，因此在大型網(wǎng)站應(yīng)對(duì)高負(fù)載和并發(fā)的解決方案上有一些積累和經(jīng)驗(yàn)，可以和大家一起探討一下。

一個(gè)小型的網(wǎng)站，比如個(gè)人網(wǎng)站，可以使用最簡(jiǎn)單的html靜態(tài)頁(yè)面就實(shí)現(xiàn)了，配合一些圖片達(dá)到美化效果，所有的頁(yè)面均存放在一個(gè)目錄下，這樣的網(wǎng)站對(duì)系統(tǒng)架構(gòu)、性能的要求都很簡(jiǎn)單，隨著互聯(lián)網(wǎng)業(yè)務(wù)的不斷豐富，網(wǎng)站相關(guān)的技術(shù)經(jīng)過(guò)這些年的發(fā)展，已經(jīng)細(xì)分到很細(xì)的方方面面，尤其對(duì)于大型網(wǎng)站來(lái)說(shuō)，所采用的技術(shù)更是涉及面非常廣，從硬件到軟件、編程語(yǔ)言、數(shù)據(jù)庫(kù)、WebServer、防火墻等各個(gè)領(lǐng)域都有了很高的要求，已經(jīng)不是原來(lái)簡(jiǎn)單的html靜態(tài)網(wǎng)站所能比擬的。

大型網(wǎng)站，比如門(mén)戶(hù)網(wǎng)站。在面對(duì)大量用戶(hù)訪(fǎng)問(wèn)、高并發(fā)請(qǐng)求方面，基本的解決方案集中在這樣幾個(gè)環(huán)節(jié)：使用高性能的服務(wù)器、高性能的數(shù)據(jù)庫(kù)、高效率的編程語(yǔ)言、還有高性能的Web容器。但是除了這幾個(gè)方面，還沒(méi)法根本解決大型網(wǎng)站面臨的高負(fù)載和高并發(fā)問(wèn)題。

上面提供的幾個(gè)解決思路在一定程度上也意味著更大的投入，并且這樣的解決思路具備瓶頸，沒(méi)有很好的擴(kuò)展性，下面我從低成本、高性能和高擴(kuò)張性的角度來(lái)說(shuō)說(shuō)我的一些經(jīng)驗(yàn)。 計(jì)算機(jī)電子書(shū)

1、HTML靜態(tài)化

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

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

同時(shí)，html靜態(tài)化也是某些緩存策略使用的手段，對(duì)于系統(tǒng)中頻繁使用數(shù)據(jù)庫(kù)查詢(xún)但是內(nèi)容更新很小的應(yīng)用，可以考慮使用html靜態(tài)化來(lái)實(shí)現(xiàn)，比如論壇中論壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進(jìn)行后臺(tái)管理并且存儲(chǔ)再數(shù)據(jù)庫(kù)中，這些信息其實(shí)大量被前臺(tái)程序調(diào)用，但是更新頻率很小，可以考慮將這部分內(nèi)容進(jìn)行后臺(tái)更新的時(shí)候進(jìn)行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫(kù)訪(fǎng)問(wèn)請(qǐng)求。

2、圖片服務(wù)器分離

大家知道，對(duì)于Web服務(wù)器來(lái)說(shuō)，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁(yè)面進(jìn)行分離，這是基本上大型網(wǎng)站都會(huì)采用的策略，他們都有獨(dú)立的圖片服務(wù)器，甚至很多臺(tái)圖片服務(wù)器。這樣的架構(gòu)可以降低提供頁(yè)面訪(fǎng)問(wèn)請(qǐng)求的服務(wù)器系統(tǒng)壓力，并且可以保證系統(tǒng)不會(huì)因?yàn)閳D片問(wèn)題而崩潰，在應(yīng)用服務(wù)器和圖片服務(wù)器上，可以進(jìn)行不同的配置優(yōu)化，比如apache在配置ContentType的時(shí)候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率。

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

大型網(wǎng)站都有復(fù)雜的應(yīng)用，這些應(yīng)用必須使用數(shù)據(jù)庫(kù)，那么在面對(duì)大量訪(fǎng)問(wèn)的時(shí)候，數(shù)據(jù)庫(kù)的瓶頸很快就能顯現(xiàn)出來(lái)，這時(shí)一臺(tái)數(shù)據(jù)庫(kù)將很快無(wú)法滿(mǎn)足應(yīng)用，于是我們需要使用數(shù)據(jù)庫(kù)集群或者庫(kù)表散列。

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

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

4、緩存

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

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

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

5、鏡像

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

6、負(fù)載均衡

負(fù)載均衡將是大型網(wǎng)站解決高負(fù)荷訪(fǎng)問(wèn)和大量并發(fā)請(qǐng)求采用的終極解決辦法。

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

硬件四層交換

第四層交換使用第三層和第四層信息包的報(bào)頭信息，根據(jù)應(yīng)用區(qū)間識(shí)別業(yè)務(wù)流，將整個(gè)區(qū)間段的業(yè)務(wù)流分配到合適的應(yīng)用服務(wù)器進(jìn)行處理。　第四層交換功能就象是虛IP，指向物理服務(wù)器。它傳輸?shù)臉I(yè)務(wù)服從的協(xié)議多種多樣，有HTTP、FTP、NFS、Telnet或其他協(xié)議。這些業(yè)務(wù)在物理服務(wù)器基礎(chǔ)上，需要復(fù)雜的載量平衡算法。在IP世界，業(yè)務(wù)類(lèi)型由終端TCP或UDP端口地址來(lái)決定，在第四層交換中的應(yīng)用區(qū)間則由源端和終端IP地址、TCP和UDP端口共同決定。

在硬件四層交換產(chǎn)品領(lǐng)域，有一些知名的產(chǎn)品可以選擇，比如Alteon、F5等，這些產(chǎn)品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力。Yahoo中國(guó)當(dāng)初接近2000臺(tái)服務(wù)器使用了三四臺(tái)Alteon就搞定了。

軟件四層交換

大家知道了硬件四層交換機(jī)的原理后，基于OSI模型來(lái)實(shí)現(xiàn)的軟件四層交換也就應(yīng)運(yùn)而生，這樣的解決方案實(shí)現(xiàn)的原理一致，不過(guò)性能稍差。但是滿(mǎn)足一定量的壓力還是游刃有余的，有人說(shuō)軟件實(shí)現(xiàn)方式其實(shí)更靈活，處理能力完全看你配置的熟悉能力。計(jì)算機(jī)電子書(shū)

軟件四層交換我們可以使用Linux上常用的LVS來(lái)解決，LVS就是Linux Virtual Server，他提供了基于心跳線(xiàn)heartbeat的實(shí)時(shí)災(zāi)難應(yīng)對(duì)解決方案，提高系統(tǒng)的魯棒性，同時(shí)可供了靈活的虛擬VIP配置和管理功能，可以同時(shí)滿(mǎn)足多種應(yīng)用需求，這對(duì)于分布式的系統(tǒng)來(lái)說(shuō)必不可少。

一個(gè)典型的使用負(fù)載均衡的策

轉(zhuǎn)載于:https://www.cnblogs.com/shuke/archive/2010/01/26/1656483.html

總結(jié)

以上是生活随笔為你收集整理的大型Web2.0站点构建技术初探一的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。