各模塊間或者進程間的通信普遍異步化隊列化也相當重要，可以兼顧輕載重載時的響應性能和系統(tǒng)壓力,數(shù)據(jù)庫壓力可以通過file cache分解到文件系統(tǒng)，文件系統(tǒng)io壓力再通過mem cache分解，效果很不錯.

完全胡說八道!
“大家知道，對于Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的”,你以為是在內(nèi)存中動態(tài)生成圖片啊.無論是什么文件,在容器輸出時只是讀文件,輸出給response而已,和是什么文件有什么關系.

關鍵是靜態(tài)文件和動態(tài)頁面之間應該采用不同策略,如靜態(tài)文件應該盡量緩存,因為無論你請求多少次輸出內(nèi)容都是相同的,如果用戶頁面中有二十個就沒有必要請求二十次,而應該使用緩存.而動態(tài)頁面每次請求輸出都不相同(否則就應該是靜態(tài)的),所以不應該緩存.

所以即使在同一服務器上也可以對靜態(tài)和動態(tài)資源做不同優(yōu)化,專門的圖片服務器那是為了資源管理的方便,和你說的性能沒有關系.

Michael 您好，這篇文章我看幾次了，有一個問題，您的文章中提到了如下一段：

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

對于大型的站點來說，他的數(shù)據(jù)庫和 Web Server 一般都是分布式的，在多個區(qū)域都有部署，當某個地區(qū)的用戶訪問時會對應到一個節(jié)點上，如果是對社區(qū)內(nèi)的帖子實時靜態(tài)化，有更新時再重新靜態(tài)化，那么在節(jié)點 之間如何立刻同步呢？數(shù)據(jù)庫端如何實現(xiàn)呢？如果用戶看不到的話會以為發(fā)帖失敗？造成重復發(fā)了，那么如何將用戶鎖定在一個節(jié)點上呢，這些怎么解決？謝謝。

希望有空跟你學習請教網(wǎng)站負載問題。

一般對于一個中型網(wǎng)站來說，交互操作非常多，日PV百萬左右，如何做合理的負載？

請問，如果一個網(wǎng)站處于技術(shù)發(fā)展期，那么這些優(yōu)化手段應該先實施哪些后實施哪些呢？
或者說從成本（技術(shù)、人力和財力成本）方面，哪些先實施能夠取得最大效果呢？

恩，多謝Michael的耐心講解

Very good site. Thanks for author!

echonow on September 1, 2006 at 2:28 pm said:

贊一個先，是一篇很不錯的文章，不過要真正掌握里面的東西恐怕還是需要時間和實踐！

先問一下關于圖…

這位朋友說得很對，因為目前只有一臺服務器，所以從物理上無法實現(xiàn)真正的分離，暫時使用虛擬主機來實現(xiàn)，是為了程序設計和網(wǎng)站架構(gòu)上的靈活，如果有 了一臺新的服務器，我只需要把圖片鏡像過去或者同步過去，然后把img.9tmd.com的dns解析到新的服務器上就自然實現(xiàn)了分離，如果現(xiàn)在不從架構(gòu) 和程序上實現(xiàn)，今后這樣的分離就會比較痛苦:)

echonow on September 7, 2006 at 4:59 pm said:

謝謝lz的回復，現(xiàn)在主要實現(xiàn)問題是如何能在素材上傳時直接傳到圖片服務器上呢，總不至于每次先傳到web…

通過samba或者nfs實現(xiàn)是比較簡單的方法。然后使用squid緩存來降低訪問的負載，提高磁盤性能和延長磁盤使用壽命。

echonow on September 8, 2006 at 9:42 am said:

多謝樓主的耐心指導，我先研究下，用共享區(qū)來存儲確實是個不錯的想法!

不客氣，歡迎常交流！

回復fanstone：

關于如何在網(wǎng)站的前期盡可能低成本的投入，做到性能最大化利用，同時做好后期系統(tǒng)架構(gòu)的規(guī)劃，這個問題可以說已經(jīng)放大到超出技術(shù)范疇，不過和技術(shù)相關的部分還是有不少需要考慮的。

一個網(wǎng)站的規(guī)劃關鍵的就是對階段性目標的規(guī)劃，比如預測幾個月后達到什么用戶級別、存儲級別、并發(fā)請求數(shù)，然后再過幾個月又將什么情況，這些預測必 須根據(jù)具體業(yè)務和市場情況來進行預估和不斷調(diào)整的，有了這些預測數(shù)據(jù)作為參考，就能進行技術(shù)架構(gòu)的規(guī)劃，否則技術(shù)上是無法合理進行架構(gòu)設計的。

在網(wǎng)站發(fā)展規(guī)劃基礎上，考慮今后要提供什么樣的應用？有些什么樣的域名關系？各個應用之間的業(yè)務邏輯和關聯(lián)是什么？面對什么地域分布的用戶提供服務？等等。。。

上面這些問題有助于規(guī)劃網(wǎng)站服務器和設備投入，同時從技術(shù)上可以及早預測到未來將會是一個什么架構(gòu)，在滿足這個架構(gòu)下的每個節(jié)點將需要滿足什么條件，就是初期架構(gòu)的要求。

總的來說，不結(jié)合具體業(yè)務的技術(shù)規(guī)劃是沒有意義的，所以首先是業(yè)務規(guī)劃，也就是產(chǎn)品設計，然后才是技術(shù)規(guī)劃。

很 好的文章，樓主說的方法非常適用，目前我們公司的網(wǎng)站也是按照樓主所說的方法進行設計的，效果比較好，利于以后的擴展，另外我再補充一點，其實樓主也說 了，網(wǎng)站的域名也需要提前考慮和規(guī)劃，比如網(wǎng)站的圖片內(nèi)容比較多，可以按應用圖片的類型可以根據(jù)不同的業(yè)務需求采用不同的域名img1~imgN等，便于 日后的擴展和移至，希望樓主能夠多發(fā)一些這樣的好文章。

zhang on April 3, 2007 at 9:08 am said:

圖片服務器與主數(shù)據(jù)分離的問題。
圖片是存儲在硬盤里好還是存儲在數(shù)據(jù)庫里好？
請您分硬盤和數(shù)據(jù)庫兩…

肯定是存儲在硬盤里面，出現(xiàn)存儲在數(shù)據(jù)庫里面的說法實際上是出自一些虛擬主機或者租用空間的個人網(wǎng)站和企業(yè)網(wǎng)站，因為網(wǎng)站數(shù)據(jù)量小，也為了備份方便，從大型商業(yè)網(wǎng)站來說，沒有圖片存儲在數(shù)據(jù)庫里面的大型應用。數(shù)據(jù)庫容量和效率都會是極大的瓶頸。

