說說大型高併發高負載網站的系統架構
轉載請保留出處：俊麟 Michael’s blog (http://www.toplee.com/blog/?p=71)
Trackback Url : http://www.toplee.com/blog/wp-trackback.php?p=71
我在CERNET做過撥號接入平臺的搭建，而後在Yahoo&3721從事過搜索引擎前端開發，又在MOP處理過大型社區貓撲大雜燴的 架構升級等工作，同時自己接觸和開發過不少大中型網站的模塊，因此在大型網站應對高負載和併發的解決方案上有一些積累和經驗，可以和大家一起探討一下。
一個小型的網站，比如個人網站，可以使用最簡單的html靜態頁面就實現了，配合一些圖片達到美化效果，所有的頁面均存放在一個目錄下，這樣的網站對 系統架構、性能的要求都很簡單，隨着互聯網業務的不斷豐富，網站相關的技術經過這些年的發展，已經細分到很細的方方面面，尤其對於大型網站來說，所採用的 技術更是涉及面非常廣，從硬件到軟件、編程語言、數據庫、WebServer、防火牆等各個領域都有了很高的要求，已經不是原來簡單的html靜態網站所 能比擬的。
大型網站，比如門戶網站。在面對大量用戶訪問、高併發請求方面，基本的解決方案集中在這樣幾個環節：使用高性能的服務器、高性能的數據庫、高效率的編程語言、還有高性能的Web容器。但是除了這幾個方面，還沒法根本解決大型網站面臨的高負載和高併發問題。
上面提供的幾個解決思路在一定程度上也意味着更大的投入，並且這樣的解決思路具備瓶頸，沒有很好的擴展性，下面我從低成本、高性能和高擴張性的角度來說說我的一些經驗。
1、HTML靜態化
其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們儘可能使我們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也 是最有效的方法。但是對於大量內容並且頻繁更新的網站，我們無法全部手動去挨個實現，於是出現了我們常見的信息發佈系統CMS，像我們常訪問的各個門戶站 點的新聞頻道，甚至他們的其他頻道，都是通過信息發佈系統來管理和實現的，信息發佈系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、權 限管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
除了門戶和信息發佈類型的網站，對於交互性要求很高的社區類型網站來說，儘可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時 的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。目前很多博客也都實現了靜態化，我 使用的這個Blog程序WordPress還沒有靜態化，所以如果面對高負載訪問，www.toplee.com一定不能承受 
同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用數據庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現， 比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行後臺管理並且存儲再數據庫中，這些信息其實大量被前臺程序調用，但是更新頻率很小，可以 考慮將這部分內容進行後臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。
在進行html靜態化的時候可以使用一種折中的方法，就是前端使用動態實現，在一定的策略下進行定時靜態化和定時判斷調用，這個能實現很多靈活性的操作，我開發的檯球網站故人居(www.8zone.cn)就是使用了這樣的方法，我通過設定一些html靜態化的時間間隔來對動態網站內容進行緩存，達到分擔大部分的壓力到靜態頁面上，可以應用於中小型網站的架構上。故人居網站的地址：http://www.8zone.cn，順便提一下，有喜歡檯球的朋友多多支持我這個免費網站:)
2、圖片服務器分離
大家知道，對於Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是我們有必要將圖片與頁面進行分離，這是基本上大 型網站都會採用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統壓力，並且可以保證系統不會因 爲圖片問題而崩潰。
在應用服務器和圖片服務器上，可以進行不同的配置優化，比如Apache在配置ContentType的時候可以儘量少支持，儘可能少的LoadModule，保證更高的系統消耗和執行效率。
我的檯球網站故人居8zone.cn也使用了圖片服務器架構上的分離，目前是僅僅是架構上分離，物理上沒有分離，由於沒有錢買更多的服務器:)，大家可以看到故人居上的圖片連接都是類似img.9tmd.com或者img1.9tmd.com的URL。
另外，在處理靜態頁面或者圖片、js等訪問方面，可以考慮使用lighttpd代替Apache，它提供了更輕量級和更高效的處理能力。
3、數據庫集羣和庫表散列
大型網站都有複雜的應用，這些應用必須使用數據庫，那麼在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快無法滿足應用，於是我們需要使用數據庫集羣或者庫表散列。
在數據庫集羣方面，很多數據庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施即可。
上面提到的數據庫集羣由於在架構、成本、擴張性方面都會受到所採用DB類型的限制，於是我們需要從應用程序的角度來考慮改善系統架構，庫表散列 是常用並且最有效的解決方案。我們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不同的模塊對應不同的數據庫或者表，再按照一定的策略對某個 頁面或者功能進行更小的數據庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能並且有很好的擴展性。sohu的論壇就是採用 了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，然後對帖子、用戶按照板塊和ID進行散列數據庫和表，最終可以在配置文件中進行簡單的配置 便能讓系統隨時增加一臺低成本的數據庫進來補充系統性能。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這裏先講述最基本的兩種緩存。高級和分佈式的緩存在後面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的mod_proxy緩存模塊，也可以使用外加的Squid進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，Linux上提供的Memcached是常用的緩存方案，不少web編程語言都提供memcache訪問接口，php、perl、c和java都有，可以在web開發中使用，可以實時或者Cron的把數據、對象等內容進行緩存，策略非常靈活。一些大型社區使用了這樣的架構。
另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊和eAccelerator加速和Cache模塊，還要知名的Apc、XCache（國人開發的，支持！）php緩存模塊，Java就更多了，.net不是很熟悉，相信也肯定有。
5、鏡像
鏡像是大型網站常採用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網絡接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和 EduNet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這裏不闡述太深，有很多專業的現 成的解決架構和產品可選。也有廉價的通過軟件實現的思路，比如Linux上的rsync等工具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。另外有關初級的負載均衡DNS輪循和較專業的CDN架構就不多說了。
6.1 硬件四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。 第四層交換功能就 象是虛IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理服務器基礎上，需要 複雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共 同決定。
在硬件四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。
6.2 軟件四層交換
大家知道了硬件四層交換機的原理後，基於OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是遊刃有餘的，有人說軟件實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿 足多種應用需求，這對於分佈式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣，這種思路在很多大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討。
總結：
對於大型網站來說，前面提到的每個方法可能都會被同時使用到，Michael這裏介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會， 有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大，希望大家一起討論，達到拋磚引玉之效。
轉載請保留出處：俊麟 Michael’s blog (http://www.toplee.com/blog/?p=71)
Trackback Url : http://www.toplee.com/blog/wp-trackback.php?p=71
(2 votes, average: 6.5 out of 10)
Loading ...寫得好！現在，網上像這樣的文章不多，看完受益匪淺
完全胡說八道!
“大家知道，對於Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的”,你以爲是在內存中動態生成圖片啊.無論是什麼文件,在容器輸出時只是讀文件,輸出給response而已,和是什麼文件有什麼關係.
關鍵是靜態文件和動態頁面之間應該採用不同策略,如靜態文件應該儘量緩存,因爲無論你請求多少次輸出內容都是相同的,如果用戶頁面中有二十個就沒有必要請求二十次,而應該使用緩存.而動態頁面每次請求輸出都不相同(否則就應該是靜態的),所以不應該緩存.
所以即使在同一服務器上也可以對靜態和動態資源做不同優化,專門的圖片服務器那是爲了資源管理的方便,和你說的性能沒有關係.
動 態的緩存案例估計樓上朋友沒有遇到過，在處理inktomi的搜索結果的案例中，我們使用的全部是面對動態的緩存，對於同樣的關鍵詞和查詢條件來說，這樣 的緩存是非常重要的，對於動態的內容緩存，編程時使用合理的header參數可以方便的管理緩存的策略，比如失效時間等。
我們說到有關圖片影響性能的問題，一般來說都是出自於我們的大部分訪問頁面中圖片往往比html代碼佔用的流量大，在同等網絡帶寬的情況下，圖片傳 輸需要的時間更長，由於傳輸需要花很大開銷在建立連接上，這會延長用戶client端與server端的http連接時長，這對於apache來說，併發 性能肯定會下降，除非你的返回全部是靜態的，那就可以把 httpd.conf 中的 KeepAlives 爲 off ，這樣可以減小連接處理時間，但是如果圖片過多會導致建立的連接次數增多，同樣消耗性能。
另外我們提到的理論更多的是針對大型集羣的案例，在這樣的環境下，圖片的分離能有效的改進架構，進而影響到性能的提升，要知道我們爲什麼要談架構？架構可能爲了安全、爲了資源分配、也爲了更科學的開發和管理，但是終極目都是爲了性能。
另外在RFC1945的HTTP協議文檔中很容易找到有關Mime Type和Content length部分的說明，這樣對於理解圖片對性能影響是很容易的。
樓上的朋友完全是小人作爲，希望別用guest跟我忽悠，男人還害怕別人知道你叫啥？再說了，就算說錯了也不至於用胡說八道來找茬！大家重在交流和學習，我也不是什麼高人，頂多算個普通程序員而已。
Michael 您好，這篇文章我看幾次了，有一個問題，您的文章中提到了如下一段：
“對於交互性要求很高的社區類型網站來說，儘可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。”
對於大型的站點來說，他的數據庫和 Web Server 一般都是分佈式的，在多個區域都有部署，當某個地區的用戶訪問時會對應到一個節點上，如果是對社區內的帖子實時靜態化，有更新時再重新靜態化，那麼在節點 之間如何立刻同步呢？數據庫端如何實現呢？如果用戶看不到的話會以爲發帖失敗？造成重複發了，那麼如何將用戶鎖定在一個節點上呢，這些怎麼解決？謝謝。
對於將一個用戶鎖定在某個節點上是通過四層交換來實現的，一般情況下是這樣，如果應用比較小的可以通過程序代碼來實現。大型的應用一般通過類似LVS和硬件四層交換來管理用戶連接，可以制定策略來使用戶的連接在生命期內保持在某個節點上。
靜態化和同步的策略比較多，一般採用的方法是集中或者分佈存儲，但是靜態化卻是通過集中存儲來實現的，然後使用前端的proxy羣來實現緩存和分擔壓力。
希望有空跟你學習請教網站負載問題。
Great website! Bookmarked! I am impressed at your work!
一般對於一箇中型網站來說，交互操作非常多，日PV百萬左右，如何做合理的負載？
heiyeluren on June 21, 2006 at 10:39 am said:
一般對於一箇中型網站來說，交互操作非常多，日PV百萬左右，如何做合理的負載？
交互如果非常多，可以考慮使用集羣加Memory Cache的方式，把不斷變化而且需要同步的數據放入Memory Cache裏面進行讀取，具體的方案還得需要結合具體的情況來分析。
請問，如果一個網站處於技術發展期，那麼這些優化手段應該先實施哪些後實施哪些呢？
或者說從成本（技術、人力和財力成本）方面，哪些先實施能夠取得最大效果呢？
donald on June 27, 2006 at 5:39 pm said:
請問，如果一個網站處於技術發展期，那麼這些優化手段應該先實施哪些後實施哪些呢？
或者說從成本（技術、人力和財力成本）方面，哪些先實施能夠取得最大效果呢？
先從服務器性能優化、代碼性能優化方面入手，包括webserver、dbserver的優化配置、html靜態化等容易入手的開始，這些環節爭取 先榨取到最大化的利用率，然後再考慮從架構上增加投入，比如集羣、負載均衡等方面，這些都需要在有一定的發展積累之後再做考慮比較恰當。
恩，多謝Michael的耐心講解
寫得好,爲人也不錯.
Very good site. Thanks for author!
贊一個先，是一篇很不錯的文章，不過要真正掌握裏面的東西恐怕還是需要時間和實踐！
先問一下關於圖片服務器的問題了！
我的檯球網站故人居9tmd.com也使用了圖片服務器架構上的分離，目前是僅僅是架構上分離，物理上沒有分離，由於沒有錢買更多的服務器:)，大家可以看到故人居上的圖片連接都是類似img.9tmd.com或者img1.9tmd.com的URL。
這個，樓主這個img.9tmd.com是虛擬主機吧，也就是說是一個apache提供的服務吧，這樣的話對於性能的提高也很有意義嗎？還是隻是鋪墊，爲了方便以後的物理分離呢？
echonow on September 1, 2006 at 2:28 pm said:
贊一個先，是一篇很不錯的文章，不過要真正掌握裏面的東西恐怕還是需要時間和實踐！
先問一下關於圖片服務器的問題了！
我的檯球網站故人居9tmd.com也使用了圖片服務器架構上的分離，目前是僅僅是架構上分離，物理上沒有分離，由於沒有錢買更多的服務器:)，大家可以看到故人居上的圖片連接都是類似img.9tmd.com或者img1.9tmd.com的URL。
這個，樓主這個img.9tmd.com是虛擬主機吧，也就是說是一個apache提供的服務吧，這樣的話對於性能的提高也很有意義嗎？還是隻是鋪墊，爲了方便以後的物理分離呢？
這位朋友說得很對，因爲目前只有一臺服務器，所以從物理上無法實現真正的分離，暫時使用虛擬主機來實現，是爲了程序設計和網站架構上的靈活，如果有 了一臺新的服務器，我只需要把圖片鏡像過去或者同步過去，然後把img.9tmd.com的dns解析到新的服務器上就自然實現了分離，如果現在不從架構 和程序上實現，今後這樣的分離就會比較痛苦:)
謝謝lz的回覆，現在主要實現問題是如何能在素材上傳時直接傳到圖片服務器上呢，總不至於每次先傳到web，然後再同步到圖片服務器吧
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:
多謝樓主的耐心指導，我先研究下，用共享區來存儲確實是個不錯的想法!
不客氣，歡迎常交流！
Michael，謝謝你的好文章。仔細看了，包括回覆，受益匪淺。
donald on June 27, 2006 at 5:39 pm said:
請問，如果一個網站處於技術發展期，那麼這些優化手段應該先實施哪些後實施哪些呢？
或者說從成本（技術、人力和財力成本）方面，哪些先實施能夠取得最大效果呢？
先從服務器性能優化、代碼性能優化方面入手，包括webserver、dbserver的優化配置、html靜態化等容易入手的開始，這些環節爭取 先榨取到最大化的利用率，然後再考慮從架構上增加投入，比如集羣、負載均衡等方面，這些都需要在有一定的發展積累之後再做考慮比較恰當。
尤其這個部分很是有用，因爲我也正在建一個電子商務類的網站，由於是前期階段，費用的問題畢竟有所影響，所以暫且只用了一臺服務器囊括過了整個網站。除去 前面所說的圖片服務器分離，還有什麼辦法能在網站建設初期儘可能的爲後期的發展做好優化（性能優化，系統合理構架，前面說的websever、 dbserver優化，後期譬如硬件等擴展儘可能不要過於煩瑣等等）？ 也就是所謂的未雨綢繆了，儘可能在先期考慮到後期如果發展壯大的需求，預先做好系統規劃，並且在前期資金不足的情況下儘量做到網站以最優異的性能在運行。關於達到這兩個要求，您可以給我一些稍稍詳細一點的建議和技術參考嗎？謝謝！
看了你的文章，知道你主要關注*nix系統架構的，我的是.net和win2003的，不過我覺得這個影響也不大。主要關注點放在外圍的網站優化上。
謝謝!希望能得到您的一些好建議。
回覆fanstone：
關於如何在網站的前期儘可能低成本的投入，做到性能最大化利用，同時做好後期系統架構的規劃，這個問題可以說已經放大到超出技術範疇，不過和技術相關的部分還是有不少需要考慮的。
一個網站的規劃關鍵的就是對階段性目標的規劃，比如預測幾個月後達到什麼用戶級別、存儲級別、併發請求數，然後再過幾個月又將什麼情況，這些預測必 須根據具體業務和市場情況來進行預估和不斷調整的，有了這些預測數據作爲參考，就能進行技術架構的規劃，否則技術上是無法合理進行架構設計的。
在網站發展規劃基礎上，考慮今後要提供什麼樣的應用？有些什麼樣的域名關係？各個應用之間的業務邏輯和關聯是什麼？面對什麼地域分佈的用戶提供服務？等等。。。
上面這些問題有助於規劃網站服務器和設備投入，同時從技術上可以及早預測到未來將會是一個什麼架構，在滿足這個架構下的每個節點將需要滿足什麼條件，就是初期架構的要求。
總的來說，不結合具體業務的技術規劃是沒有意義的，所以首先是業務規劃，也就是產品設計，然後纔是技術規劃。
謝謝解答，我再多看看！
很 好的文章，樓主說的方法非常適用，目前我們公司的網站也是按照樓主所說的方法進行設計的，效果比較好，利於以後的擴展，另外我再補充一點，其實樓主也說 了，網站的域名也需要提前考慮和規劃，比如網站的圖片內容比較多，可以按應用圖片的類型可以根據不同的業務需求採用不同的域名img1~imgN等，便於 日後的擴展和移至，希望樓主能夠多發一些這樣的好文章。
圖片服務器與主數據分離的問題。
圖片是存儲在硬盤裏好還是存儲在數據庫裏好？
請您分硬盤和數據庫兩種情況解釋下面的疑問。
當存放圖片的服務器容量不能滿足要求時如何辦？
當存放圖片的服務器負載不能滿足要求時如何辦？
謝謝。
zhang on April 3, 2007 at 9:08 am said:
圖片服務器與主數據分離的問題。
圖片是存儲在硬盤裏好還是存儲在數據庫裏好？
請您分硬盤和數據庫兩種情況解釋下面的疑問。
當存放圖片的服務器容量不能滿足要求時如何辦？
當存放圖片的服務器負載不能滿足要求時如何辦？
謝謝。
肯定是存儲在硬盤裏面，出現存儲在數據庫裏面的說法實際上是出自一些虛擬主機或者租用空間的個人網站和企業網站，因爲網站數據量小，也爲了備份方便，從大型商業網站來說，沒有圖片存儲在數據庫裏面的大型應用。數據庫容量和效率都會是極大的瓶頸。
你提到的後面兩個問題。容量和負載基本上是同時要考慮的問題，容量方面，大部分的解決方案都是使用海量存儲，比如專業的盤陣，入門級的磁盤櫃或者高 級的光纖盤陣、局域網盤陣等，這些都是主要的解決方案。記得我原來說過，如果是考慮低成本，一定要自己使用便宜單臺服務器來存儲，那就需要從程序邏輯上去 控制，比如你可以多臺同樣的服務器來存儲，分別提供NFS的分區給前端應用使用，在前端應用的程序邏輯中自己去控制存儲在哪一臺服務器的NFS分區上，比 如根據Userid或者圖片id、或者別的邏輯去進行散列，這個和我們規劃大型數據庫存儲散列分表或者分庫存儲的邏輯類似。
基本上圖片負載高的解決辦法有兩種，前端squid緩存和鏡像，通過對存儲設備（服務器或者盤陣）使用鏡像，可以分佈到多臺服務器上對外提供圖片服務，然後再配合squid緩存實現負載的降低和提高用戶訪問速度。
希望能回答了您的問題。
Roc on March 22, 2007 at 11:48 pm said:
很好的文章，樓主說的方法非常適用，目前我們公司的網站也是按照樓主所說的方法進行設計的，效果比較好，利於以後的擴展，另外我再補充一點，其實樓 主也說了，網站的域名也需要提前考慮和規劃，比如網站的圖片內容比較多，可以按應用圖片的類型可以根據不同的業務需求採用不同的域名img1~imgN 等，便於日後的擴展和移至，希望樓主能夠多發一些這樣的好文章。
歡迎常來交流，還希望能得到你的指點。大家相互學習。
非常感謝您的回覆，
希望將來有合作的機會。
再次感謝。
剛纔一位朋友把你的 BLOG 發給我看，問我是否認識你，所以我就仔細看了一下你的 BLOG，發現這篇文章。
很不錯的一篇文章，基本上一個大型網站需要做的事情都已經提及了。我自己也曾任職於三大門戶之一，管理超過 100 臺的 SQUID 服務器等，希望可以也分享一下我的經驗和看法。
1、圖片服務器分離
這個觀點是我一直以來都非常支持的。特別是如果程序與圖片都放在同一個 APAHCE 的服務器下，每一個圖片的請求都有可能導致一個 HTTPD 進程的調用，而 HTTPD 如果包含有 PHP 模塊的的時候，就會佔用過多的內存，而這個是沒有任何必要的。
使用獨立的圖片服務器不但可以避免以上這個情況，更可以對不同的使用性質的圖片設置不同的過期時間，以便同一個用戶在不同頁面訪問相同圖片時不會再次從服務器（基於是緩存服務器）取數據，不但止快速，而且還省了帶寬。還有就是，對於緩存的時間上，亦可以做調立的調節。
在我過往所管理的圖片服務器中，不但止是將圖片與應用及頁面中分離出來，還是爲不同性質的圖片啓用不同的域名。以緩解不同性質圖片帶來的壓力。例如 photo.img.domain.com 這個域名是爲了攝影服務的，平時使用 5 臺 CACHE，但到了 5.1 長假期後，就有可能需要獨立爲他增加至 10 臺。而增加的這 5 臺可以從其他負載較低的圖片服務器中調動過來臨時使用。
2、數據庫集羣
一套 ORACLE RAC 的集羣佈置大概在 40W 左右，這個價格對於一般公司來說，是沒有必要的。因爲 WEB 的應用邏輯相對較簡單，而 ORACLE 這些大型數據庫的價值在於數據挖掘，而不在於簡單的存儲。所以選擇 MySQL 或 PostgreSQL 會實際一些。
簡單的 MySQL 複製就可以實現較好的效果。讀的時候從 SLAVE 讀，寫的時候纔到 MASTER 上更新。實際的情況下，MySQL 的複製性能非常好，基本上不會帶來太高的更新延時。使用 balance （http://www.inlab.de/balance.html）這個軟件，在本地（127.0.0.1）監聽 3306 端口，再映射多個 SLAVE 數據庫，可以實現讀取的負載均衡。
3、圖片保存於磁盤還是數據庫？
對於這個問題，我亦有認真地考慮過。如果是在 ext3 的文件系統下，建 3W 個目錄就到極限了，而使用 xfs 的話就沒有這個限制。圖片的存儲，如果需要是大量的保存，必須要分隔成很多個小目錄，否則就會有 ext3 只能建 3W 目錄的限制，而且文件數及目錄數太多會影響磁盤性能。還沒有算上空間佔用浪費等問題。
更更重要的是，對於一個大量小文件的數據備份，要佔用極大的資源和非常長的時間。在這些問題前面，可能將圖片保存在數據庫是個另外的選擇。
可以嘗試將圖片保存到數據庫，前端用 PHP 程序返回實際的圖片，再在前端放置一個 SQUID 的服務器，可以避免性能問題。那麼圖片的備份問題，亦可以利用 MySQL 的數據複製機制來實現。這個問題就可以得到較好的解決了。
4、頁面的靜態化我就不說了，我自己做的 wordpress 就完全實現了靜態化，同時能很好地兼顧動態數據的生成。
5、緩存
我自己之前也提出過使用 memcached，但實際使用中不是非常特別的理想。當然，各個應用環境不一致會有不一致的使用結果，這個並不重要。只要自己覺得好用就用。
6、軟件四層交換
LVS 的性能非常好，我有朋友的網站使用了 LVS 來做負責均衡的調度器，數據量非常大都可以輕鬆支撐。當然是使用了 DR 的方式。
其實我自己還想過可以用 LVS 來做 CDN 的調度。例如北京的 BGP 機房接受用戶的請求，然後通過 LVS 的 TUN 方式，將請求調度到電信或網通機房的實際物理服務器上，直接向用戶返回數據。
這種是 WAN 的調度，F5 這些硬件設備也應用這樣的技術。不過使用 LVS 來實現費用就大大降低。
以上都只屬個人觀點，能力有限，希望對大家有幫助。 ：）
很少見到有朋友能在我得blog上留下這麼多有價值的東西，代表別的可能看到這篇文章的朋友一起感謝你。
balance （http://www.inlab.de/balance.html） 這個東西準備看一下。
如 果要說3Par的光纖存儲局域網技術細節，我無法給您太多解釋，我對他們的產品沒有接觸也沒有了解，不過從SAN的概念上是可以知道大概框架的，它也是一 種基於光纖通道的存儲局域網，可以支持遠距離傳輸和較高的系統擴展性，傳統的SAN使用專門的FC光通道SCSI磁盤陣列，從你提供的內容來看，3Par 這個東西建立在低成本的SATA或FATA磁盤陣列基礎上，這一方面能降低成本，同時估計3Par在技術上有創新和改進，從而提供了廉價的高性能存儲應 用。
這個東西細節只有他們自己知道，你就知道這是個商業的SAN （存儲局域網，說白了也是盤陣，只是通過光纖通道獨立於系統外的）。
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說，“但到頭來，我認爲我們做對的還是比做錯的多。”
瞭解聯合數據庫服務器
爲達到最大型網站所需的高性能級別，多層系統一般在多個服務器之間平衡每一層的處理負荷。SQL Server 2005 通過對 SQL Server 數據庫中的數據進行水平分區，在一組服務器之間分攤數據庫處理負荷。這些服務器獨立管理，但協作處理應用程序的數據庫請求；這樣一組協作服務器稱爲“聯合 體”。
只有在應用程序將每個 SQL 語句發送到包含該語句所需的大部分數據的成員服務器時，聯合數據庫層才能達到非常高的性能級別。這稱爲使用語句所需的數據來配置 SQL 語句。使用所需的數據來配置 SQL 語句不是聯合服務器所特有的要求。羣集系統也有此要求。
雖然服務器聯合體與單個數據庫服務器對應用程序來說是一樣的，但在實現數據庫服務層的方式上存在內部差異，
關 於MySpace是否使用了3Par的SAN，並且起到多大的關鍵作用，我也無法考證，也許可以通過在MySpace工作的朋友可以瞭解到，但是從各種數 據和一些案例來看，3Par的確可以改善成本過高和存儲I/O性能問題，但是實際應用中，除非電信、銀行或者真的類似MySpace這樣規模的站點，的確 很少遇到存儲連SAN都無法滿足的情況，另外，對於數據庫方面，據我知道，凡電信、金融和互聯網上電子商務關鍵數據應用，基本上Oracle纔是最終的解 決方案。 包括我曾經工作的Yahoo，他們全球超過70%以上應用使用MySQL，但是和錢相關的或者丟失數據會承擔責任的應用，都是使用Oracle。在UDB 方面，我相信Yahoo的用戶數一定超過MySpace的幾千萬。
事實上，國內最值得研究的案例應該是騰訊，騰訊目前的數據量一定是驚人的，在和周小旻的一次短暫對話中知道騰訊的架構專家自己實現了大部分的技術，細節我無法得知。
圖 片存儲到數據庫我依然不贊同，不過一定要這麼做也不是不可以，您提到的使用CGI程序輸出到用戶客戶端，基本上每種web編程語言都支持，只要能輸出標準 的HTTP Header信息就可以了，比如PHP可以使用 header(”content-type:image/jpeg/r/n”); 語句輸出當前http返回的文件mime類型爲圖片，同時還有更多的header()函數可以輸出的HTTP Header信息，包括 content-length 之類的（提供range 斷點續傳需要），具體的可以參考PHP的手冊。 另外，perl、asp、jsp這些都提供類似的實現方法，這不是語言問題，而是一個HTTP協議問題。
早晨，其實已經是上午，起牀後，
看到您凌晨3：23的回覆，非常感動。
一定注意身體。
好像您還沒有太太，
太太和孩子也像正規程序一樣，會良好地調節您的身體。
千萬不要使用野程序調節身體，會中毒。
開個玩笑。
看到您凌晨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/
關於兩位老大討論的：圖片保存於磁盤還是數據庫
個人覺得數據庫存文件的話，查詢速度可能快點，但數據量很大的時候要加上索引，這樣添加記錄的速度就慢了
mysql對大數據量的處理能力還不是很強，上千萬條記錄時，性能也會下降
數據庫另外一個瓶頸問題就是連接
用數據庫，就要調用後臺程序（JSP/JAVA,PHP等）連接數據庫，而數據庫的連接連接、傳輸數據都要耗費系統資源。數據庫的連接數也是個瓶頸問題。 曾經寫過一個很爛的程序，每秒訪問3到5次的數據庫，結果一天下來要連接20多萬次數據庫，把對方的mysql數據庫搞癱瘓了。
抽空兒回這裏瀏覽了一下，
有收穫，
“寫真照”換了，顯得更帥了。
ok
zhang on May 19, 2007 at 12:07 am said:
抽空兒回這裏瀏覽了一下，
有收穫，
“寫真照”換了，顯得更帥了。
ok
哈哈，讓您見笑了
很好，雖然我不是做web的，但看了還是收益良多。
感謝Michael
回覆:說說大型高併發高負載網站的系統架構 …
好文章!學習中………….
推薦nginx
拜讀
terry on June 15, 2007 at 4:29 pm said:
推薦nginx
歡迎分享Nginx方面的經驗:)
[…] 來源：http://www.toplee.com/blog/archives/71.html 時間：11:40 下午 | 分類：技術文摘 標籤：系統架構, 大型網站, 性能優化 […]
看到大家都推薦圖片分離，我也知道這樣很好，但頁面裏的圖片的絕對網址是開發的時候就寫進去的，還是最終執行的時候替換的呢？
如果是開發原始網頁就寫進去的，那本地調試的時候又是怎麼顯示的呢？
如果是最終執行的時候替換的話，是用的什麼方法呢？
都可以，寫到配置文件裏面就可以，或者用全局變量定義，方法很多也都能實現，哪怕寫死了在開發的時候把本地調試也都配好圖片server，在hosts文件裏面指定一下ip到本地就可以了。
假設用最終執行時候的替換，就配置你的apache或者別的server上的mod_rewrite模塊來實現，具體的參照相關文檔。
先謝謝博主的回覆，一直在找一種方便的方法將圖片分離。
看來是最終替換法比較靈活，但我知道mod_rewrite是用來將用戶提交的網址轉換成服務器上的真實網址。
看了博主的回覆好像它還有把網頁執行的結果進行替換後再返回給瀏覽器的功能，是這樣嗎？
不是，只轉換用戶請求，對url進行rewrite，進行重定向到新的url上，規則很靈活，建議仔細看看lighttpd或者apache的mod_rewrite文檔，當然IIS也有類似的模塊。
我知道了，如果要讓客戶瀏覽的網頁代碼裏的圖片地址是絕對地址，只能在開發時就寫死了(對於靜態頁面)或用變量替換(對於動態頁面更靈活些)，是這樣嗎？
我以爲有更簡單的方法呢，謝博主指點了。
請教樓主：
我正在搞一個醫學教育視頻資源在線預覽的網站，只提供幾分鐘的視頻預覽，用swf格式，會員收看預覽後線下可購買DVD光碟。
系統架構打算使用三臺服務器：網頁服務器、數據庫服務器、視頻服務器。
網頁使用全部靜態，數據庫用SQL Server 2000，CMS是用ASP開發的。
會員數按十萬級設計，不使用庫表散列技術，請樓主給個建議，看看我的方案可行不？
這個數量級的應用好好配置優化一下服務器和代碼，三臺服務器完全沒有問題，關鍵不是看整體會員數有多少，而是看同時在線的併發數有多少，併發不多就完全沒有問題了，併發多的話，三臺的這種架構還是有些問題的。
看了樓主的文章及各位大師的討論,感到受益非淺!真希望自己有機會親自接觸一下這樣的大型服務系統。希望樓主多寫些好文章！
這是一篇很棒的文章，裏面有兩篇回覆也很好。高訪問量的網站架構策略是很多網站開發時需要的。如果文章能更細節一些就更好了，建議樓主將這方面的內容寫成一本書，我相信一定有很多人想要它，省去了後來者艱難的探索。
看了大型網站的架夠,很想了解關於大型網絡架夠的防DDOS處理是怎麼搞的,剛建了個小站,經常被攻擊,導致用戶嚴重流失,已經快關了,所以希望,能對DDOS的攻擊處理方法提供一些詳細的方案!
Hi Michael,
I’m developing my own eCommerce product based on DotNetNuke and your article gives me a lot of inspiration.
Thank you so much for sharing.
Frank
Frank Wang on August 17, 2007 at 9:12 am said:
Hi Michael,
I’m developing my own eCommerce product based on DotNetNuke and your article gives me a lot of inspiration.
Thank you so much for sharing.
Frank
客氣了，歡迎常來交流。
Michael大蝦，我是一個Web方面的小菜鳥，目前工作是負責開發和維護公司的實時系統，不過一直對網站建設很感興趣。
看了你的文章感覺非常受用，希望能和你更進一步的交流，或者說直接點就是向你請教向你學習。我的qq：116901807，非常急切的想和你聯繫，希望你能抽空和我聊聊，謝謝！！！
Mr.Happy on September 13, 2007 at 10:59 am said:
Michael大蝦，我是一個Web方面的小菜鳥，目前工作是負責開發和維護公司的實時系統，不過一直對網站建設很感興趣。
看了你的文章感覺非常受用，希望能和你更進一步的交流，或者說直接點就是向你請教向你學習。我的qq：116901807，非常急切的想和你聯繫，希望你能抽空和我聊聊，謝謝！！！
最近幾天公司事情實在太多，每天都工作到凌晨兩三點，blog也少了，剛看到你的留言，歡迎和我交流，在blog裏面有我的聯繫方式，包括QQ。
週末或者晚上11點以後我時間會稍微多一點，其他時間估計都很難有足夠的時間聊天，請多多包涵和理解
有人說圖片沒必要分離，那是錯的
雖然我沒有做web，但是圖片一般都是一些小文件
讀的時候，非常佔用io的，比起http建立所耗的時候更恐怖
一個磁盤的io數必定是非常有限的
我開發過一個文件服務器，所以很明白….
我們在做web server的cache的時候使用tangosol coherence.
xzg on September 29, 2007 at 10:29 pm said:
有人說圖片沒必要分離，那是錯的
雖然我沒有做web，但是圖片一般都是一些小文件
讀的時候，非常佔用io的，比起http建立所耗的時候更恐怖一個磁盤的io數必定是非常有限的
我開發過一個文件服務器，所以很明白….
這位兄弟說太好了，說真的，中國的計算機科學最缺乏的就是對基礎科學深刻理解的高手，這位兄弟接觸的就是這個部分，是真正的高手。
講的都是最普通的，沒有什麼特別之處
fred on September 30, 2007 at 9:25 am said:
講的都是最普通的，沒有什麼特別之處
拋磚引玉，的確都不深入。
不知道能不能給幾個機會討論一下。我是從事。net方向的
各模塊間或者進程間的通信普遍異步化隊列化也相當重要，可以兼顧輕載重載時的響應性能和系統壓力,數據庫壓力可以通過file cache分解到文件系統，文件系統io壓力再通過mem cache分解，效果很不錯.