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

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

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

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

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

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

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

希望有空跟你學習請教網站負載問題。

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

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

恩，多謝Michael的耐心講解

Very good site. Thanks for author!

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

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

先問一下關于圖…

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

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

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

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

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

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

不客氣，歡迎常交流！

回復fanstone：

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

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

在網站發展規劃基礎上，考慮今后要提供什么樣的應用？有些什么樣的域名關系？各個應用之間的業務邏輯和關聯是什么？面對什么地域分布的用戶提供服務？等等。。。

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

總的來說，不結合具體業務的技術規劃是沒有意義的，所以首先是業務規劃，也就是產品設計，然后才是技術規劃。

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

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

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

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

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

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

希望能回答了您的問題。

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

再次感謝。

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

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

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

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

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

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

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

億萬用戶網站MySpace的成功秘密

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

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

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

Benedetto說他的項目組有很多教訓必須總結，他們仍在學習，路漫漫而修遠。他們當前需要改進的工作包括實現更靈活的數據緩存系統，以及為避免再次出現類似7月癱瘓事件的地理上分布式架構。

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

MySpace的站點架構已經歷了5個版本——每次都是用戶數達到一個里程碑后，必須做大量的調整和優化。Benedetto說，“但我們始終跟不上形勢的發展速度。我們重構重構再重構，一步步挪到今天”。

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

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

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

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

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

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

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

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

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

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

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

開個玩笑。

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

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

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

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

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

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

回復:說說大型高并發高負載網站的系統架構 …

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

拜讀

[...] 來源：http://www.toplee.com/blog/archives/71.html 時間：11:40 下午 | 分類：技術文摘 標簽：系統架構, 大型網站, 性能優化 [...]

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

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

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

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

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

看了大型網站的架夠,很想了解關于大型網絡架夠的防DDOS處理是怎么搞的,剛建了個小站,經常被攻擊,導致用戶嚴重流失,已經快關了,所以希望,能對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方面的小菜鳥，目前工作是負責開發和維護公司的實時系統，不過一直對網…

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

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

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

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

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

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

還有很多問題 希望能得到解答： 如果更好的控制權限。 我們知道靜態頁面的好處是 快，而沒有動態語言加載在里面 我們對文件控制就成了問題。 好比 假設我們有一個圖庫網站。 我們如何控制不同用戶的權限？ 如果在用戶可能猜出所有圖片編碼規則的前提下，很難控制。

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

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

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

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

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

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

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

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

一套程序對應多套模板和風格，這樣的應用其實很多，比如blog、bbs之類的，還有一些網站的個人空間都是這樣的策略，也沒有什么特別需要注意 的，這樣的網站最大的問題就是可能要注意設計一個合理的底層架構，比如用戶系統、cookie使用、子域名等方面都要考慮合理。更多的問題就需要落實到細 節的時候才能針對性的來說。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大哥，多來點這類文章吧

我感覺查詢是不是很消耗網站服務器的資源？

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

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

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

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

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

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

昨晚在QQ上和您交流過了，半個老鄉

今后保持聯絡，相互學習。

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

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

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

[...] 說說大型高并發高負載網站的系統架構（更新） - 24,997 views [...]

Robert wrote related post…

Silk posts and stories…

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

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

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

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

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

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

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服務器，你嘗試這樣調整一下。

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

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

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

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

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

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

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

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