你提到的后面兩個問題。容量和負載基本上是同時要考慮的問題，容量方面，大部分的解決方案都是使用海量存儲，比如專業(yè)的盤陣，入門級的磁盤柜或者高 級的光纖盤陣、局域網(wǎng)盤陣等，這些都是主要的解決方案。記得我原來說過，如果是考慮低成本，一定要自己使用便宜單臺服務器來存儲，那就需要從程序邏輯上去 控制，比如你可以多臺同樣的服務器來存儲，分別提供NFS的分區(qū)給前端應用使用，在前端應用的程序邏輯中自己去控制存儲在哪一臺服務器的NFS分區(qū)上，比 如根據(jù)Userid或者圖片id、或者別的邏輯去進行散列，這個和我們規(guī)劃大型數(shù)據(jù)庫存儲散列分表或者分庫存儲的邏輯類似。

基本上圖片負載高的解決辦法有兩種，前端squid緩存和鏡像，通過對存儲設備（服務器或者盤陣）使用鏡像，可以分布到多臺服務器上對外提供圖片服務，然后再配合squid緩存實現(xiàn)負載的降低和提高用戶訪問速度。

希望能回答了您的問題。

非常感謝您的回復，
希望將來有合作的機會。

再次感謝。

很少見到有朋友能在我得blog上留下這么多有價值的東西，代表別的可能看到這篇文章的朋友一起感謝你。

balance （http://www.inlab.de/balance.html） 這個東西準備看一下。

myspace和美國的許多銀行都更換為了3Par
請您在百忙之中核實一下，是否確實像說的那么好。
下面是摘抄：

Priceline.com是一家以銷售空座機票為主的網(wǎng)絡公司，客戶數(shù)量多達680萬。該公司近期正在內(nèi)部實施一項大規(guī)模的SAN系統(tǒng)整合計劃， 一口氣購進了5套3PARdata的服務器系統(tǒng)，用以替代現(xiàn)有的上百臺Sun存儲陣列。如果該方案部署成功的話，將有望為Priceline.com節(jié)省 大量的存儲管理時間、資本開銷及系統(tǒng)維護費用。
Priceline.com之前一直在使用的SAN系統(tǒng)是由50臺光纖磁盤陣列、50臺SCSI磁盤陣列和15臺存儲服務器構(gòu)成的。此次，該公司一舉 購入了5臺3Par S400 InServ Storage Servers存儲服務器，用以替代原來的服務器系統(tǒng)，使得設備整體能耗、占用空間及散熱一舉降低了60%。整個系統(tǒng)部署下來，總存儲容量將逼近 30TB。
Priceline的首席信息官Ron Rose拒絕透露該公司之前所使用的SAN系統(tǒng)設備的供應商名稱，不過，消息靈通人士表示，PriceLine原來的存儲環(huán)境是由不同型號的Sun系統(tǒng)混合搭建而成的。
“我們并不愿意隨便更換系統(tǒng)供應商，不過，3Par的存儲系統(tǒng)所具備的高投資回報率，實在令人難以抗拒，”Rose介紹說，“我們給了原來的設備供應 商以足夠的適應時間，希望它們的存儲設備也能夠提供與3Par一樣的效能，最后，我們失望了。如果換成3Par的存儲系統(tǒng)的話，短期內(nèi)就可以立刻見到成 效。”
Rose接著補充說，“原先使用的那套SAN系統(tǒng)，并沒有太多讓我們不滿意的地方，除了欠缺一點靈活性之外：系統(tǒng)的配置方案堪稱不錯，但并不是最優(yōu)化的。使用了大量價格偏貴的光纖磁盤，許多SAN端口都是閑置的。”

自從更換成3Par的磁盤陣列之后，該公司存儲系統(tǒng)的端口數(shù)量從90個驟減為24個。“我們購買的軟件許可證都是按端口數(shù)量來收費的。每增加一個端 口，需要額外支付500-1,500美元，單單這一項，就為我們節(jié)省了一筆相當可觀的開支，”Rose解釋說。而且，一旦啟用3Par的精簡自動配置軟 件，系統(tǒng)資源利用率將有望提升30%，至少在近一段時間內(nèi)該公司不必考慮添置新的磁盤系統(tǒng)。
精簡自動配置技術(shù)最大的功效就在于它能夠按照應用程序的實際需求來分配存儲資源，有效地降低了空間閑置率。如果當前運行的應用程序需要額外的存儲資源 的話，該軟件將在不干擾應用程序正常運行的前提下，基于“按需”和“公用”的原則來自動發(fā)放資源空間，避免了人力干預，至少為存儲管理員減輕了一半以上的 工作量。
3Par的磁盤陣列是由低成本的SATA和FATA（即：低成本光纖信道接口）磁盤驅(qū)動器構(gòu)成的，而并非昂貴的高效能FC磁盤，大大降低了系統(tǒng)整體成本。
3Par推出的SAN解決方案，實際上是遵循了“允許多個分布式介質(zhì)服務器共享通過光纖信道SAN 連接的公共的集中化存儲設備”的設計理念。“這樣一來，就不必給所有的存儲設備都外掛一個代理服務程序了，”Rose介紹說。出于容災容錯和負載均衡的考 慮，Priceline搭建了兩個生產(chǎn)站點，每一個站點都部署了一套3Par SAN系統(tǒng)。此外，Priceline還購買了兩臺3Par Inservs服務器，安置在主數(shù)據(jù)中心內(nèi)，專門用于存放鏡像文件。第5臺服務器設置在Priceline的企業(yè)資料處理中心內(nèi)，用于存放數(shù)據(jù)倉庫；第6 臺服務器設置在實驗室內(nèi)，專門用于進行實際網(wǎng)站壓力測試。

MySpace目前采用了一種新型SAN設備——來自加利福尼亞州弗里蒙特的3PARdata。在3PAR的系統(tǒng)里，仍能在邏輯上按容量劃分數(shù)據(jù)存 儲，但它不再被綁定到特定磁盤或磁盤簇，而是散布于大量磁盤。這就使均分數(shù)據(jù)訪問負荷成為可能。當數(shù)據(jù)庫需要寫入一組數(shù)據(jù)時，任何空閑磁盤都可以馬上完成 這項工作，而不再像以前那樣阻塞在可能已經(jīng)過載的磁盤陣列處。而且，因為多個磁盤都有數(shù)據(jù)副本，讀取數(shù)據(jù)時，也不會使SAN的任何組件過載。

3PAR宣布，VoIP服務供應商Cbeyond Communications已向它訂購了兩套InServ存儲服務器，一套應用于該公司的可操作支持系統(tǒng)，一套應用于測試和開發(fā)系統(tǒng)環(huán)境。3PAR的總 部設在亞特蘭大，該公司的產(chǎn)品多銷往美國各州首府和大城市，比如說亞特蘭大、達拉斯、丹佛、休斯頓、芝加哥，等等。截至目前為止，3PAR售出的服務器數(shù) 量已超過了15,000臺，許多客戶都是來自于各行各業(yè)的龍頭企業(yè)，它們之所以挑選3PAR的產(chǎn)品，主要是看中了它所具備的高性能、可擴展性、操作簡單、 無比倫比的性價比等優(yōu)點，另外，3PAR推出的服務器系列具有高度的集成性能，適合應用于高速度的T1互聯(lián)網(wǎng)接入、本地和長途語音服務、虛擬主機（Web hosting）、電子郵件、電話會議和虛擬個人網(wǎng)絡（VPN）等服務領域。

億萬用戶網(wǎng)站MySpace的成功秘密

◎ 文 / David F. Carr 譯 / 羅小平

高速增長的訪問量給社區(qū)網(wǎng)絡的技術(shù)體系帶來了巨大挑戰(zhàn)。MySpace的開發(fā)者多年來不斷重構(gòu)站點軟件、數(shù)據(jù)庫和存儲系統(tǒng)，以期與自身的成長同步 ——目前，該站點月訪問量已達400億。絕大多數(shù)網(wǎng)站需要應對的流量都不及MySpace的一小部分，但那些指望邁入龐大在線市場的人，可以從 MySpace的成長過程學到知識。

MySpace開發(fā)人員已經(jīng)多次重構(gòu)站點軟件、數(shù)據(jù)庫和存儲系統(tǒng)，以滿足爆炸性的成長需要，但此工作永不會停息。“就像粉刷金門大橋，工作完成之 時，就是重新來過之日。”（譯者注：意指工人從橋頭開始粉刷，當?shù)竭_橋尾時，橋頭涂料已經(jīng)剝落，必須重新開始）MySpace技術(shù)副總裁Jim Benedetto說。
既然如此，MySpace的技術(shù)還有何可學之處？因為MySpace事實上已經(jīng)解決了很多系統(tǒng)擴展性問題，才能走到今天。

Benedetto說他的項目組有很多教訓必須總結(jié)，他們?nèi)栽趯W習，路漫漫而修遠。他們當前需要改進的工作包括實現(xiàn)更靈活的數(shù)據(jù)緩存系統(tǒng)，以及為避免再次出現(xiàn)類似7月癱瘓事件的地理上分布式架構(gòu)。

背景知識
當然，這么多的用戶不停發(fā)布消息、撰寫評論或者更新個人資料，甚至一些人整天都泡在Space上，必然給MySpace的技術(shù)工作帶來前所未有的挑戰(zhàn)。而 傳統(tǒng)新聞站點的絕大多數(shù)內(nèi)容都是由編輯團隊整理后主動提供給用戶消費，它們的內(nèi)容數(shù)據(jù)庫通常可以優(yōu)化為只讀模式，因為用戶評論等引起的增加和更新操作很 少。而MySpace是由用戶提供內(nèi)容，數(shù)據(jù)庫很大比例的操作都是插入和更新，而非讀取。
瀏覽MySpace上的任何個人資料時，系統(tǒng)都必須先查詢數(shù)據(jù)庫，然后動態(tài)創(chuàng)建頁面。當然，通過數(shù)據(jù)緩存，可以減輕數(shù)據(jù)庫的壓力，但這種方案必須解決原始數(shù)據(jù)被用戶頻繁更新帶來的同步問題。

MySpace的站點架構(gòu)已經(jīng)歷了5個版本——每次都是用戶數(shù)達到一個里程碑后，必須做大量的調(diào)整和優(yōu)化。Benedetto說，“但我們始終跟不上形勢的發(fā)展速度。我們重構(gòu)重構(gòu)再重構(gòu)，一步步挪到今天”。

在每個里程碑，站點負擔都會超過底層系統(tǒng)部分組件的最大載荷，特別是數(shù)據(jù)庫和存儲系統(tǒng)。接著，功能出現(xiàn)問題，用戶失聲尖叫。最后，技術(shù)團隊必須為此修訂系統(tǒng)策略。
雖然自2005年早期，站點賬戶數(shù)超過7百萬后，系統(tǒng)架構(gòu)到目前為止保持了相對穩(wěn)定，但MySpace仍然在為SQL Server支持的同時連接數(shù)等方面繼續(xù)攻堅，Benedetto說，“我們已經(jīng)盡可能把事情做到最好”。

里程碑一：50萬賬戶
按Benedetto 的說法，MySpace最初的系統(tǒng)很小，只有兩臺Web服務器和一個數(shù)據(jù)庫服務器。那時使用的是Dell雙CPU、4G內(nèi)存的系統(tǒng)。
單個數(shù)據(jù)庫就意味著所有數(shù)據(jù)都存儲在一個地方，再由兩臺Web服務器分擔處理用戶請求的工作量。但就像MySpace后來的幾次底層系統(tǒng)修訂時的情況一樣，三服務器架構(gòu)很快不堪重負。此后一個時期內(nèi)，MySpace基本是通過添置更多Web服務器來對付用戶暴增問題的。
但到在2004年早期，MySpace用戶數(shù)增長到50萬后，數(shù)據(jù)庫服務器也已開始汗流浹背。
但和Web服務器不同，增加數(shù)據(jù)庫可沒那么簡單。如果一個站點由多個數(shù)據(jù)庫支持，設計者必須考慮的是，如何在保證數(shù)據(jù)一致性的前提下，讓多個數(shù)據(jù)庫分擔壓力。
在第二代架構(gòu)中，MySpace運行在3個SQL Server數(shù)據(jù)庫服務器上——一個為主，所有的新數(shù)據(jù)都向它提交，然后由它復制到其他兩個；另兩個全力向用戶供給數(shù)據(jù)，用以在博客和個人資料欄顯示。這 種方式在一段時間內(nèi)效果很好——只要增加數(shù)據(jù)庫服務器，加大硬盤，就可以應對用戶數(shù)和訪問量的增加。

里程碑二：1-2百萬賬戶
MySpace注冊數(shù)到達1百萬至2百萬區(qū)間后，數(shù)據(jù)庫服務器開始受制于I/O容量——即它們存取數(shù)據(jù)的速度。而當時才是2004年中，距離上次數(shù)據(jù)庫系 統(tǒng)調(diào)整不過數(shù)月。用戶的提交請求被阻塞，就像千人樂迷要擠進只能容納幾百人的夜總會，站點開始遭遇“主要矛盾”，Benedetto說，這意味著 MySpace永遠都會輕度落后于用戶需求。
“有人花5分鐘都無法完成留言，因此用戶總是抱怨說網(wǎng)站已經(jīng)完蛋了。”他補充道。
這一次的數(shù)據(jù)庫架構(gòu)按照垂直分割模式設計，不同的數(shù)據(jù)庫服務于站點的不同功能，如登錄、用戶資料和博客。于是，站點的擴展性問題看似又可以告一段落了，可以歇一陣子。
垂直分割策略利于多個數(shù)據(jù)庫分擔訪問壓力，當用戶要求增加新功能時，MySpace將投入新的數(shù)據(jù)庫予以支持它。賬戶到達2百萬后，MySpace還從存 儲設備與數(shù)據(jù)庫服務器直接交互的方式切換到SAN（Storage Area Network，存儲區(qū)域網(wǎng)絡）——用高帶寬、專門設計的網(wǎng)絡將大量磁盤存儲設備連接在一起，而數(shù)據(jù)庫連接到SAN。這項措施極大提升了系統(tǒng)性能、正常運 行時間和可靠性，Benedetto說。

里程碑三：3百萬賬戶
當用戶繼續(xù)增加到3百萬后，垂直分割策略也開始難以為繼。盡管站點的各個應用被設計得高度獨立，但有些信息必須共享。在這個架構(gòu)里，每個數(shù)據(jù)庫必須有各自 的用戶表副本——MySpace授權(quán)用戶的電子花名冊。這就意味著一個用戶注冊時，該條賬戶記錄必須在9個不同數(shù)據(jù)庫上分別創(chuàng)建。但在個別情況下，如果其 中某臺數(shù)據(jù)庫服務器臨時不可到達，對應事務就會失敗，從而造成賬戶非完全創(chuàng)建，最終導致此用戶的該項服務無效。
另外一個問題是，個別應用如博客增長太快，那么專門為它服務的數(shù)據(jù)庫就有巨大壓力。
2004年中，MySpace面臨Web開發(fā)者稱之為“向上擴展”對“向外擴展”（譯者注：Scale Up和Scale Out，也稱硬件擴展和軟件擴展）的抉擇——要么擴展到更大更強、也更昂貴的服務器上，要么部署大量相對便宜的服務器來分擔數(shù)據(jù)庫壓力。一般來說，大型站 點傾向于向外擴展，因為這將讓它們得以保留通過增加服務器以提升系統(tǒng)能力的后路。
但成功地向外擴展架構(gòu)必須解決復雜的分布式計算問題，大型站點如Google、Yahoo和Amazon.com，都必須自行研發(fā)大量相關技術(shù)。以Google為例，它構(gòu)建了自己的分布式文件系統(tǒng)。
另外，向外擴展策略還需要大量重寫原來軟件，以保證系統(tǒng)能在分布式服務器上運行。“搞不好，開發(fā)人員的所有工作都將白費”，Benedetto說。
因此，MySpace首先將重點放在了向上擴展上，花費了大約1個半月時間研究升級到32CPU服務器以管理更大數(shù)據(jù)庫的問題。Benedetto說，“那時候，這個方案看似可能解決一切問題。”如穩(wěn)定性，更棒的是對現(xiàn)有軟件幾乎沒有改動要求。
糟糕的是，高端服務器極其昂貴，是購置同樣處理能力和內(nèi)存速度的多臺服務器總和的很多倍。而且，站點架構(gòu)師預測，從長期來看，即便是巨型數(shù)據(jù)庫，最后也會不堪重負，Benedetto說，“換句話講，只要增長趨勢存在，我們最后無論如何都要走上向外擴展的道路。”
因此，MySpace最終將目光移到分布式計算架構(gòu)——它在物理上分布的眾多服務器，整體必須邏輯上等同于單臺機器。拿數(shù)據(jù)庫來說，就不能再像過去那樣將 應用拆分，再以不同數(shù)據(jù)庫分別支持，而必須將整個站點看作一個應用。現(xiàn)在，數(shù)據(jù)庫模型里只有一個用戶表，支持博客、個人資料和其他核心功能的數(shù)據(jù)都存儲在 相同數(shù)據(jù)庫。
既然所有的核心數(shù)據(jù)邏輯上都組織到一個數(shù)據(jù)庫，那么MySpace必須找到新的辦法以分擔負荷——顯然，運行在普通硬件上的單個數(shù)據(jù)庫服務器是無能為力 的。這次，不再按站點功能和應用分割數(shù)據(jù)庫，MySpace開始將它的用戶按每百萬一組分割，然后將各組的全部數(shù)據(jù)分別存入獨立的SQL Server實例。目前，MySpace的每臺數(shù)據(jù)庫服務器實際運行兩個SQL Server實例，也就是說每臺服務器服務大約2百萬用戶。Benedetto指出，以后還可以按照這種模式以更小粒度劃分架構(gòu)，從而優(yōu)化負荷分擔。
當然，還是有一個特殊數(shù)據(jù)庫保存了所有賬戶的名稱和密碼。用戶登錄后，保存了他們其他數(shù)據(jù)的數(shù)據(jù)庫再接管服務。特殊數(shù)據(jù)庫的用戶表雖然龐大，但它只負責用戶登錄，功能單一，所以負荷還是比較容易控制的。

里程碑四：9百萬到1千7百萬賬戶
2005年早期，賬戶達到9百萬后，MySpace開始用Microsoft的C#編寫ASP.NET程序。C#是C語言的最新派生語言，吸收了C++和 Java的優(yōu)點，依托于Microsoft .NET框架（Microsoft為軟件組件化和分布式計算而設計的模型架構(gòu)）。ASP.NET則由編寫Web站點腳本的ASP技術(shù)演化而來，是 Microsoft目前主推的Web站點編程環(huán)境。
可以說是立竿見影，MySpace馬上就發(fā)現(xiàn)ASP.NET程序運行更有效率，與ColdFusion相比，完成同樣任務需消耗的處理器能力更小。據(jù)技術(shù) 總監(jiān)Whitcomb說，新代碼需要150臺服務器完成的工作，如果用ColdFusion則需要246臺。Benedetto還指出，性能上升的另一個 原因可能是在變換軟件平臺，并用新語言重寫代碼的過程中，程序員復審并優(yōu)化了一些功能流程。

最終，MySpace開始大規(guī)模遷移到ASP.NET。即便剩余的少部分ColdFusion代碼，也從Cold-Fusion服務器搬到了 ASP.NET，因為他們得到了BlueDragon.NET（喬治亞州阿爾法利塔New Atlanta Communications公司的產(chǎn)品，它能將ColdFusion代碼自動重新編譯到Microsoft平臺）的幫助。
賬戶達到1千萬時，MySpace再次遭遇存儲瓶頸問題。SAN的引入解決了早期一些性能問題，但站點目前的要求已經(jīng)開始周期性超越SAN的I/O容量——即它從磁盤存儲系統(tǒng)讀寫數(shù)據(jù)的極限速度。
原因之一是每數(shù)據(jù)庫1百萬賬戶的分割策略，通常情況下的確可以將壓力均分到各臺服務器，但現(xiàn)實并非一成不變。比如第七臺賬戶數(shù)據(jù)庫上線后，僅僅7天就被塞滿了，主要原因是佛羅里達一個樂隊的歌迷瘋狂注冊。
某個數(shù)據(jù)庫可能因為任何原因，在任何時候遭遇主要負荷，這時，SAN中綁定到該數(shù)據(jù)庫的磁盤存儲設備簇就可能過載。“SAN讓磁盤I/O能力大幅提升了，但將它們綁定到特定數(shù)據(jù)庫的做法是錯誤的。”Benedetto說。
最初，MySpace通過定期重新分配SAN中數(shù)據(jù)，以讓其更為均衡的方法基本解決了這個問題，但這是一個人工過程，“大概需要兩個人全職工作。”Benedetto說。
長期解決方案是遷移到虛擬存儲體系上，這樣，整個SAN被當作一個巨型存儲池，不再要求每個磁盤為特定應用服務。MySpace目前采用了一種新型SAN設備——來自加利福尼亞州弗里蒙特的3PARdata。
在3PAR的系統(tǒng)里，仍能在邏輯上按容量劃分數(shù)據(jù)存儲，但它不再被綁定到特定磁盤或磁盤簇，而是散布于大量磁盤。這就使均分數(shù)據(jù)訪問負荷成為可能。當數(shù)據(jù) 庫需要寫入一組數(shù)據(jù)時，任何空閑磁盤都可以馬上完成這項工作，而不再像以前那樣阻塞在可能已經(jīng)過載的磁盤陣列處。而且，因為多個磁盤都有數(shù)據(jù)副本，讀取數(shù) 據(jù)時，也不會使SAN的任何組件過載。
當2005年春天賬戶數(shù)達到1千7百萬時，MySpace又啟用了新的策略以減輕存儲系統(tǒng)壓力，即增加數(shù)據(jù)緩存層——位于Web服務器和數(shù)據(jù)庫服務器之 間，其唯一職能是在內(nèi)存中建立被頻繁請求數(shù)據(jù)對象的副本，如此一來，不訪問數(shù)據(jù)庫也可以向Web應用供給數(shù)據(jù)。換句話說，100個用戶請求同一份資料，以 前需要查詢數(shù)據(jù)庫100次，而現(xiàn)在只需1次，其余都可從緩存數(shù)據(jù)中獲得。當然如果頁面變化，緩存的數(shù)據(jù)必須從內(nèi)存擦除，然后重新從數(shù)據(jù)庫獲取——但在此之 前，數(shù)據(jù)庫的壓力已經(jīng)大大減輕，整個站點的性能得到提升。
緩存區(qū)還為那些不需要記入數(shù)據(jù)庫的數(shù)據(jù)提供了驛站，比如為跟蹤用戶會話而創(chuàng)建的臨時文件——Benedetto坦言他需要在這方面補課，“我是數(shù)據(jù)庫存儲狂熱分子，因此我總是想著將萬事萬物都存到數(shù)據(jù)庫。”但將像會話跟蹤這類的數(shù)據(jù)也存到數(shù)據(jù)庫，站點將陷入泥沼。
增加緩存服務器是“一開始就應該做的事情，但我們成長太快，以致于沒有時間坐下來好好研究這件事情。”Benedetto補充道。

里程碑五：2千6百萬賬戶
2005年中期，服務賬戶數(shù)達到2千6百萬時，MySpace切換到了還處于beta測試的SQL Server 2005。轉(zhuǎn)換何太急？主流看法是2005版支持64位處理器。但Benedetto說，“這不是主要原因，盡管這也很重要；主要還是因為我們對內(nèi)存的渴 求。”支持64位的數(shù)據(jù)庫可以管理更多內(nèi)存。
更多內(nèi)存就意味著更高的性能和更大的容量。原來運行32位版本的SQL Server服務器，能同時使用的內(nèi)存最多只有4G。切換到64位，就好像加粗了輸水管的直徑。升級到SQL Server 2005和64位Windows Server 2003后，MySpace每臺服務器配備了32G內(nèi)存，后于2006年再次將配置標準提升到64G。

意外錯誤
如果沒有對系統(tǒng)架構(gòu)的歷次修改與升級，MySpace根本不可能走到今天。但是，為什么系統(tǒng)還經(jīng)常吃撐著了？很多用戶抱怨的“意外錯誤”是怎么引起的呢？
原因之一是MySpace對Microsoft的Web技術(shù)的應用已經(jīng)進入連Microsoft自己也才剛剛開始探索的領域。比如11月，超出SQL Server最大同時連接數(shù)，MySpace系統(tǒng)崩潰。Benedetto說，這類可能引發(fā)系統(tǒng)崩潰的情況大概三天才會出現(xiàn)一次，但仍然過于頻繁了，以致 惹人惱怒。一旦數(shù)據(jù)庫罷工，“無論這種情況什么時候發(fā)生，未緩存的數(shù)據(jù)都不能從SQL Server獲得，那么你就必然看到一個‘意外錯誤’提示。”他解釋說。
去年夏天，MySpace的Windows 2003多次自動停止服務。后來發(fā)現(xiàn)是操作系統(tǒng)一個內(nèi)置功能惹的禍——預防分布式拒絕服務攻擊（黑客使用很多客戶機向服務器發(fā)起大量連接請求，以致服務器 癱瘓）。MySpace和其他很多頂級大站點一樣，肯定會經(jīng)常遭受攻擊，但它應該從網(wǎng)絡級而不是依靠Windows本身的功能來解決問題——否則，大量 MySpace合法用戶連接時也會引起服務器反擊。
“我們花了大約一個月時間尋找Windows 2003服務器自動停止的原因。”Benedetto說。最后，通過Microsoft的幫助，他們才知道該怎么通知服務器：“別開槍，是友軍。”
緊接著是在去年7月某個周日晚上，MySpace總部所在地洛杉磯停電，造成整個系統(tǒng)停運12小時。大型Web站點通常要在地理上分布配置多個數(shù)據(jù)中心以 預防單點故障。本來，MySpace還有其他兩個數(shù)據(jù)中心以應對突發(fā)事件，但Web服務器都依賴于部署在洛杉磯的SAN。沒有洛杉磯的SAN，Web服務 器除了懇求你耐心等待，不能提供任何服務。
Benedetto說，主數(shù)據(jù)中心的可靠性通過下列措施保證：可接入兩張不同電網(wǎng)，另有后備電源和一臺儲備有30天燃料的發(fā)電機。但在這次事故中，不僅兩張電網(wǎng)失效，而且在切換到備份電源的過程中，操作員燒掉了主動力線路。
2007年中，MySpace在另兩個后備站點上也建設了SAN。這對分擔負荷大有幫助——正常情況下，每個SAN都能負擔三分之一的數(shù)據(jù)訪問量。而在緊急情況下，任何一個站點都可以獨立支撐整個服務，Benedetto說。
MySpace仍然在為提高穩(wěn)定性奮斗，雖然很多用戶表示了足夠信任且能原諒偶現(xiàn)的錯誤頁面。
“作為開發(fā)人員，我憎惡Bug，它太氣人了。”Dan Tanner這個31歲的德克薩斯軟件工程師說，他通過MySpace重新聯(lián)系到了高中和大學同學。“不過，MySpace對我們的用處很大，因此我們可 以原諒偶發(fā)的故障和錯誤。” Tanner說，如果站點某天出現(xiàn)故障甚至崩潰，恢復以后他還是會繼續(xù)使用。
這就是為什么Drew在論壇里咆哮時，大部分用戶都告訴他應該保持平靜，如果等幾分鐘，問題就會解決的原因。Drew無法平靜，他寫道，“我已經(jīng)兩次給 MySpace發(fā)郵件，而它說一小時前還是正常的，現(xiàn)在出了點問題……完全是一堆廢話。”另一個用戶回復說，“畢竟它是免費的。”Benedetto坦承 100%的可靠性不是他的目標。“它不是銀行，而是一個免費的服務。”他說。
換句話說，MySpace的偶發(fā)故障可能造成某人最后更新的個人資料丟失，但并不意味著網(wǎng)站弄丟了用戶的錢財。“關鍵是要認識到，與保證站點性能相比，丟 失少許數(shù)據(jù)的故障是可接受的。”Benedetto說。所以，MySpace甘冒丟失2分鐘到2小時內(nèi)任意點數(shù)據(jù)的危險，在SQL Server配置里延長了“checkpoint”操作——它將待更新數(shù)據(jù)永久記錄到磁盤——的間隔時間，因為這樣做可以加快數(shù)據(jù)庫的運行。
Benedetto說，同樣，開發(fā)人員還經(jīng)常在幾個小時內(nèi)就完成構(gòu)思、編碼、測試和發(fā)布全過程。這有引入Bug的風險，但這樣做可以更快實現(xiàn)新功能。而 且，因為進行大規(guī)模真實測試不具可行性，他們的測試通常是在僅以部分活躍用戶為對象，且用戶對軟件新功能和改進不知就里的情況下進行的。因為事實上不可能 做真實的加載測試，他們做的測試通常都是針對站點。
“我們犯過大量錯誤，”Benedetto說，“但到頭來，我認為我們做對的還是比做錯的多。”

關 于MySpace是否使用了3Par的SAN，并且起到多大的關鍵作用，我也無法考證，也許可以通過在MySpace工作的朋友可以了解到，但是從各種數(shù) 據(jù)和一些案例來看，3Par的確可以改善成本過高和存儲I/O性能問題，但是實際應用中，除非電信、銀行或者真的類似MySpace這樣規(guī)模的站點，的確 很少遇到存儲連SAN都無法滿足的情況，另外，對于數(shù)據(jù)庫方面，據(jù)我知道，凡電信、金融和互聯(lián)網(wǎng)上電子商務關鍵數(shù)據(jù)應用，基本上Oracle才是最終的解 決方案。 包括我曾經(jīng)工作的Yahoo，他們?nèi)虺^70%以上應用使用MySQL，但是和錢相關的或者丟失數(shù)據(jù)會承擔責任的應用，都是使用Oracle。在UDB 方面，我相信Yahoo的用戶數(shù)一定超過MySpace的幾千萬。

事實上，國內(nèi)最值得研究的案例應該是騰訊，騰訊目前的數(shù)據(jù)量一定是驚人的，在和周小旻的一次短暫對話中知道騰訊的架構(gòu)專家自己實現(xiàn)了大部分的技術(shù)，細節(jié)我無法得知。

早晨，其實已經(jīng)是上午，起床后，
看到您凌晨3：23的回復，非常感動。
一定注意身體。
好像您還沒有太太，
太太和孩子也像正規(guī)程序一樣，會良好地調(diào)節(jié)您的身體。
千萬不要使用野程序調(diào)節(jié)身體，會中毒。

開個玩笑。

zhang on April 16, 2007 at 8:59 am said:

看到您凌晨3：23的回復，
非常感動！
一定注意身體，
好像您還沒有太太，
太太和孩子就像正…

哈哈，最近我是有點瘋狂，不過從大學開始，似乎就習慣了晚睡，我基本多年都保持2點左右睡覺，8點左右起床，昨晚有點夸張，因為看一個文檔和寫一些東西一口氣就到3點多了，臨睡前看到您的留言，順便就回復了。

看ㄋ你的文章，很有感覺的說．我自己也做網(wǎng)站，希望可以多多交流一下，大家保持聯(lián)繫．
http://www.gameon9.com/
http://www.gameon9.com.tw/

抽空兒回這里瀏覽了一下，
有收獲，
“寫真照”換了，顯得更帥了。
ok

很好，雖然我不是做web的，但看了還是收益良多。

回復:說說大型高并發(fā)高負載網(wǎng)站的系統(tǒng)架構(gòu) …

好文章!學習中………….

拜讀

[...] 來源：http://www.toplee.com/blog/archives/71.html 時間：11:40 下午 | 分類：技術(shù)文摘 標簽：系統(tǒng)架構(gòu), 大型網(wǎng)站, 性能優(yōu)化 [...]

都可以，寫到配置文件里面就可以，或者用全局變量定義，方法很多也都能實現(xiàn)，哪怕寫死了在開發(fā)的時候把本地調(diào)試也都配好圖片server，在hosts文件里面指定一下ip到本地就可以了。

假設用最終執(zhí)行時候的替換，就配置你的apache或者別的server上的mod_rewrite模塊來實現(xiàn)，具體的參照相關文檔。

不是，只轉(zhuǎn)換用戶請求，對url進行rewrite，進行重定向到新的url上，規(guī)則很靈活，建議仔細看看lighttpd或者apache的mod_rewrite文檔，當然IIS也有類似的模塊。

請教樓主：
我正在搞一個醫(yī)學教育視頻資源在線預覽的網(wǎng)站，只提供幾分鐘的視頻預覽，用swf格式，會員收看預覽后線下可購買DVD光碟。
系統(tǒng)架構(gòu)打算使用三臺服務器：網(wǎng)頁服務器、數(shù)據(jù)庫服務器、視頻服務器。
網(wǎng)頁使用全部靜態(tài)，數(shù)據(jù)庫用SQL Server 2000，CMS是用ASP開發(fā)的。
會員數(shù)按十萬級設計，不使用庫表散列技術(shù)，請樓主給個建議，看看我的方案可行不？

看了樓主的文章及各位大師的討論,感到受益非淺!真希望自己有機會親自接觸一下這樣的大型服務系統(tǒng)。希望樓主多寫些好文章！

看了大型網(wǎng)站的架夠,很想了解關于大型網(wǎng)絡架夠的防DDOS處理是怎么搞的,剛建了個小站,經(jīng)常被攻擊,導致用戶嚴重流失,已經(jīng)快關了,所以希望,能對DDOS的攻擊處理方法提供一些詳細的方案!

Frank Wang on August 17, 2007 at 9:12 am said:

Hi Michael,

I’m developing my own eCommerce pro…

客氣了，歡迎常來交流。

Mr.Happy on September 13, 2007 at 10:59 am said:

Michael大蝦，我是一個Web方面的小菜鳥，目前工作是負責開發(fā)和維護公司的實時系統(tǒng)，不過一直對網(wǎng)…

最近幾天公司事情實在太多，每天都工作到凌晨兩三點，blog也少了，剛看到你的留言，歡迎和我交流，在blog里面有我的聯(lián)系方式，包括QQ。

周末或者晚上11點以后我時間會稍微多一點，其他時間估計都很難有足夠的時間聊天，請多多包涵和理解

我們在做web server的cache的時候使用tangosol coherence.

講的都是最普通的，沒有什么特別之處

非常不多，雖然不是很詳細。但是至少能給與像我這樣還在黑暗中摸索的人給了一個探索的方向。
不知道能不能給幾個機會討論一下。我是從事。net方向的。

非常不錯， 唯一的不足就是還是比較粗。 更細一些更好

還有很多問題 希望能得到解答： 如果更好的控制權(quán)限。 我們知道靜態(tài)頁面的好處是 快，而沒有動態(tài)語言加載在里面 我們對文件控制就成了問題。 好比 假設我們有一個圖庫網(wǎng)站。 我們?nèi)绾慰刂撇煌脩舻臋?quán)限？ 如果在用戶可能猜出所有圖片編碼規(guī)則的前提下，很難控制。

用戶數(shù)目的繼續(xù)增加 如何管理數(shù)據(jù)庫，它的 讀取 鎖定，如何保持高效。 前提是 數(shù)據(jù)庫已經(jīng)分散到了多個。 他們之間如何建立更強的邏輯的結(jié)構(gòu)？和臟數(shù)據(jù)的問題？

您好，看了您的文章，受益匪淺
我現(xiàn)在在開發(fā)一個php的社區(qū)程序，關于是否應該使用靜態(tài)生成的問題，我曾經(jīng)問過一些人，他們的答案大多認為這樣做是不劃算的。論壇程序是頻繁更新的，在 每次回復都需要再次生成靜態(tài)，生成靜態(tài)本身是有開銷的。這之間的權(quán)衡一直困擾著我。我想問您，如果10個瀏覽著中創(chuàng)造一個回復，那么我生成靜態(tài)是否劃算 呢？

確實啊，使用靜態(tài)對于日后的管理會造成麻煩。
您的意思是推薦使用smarty等模板引擎的緩存功能來降低數(shù)據(jù)庫的查詢嗎？

luojing on October 2, 2007 at 9:41 pm said:

確實啊，使用靜態(tài)對于日后的管理會造成麻煩。
您的意思是推薦使用smarty等模板引擎的緩存功能來降…

建議結(jié)合APC、Xcache之類的PHP緩存技術(shù)提高PHP處理性能，然后結(jié)合類似Discuz的文件緩存進一步提高性能（也可以使用一些開源的 文件緩存代碼），最后還可以參照Vbb的使用Memcached內(nèi)存緩存的方法提高性能，在上述優(yōu)化基礎上，合理結(jié)合Smarty的緩存對一些靜態(tài)塊進行 緩存（事實也是文件緩存），這樣基本上就能處理大型應用了。

（入門級問題）請問要實現(xiàn)圖片服務器的架構(gòu)，在具體程序中應該怎么做？包括文件服務器。
Baidu、Google上都不好搜。
期待樓主告知相關的一些文章或網(wǎng)站的鏈接：）

對于PHP的模板IO性能提高，可以通過Xcache、APC這樣的PHP擴展模塊來實現(xiàn)，比別的方式效果都要好。

一套程序?qū)嗵啄０搴惋L格，這樣的應用其實很多，比如blog、bbs之類的，還有一些網(wǎng)站的個人空間都是這樣的策略，也沒有什么特別需要注意 的，這樣的網(wǎng)站最大的問題就是可能要注意設計一個合理的底層架構(gòu)，比如用戶系統(tǒng)、cookie使用、子域名等方面都要考慮合理。更多的問題就需要落實到細 節(jié)的時候才能針對性的來說。

[...] By Michael 轉(zhuǎn)載請保留出處：俊麟 Michael’s blog (http://www.toplee.com/blog/?p=71) Trackback Url : [...]

我有兩臺服務器，一臺web,一臺image
而且圖片有60w張之多（接近20G）
如果我要在web上傳圖片，在image瀏覽圖片
該怎么做？

我想在images服務器上使用squid作加速緩存，圖片地址都使用images服務器的，圖片上傳到web后，訪問時再緩存到images上。

好久沒有看到這么好我文章和這么經(jīng)典的回復，最近也在做一電子商務平臺的架構(gòu)，受益非淺。
這篇文章使我對大型網(wǎng)站的架構(gòu)肅然起勁。
謝謝Michael，我會一直關注你的Blog。

首先感謝博主有這么好的帖

我有點困惑：smarty是不是很好呢？最近在搞個政府類的門戶網(wǎng)站，目前是將各類服務分開的：2臺WEB、1臺數(shù)據(jù)庫、1臺文件(含一些上傳的 image)+后臺管理，采用的是php+html混排方式，目前速度并不是很理想，這也許和我配置的Linux服務器有關，呵呵，我配Linux還不是 拿手。
我想將程序采用smarty編寫，不知道和純靜態(tài)有什么好處。

朋友,很開心你守侯在這樣一個技術(shù)和心靈家園,我會支持你的,希望我們可以多交流.

我擅長應用服務器的開發(fā),目前對于web網(wǎng)站的架構(gòu)正在積極探索和研究,因為我有個不錯的idea,我跟你差不多,也工作了將近7年了,也沒混出來 什么名堂,期間也創(chuàng)過一次業(yè),以失敗告終,目前在上海一家證券軟件的公司做應用服務器的架構(gòu)與開發(fā).我的msn是 hook_ghy@hotmail.com,我會加你的.

嘿 嘿，不錯，說的還是比較全。不過貌似缺乏一定的條理。圖片服務器的分離存儲被單獨作為一大條了。個人感覺這只是根據(jù)文件類型分離存儲的一部分，目的是為了 減少瀏覽器和服務器的請求交互時間—這點上還有很多可以做的，比如合理安排 html 結(jié)構(gòu)，讓瀏覽器優(yōu)先載入部分資源以盡快把頁面顯示給用戶—這方面相關的東西 Oreilly 出了一本叫 High Performance Web Sites 上說的比較多。

另外，Cache 那塊似乎缺點什么，尤其是內(nèi)存 Cache ，可以蔓延到數(shù)據(jù)庫、靜態(tài)頁面甚至說的圖片等其他靜態(tài)文件，甚至 xcache 等一般是把動態(tài)程序編譯(加速一次)后 Cache 到內(nèi)存(再次加速)里。

有些東西好象確實很難理清

Hick on December 31, 2007 at 4:11 pm said:

嘿嘿，不錯，說的還是比較全。不過貌似缺乏一定的條理。圖片服務器的分離存儲被單獨作為一大條了。個人感覺…

很多東西講到后面就會越說越細了.
最后被支枝蔓蔓纏住吧.
呵呵.其實架構(gòu)這方面
很多和程序有關
只是純從物理結(jié)構(gòu)以及服務器結(jié)構(gòu)來說.沒有程序配合還是不行的.
比如數(shù)據(jù)庫分片.或者數(shù)據(jù)庫讀寫分離等等.
甚至上傳圖片的路徑和存放方式
都是程序端的東西.
很多時候.SA對這塊東西挺無奈.而網(wǎng)站程序可能對一些系統(tǒng)性的東西又不是很了解.例如圖片什么方法存儲系統(tǒng)會響應的更好一些.
所以一個好的SA必然需要會編程.而且要善于調(diào)試程序.理解系統(tǒng)瓶頸.
誰說SA會比程序員輕松的.呵呵

大哥，多來點這類文章吧

我感覺查詢是不是很消耗網(wǎng)站服務器的資源？

[quote]我感覺查詢是不是很消耗網(wǎng)站服務器的資源？[/quote]
不同的網(wǎng)站有不同類型的瓶頸
例如交易型網(wǎng)站,則插入數(shù)據(jù)可能會是瓶頸.因為需要做事務來保證操作的不可分割性.
對于其他絕大多數(shù)類網(wǎng)站,查詢一般來說是最消耗數(shù)據(jù)庫服務器資源的操作.
至于網(wǎng)頁服務器.則需要根據(jù)流量分析來判斷了.因為即便有一塊程序效率十分低下.但是調(diào)用次數(shù)非常少的話,也不會成為整體網(wǎng)站的瓶頸.
而只有10來句的語句,如果每個頁面都要調(diào)用,也會成為整個網(wǎng)站的瓶頸.

最近一直對大型網(wǎng)站的架構(gòu)感興趣，無意之中搜到博主的文章，受益匪淺，謝謝～

High Performance Web Sites
博文視點應該已經(jīng)開始翻譯了.
是YAHOO的WEB PERFOEMEANCE團隊的LEADER寫的
很棒的一本書.
從頁面設計一直講到系統(tǒng)構(gòu)架.

搞本英文影印版的來…:D

光影傳說 on March 27, 2008 at 3:51 pm said:

樓主，向您請教個問題。
我是用.net做的CS業(yè)務應用軟件，也遇到了伸縮性和并發(fā)性的類似問題。
…

昨晚在QQ上和您交流過了，半個老鄉(xiāng)

今后保持聯(lián)絡，相互學習。

從兩年前看到現(xiàn)在，用了一下午時間，不過這時間花的值，感謝樓主的奉獻，再次感謝，這個我已經(jīng)做下了記號。

Michael大大實在太好人了，百忙當中都可以抽時間詳細回復我的問題，狂贊！o(∩_∩)o…

受益匪淺啊`:) 謝謝樓主分享,也希望樓主能有更多關于高并發(fā),高訪問量的的解決心得發(fā)布:,期待

[...] 說說大型高并發(fā)高負載網(wǎng)站的系統(tǒng)架構(gòu)（更新） - 24,997 views [...]

Robert wrote related post…

Silk posts and stories…

zifa on June 15, 2008 at 7:41 pm said:

想問下多大并發(fā)才算是高負載 像6.cn這樣的站最大并發(fā)多少

可以從alexa上得到一個網(wǎng)站一天的pv數(shù)量，然后再一除就大概知道并發(fā)多少了。
視頻網(wǎng)站和傳統(tǒng)的網(wǎng)站pv還有較大差別，比如新浪的一個pv就是看一個頁面或者新聞，但是視頻網(wǎng)站一個pv可能是幾十分鐘的一個片子。

Pollux on June 17, 2008 at 5:02 pm said:

Blog主您好，看了您的文章有一些問題想要請教一下，首先是目前我這邊的情況，前端負載均衡使用nets…

1. 大量并發(fā)導致寫文件失敗是很常見的情況，基本上也很難避免，減小并發(fā)寫操作是追求的目標，這要從產(chǎn)品層面來考慮。
2. 從你的信息來看，你目前的架構(gòu)是因為按照id分組的文件太多導致，不過我沒有理解，既然是squid，為什么后端需要那么多的web服務器？ 理論上 Load balance->squids->web servers 就ok了，這方面我估計需要了解你的細節(jié)。
3. netscale我沒有用過，也是第一次聽說，不過從你現(xiàn)在的情況來看，我建議使用別的7層交換設備或者軟件來替換，這樣可以根據(jù)你描述的文件的id來進 行劃分到不同的squid群，當然，如果繼續(xù)使用netscale，由于大部分是靜態(tài)頁面，還是建議最小連接數(shù)的策略更高效。

xiaodouban on June 18, 2008 at 11:24 am said:

M總，領教了

嘿嘿，你手好了嗎？ 好久沒來打球了，周末過來一起玩兒吧。

好像你又開始折騰新東西了，小豆瓣 是新搞的嗎？

Pollux on June 18, 2008 at 1:51 pm said:

感謝Michael深夜回復，還是要多多注意身體啊。關于我的第2個問題，目前是這樣子的，因為netsc…

多臺squid指向同一個web服務器，這是通常的做法，訪問量大是增加squid，而不是增加web服務器，你嘗試這樣調(diào)整一下。

Pollux on June 20, 2008 at 10:11 pm said:

采購squid服務器的預算被槍斃了，主要是要實現(xiàn)squid服務器和web服務器1對1增加的服務器不在…

這兩天我的服務器硬盤有一塊出錯，昨晚剛恢復，沒及時回復，抱歉。

如果你們的技術(shù)架構(gòu)是你負責，你就應該要堅持你的觀點，通常來說，web服務器一般都是部署在某個核心機房，各地的squid群起到負載均衡的作 用，從這個角度來說，如果各地的點比較多，squid必然會比web服務器多很多，這是常規(guī)的做法，如果你要想讓web服務器也分布太多點，這樣架構(gòu)會很 復雜，沒有太成熟的做法。

假如你的站點主要集中在一個點上，那你說的那種比例沒有什么問題。

另外，你們的并發(fā)連接那個數(shù)量級，其實很小，因為你的內(nèi)容主要還是靜態(tài)的，雖然有動態(tài)的部分，實際上，動態(tài)的內(nèi)容，有些情況下還是可以緩存的，需要更細致的去挖掘。

從架構(gòu)上來說，有多少資源用多少資源也是原則，不能為了追求架構(gòu)而不考慮投入也是不可取的，你目前的情況來看，代碼、服務器本身的配置優(yōu)化看來應該有空間可改進，這個需要根據(jù)你具體的產(chǎn)品和代碼來判斷了。

有關數(shù)據(jù)庫的緩存，又回到我文章里面談的一些觀點了，大概就是這些方法，萬變不離其宗。