轉：高併發高負載系統架構

本文做者在Cernet作過撥號接入平臺的搭建，然後在Yahoo3721負載搜索引擎前端平臺開發，又在貓撲處理過大型社區貓撲大雜燴的架構升級等工做，同時本身接觸和開發過很多大中型網站的模塊，所以在大型網站應對高負載和併發的解決方案上有一些積累和經驗，能夠和你們一塊兒探討一下。

　　一個小型的網站，好比我的網站，能夠使用最簡單的html靜態頁面就實現了，配合一些圖片達到美化效果，全部的頁面均存放在一個目錄下，這樣的網站對系統架構、性能的要求都很簡單，隨着互聯網業務的不斷豐富，網站相關的技術通過這些年的發展，已經細分到很細的方方面面，尤爲對於大型網站來講，所採用的技術更是涉及面很是廣，從硬件到軟件、編程語言、數據庫、WebServer、防火牆等各個領域都有了很高的要求，已經不是原來簡單的html靜態網站所能比擬的。

　　大型網站，好比門戶網站。在面對大量用戶訪問、高併發請求方面，基本的解決方案集中在這樣幾個環節：使用高性能的服務器、高性能的數據庫、高效率的編程語言、還有高性能的Web容器。可是除了這幾個方面，還無法根本解決大型網站面臨的高負載和高併發問題。

　　上面提供的幾個解決思路在必定程度上也意味着更大的投入，而且這樣的解決思路具有瓶頸，沒有很好的擴展性，下面我從低成本、高性能和高擴張性的角度來講說個人一些經驗。

　　1、HTML靜態化

　　其實你們都知道，效率最高、消耗最小的就是純靜態化的html頁面，因此咱們儘量使咱們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。可是對於大量內容而且頻繁更新的網站，咱們沒法所有手動去挨個實現，因而出現了咱們常見的信息發佈系統CMS，像咱們常訪問的各個門戶站點的新聞頻道，甚至他們的其餘頻道，都是經過信息發佈系統來管理和實現的，信息發佈系統能夠實現最簡單的信息錄入自動生成靜態頁面，還能具有頻道管理、權限管理、自動抓取等功能，對於一個大型網站來講，擁有一套高效、可管理的CMS是必不可少的。

　　除了門戶和信息發佈類型的網站，對於交互性要求很高的社區類型網站來講，儘量的靜態化也是提升性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再從新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。

　　同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用數據庫查詢可是內容更新很小的應用，能夠考慮使用html靜態化來實現，好比論壇中論壇的公用設置信息，這些信息目前的主流論壇均可以進行後臺管理而且存儲再數據庫中，這些信息其實大量被前臺程序調用，可是更新頻率很小，能夠考慮將這部份內容進行後臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。

　　2、圖片服務器分離

　　你們知道，對於Web服務器來講，無論是Apache、IIS仍是其餘容器，圖片是最消耗資源的，因而咱們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片服務器，甚至不少臺圖片服務器。這樣的架構能夠下降提供頁面訪問請求的服務器系統壓力，而且能夠保證系統不會由於圖片問題而崩潰，在應用服務器和圖片服務器上，能夠進行不一樣的配置優化，好比apache在配置ContentType的時候能夠儘可能少支持，儘量少的LoadModule，保證更高的系統消耗和執行效率。

　　3、數據庫集羣和庫表散列

　　大型網站都有複雜的應用，這些應用必須使用數據庫，那麼在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快沒法知足應用，因而咱們須要使用數據庫集羣或者庫表散列。

　　在數據庫集羣方面，不少數據庫都有本身的解決方案，Oracle、Sybase等都有很好的方案，經常使用的MySQL提供的Master/Slave也是相似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施便可。

　　上面提到的數據庫集羣因爲在架構、成本、擴張性方面都會受到所採用DB類型的限制，因而咱們須要從應用程序的角度來考慮改善系統架構，庫表散列是經常使用而且最有效的解決方案。咱們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不一樣的模塊對應不一樣的數據庫或者表，再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，好比用戶表，按照用戶ID進行表散列，這樣就可以低成本的提高系統的性能而且有很好的擴展性。sohu的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，而後對帖子、用戶按照板塊和ID進行散列數據庫和表，最終能夠在配置文件中進行簡單的配置便能讓系統隨時增長一臺低成本的數據庫進來補充系統性能。

　　4、緩存

　　緩存一詞搞技術的都接觸過，不少地方用到緩存。網站架構和網站開發中的緩存也是很是重要。這裏先講述最基本的兩種緩存。高級和分佈式的緩存在後面講述。

　　架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了本身的緩存模塊，也能夠使用外加的Squid模塊進行緩存，這兩種方式都可以有效的提升Apache的訪問響應能力。

　　網站程序開發方面的緩存，Linux上提供的Memory Cache是經常使用的緩存接口，能夠在web開發中使用，好比用Java開發的時候就能夠調用MemoryCache對一些數據進行緩存和通信共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各類語言基本都有本身的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也確定有。

　　5、鏡像

　　鏡像是大型網站常採用的提升性能和數據安全性的方式，鏡像的技術能夠解決不一樣網絡接入商和地域帶來的用戶訪問速度差別，好比ChinaNet和EduNet之間的差別就促使了不少網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這裏不闡述太深，有不少專業的現成的解決架構和產品可選。也有廉價的經過軟件實現的思路，好比Linux上的rsync等工具。

　　6、負載均衡

　　負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。

　　負載均衡技術發展了多年，有不少專業的服務提供商和產品能夠選擇，我我的接觸過一些解決方法，其中有兩個架構能夠給你們作參考。

　　硬件四層交換

　　第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。　第四層交換功能就象是虛IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其餘協議。這些業務在物理服務器基礎上，須要複雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。

　　在硬件四層交換產品領域，有一些知名的產品能夠選擇，好比Alteon、F5等，這些產品很昂貴，可是物有所值，可以提供很是優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。

　　軟件四層交換

　　你們知道了硬件四層交換機的原理後，基於OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。可是知足必定量的壓力仍是遊刃有餘的，有人說軟件實現方式其實更靈活，處理能力徹底看你配置的熟悉能力。

　　軟件四層交換咱們能夠使用Linux上經常使用的LVS來解決，LVS就是Linux Virtual Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提升系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，能夠同時知足多種應用需求，這對於分佈式的系統來講必不可少。

　　一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣，這種思路在不少大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都很是容易。這樣的架構我準備空了專門詳細整理一下和你們探討。

　　對於大型網站來講，前面提到的每一個方法可能都會被同時使用到，我這裏介紹得比較淺顯，具體實現過程當中不少細節還須要你們慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大，但願你們一塊兒討論，達到拋磚引玉之效。

隨着中國大型IT企業信息化速度的加快，大部分應用的數據量和訪問量都急劇增長，大型企業網站正面臨性能和高數據訪問量的壓力，並且對存儲、安全以及信息檢索等等方面都提出了更高的要求……

    本文中，我想經過幾個國外大型IT企業及網站的成功案例，從Web技術人員角度探討如何積極地應對國內大型網站即將面臨的擴展（主要是技術方面，而較少涉及管理及營銷等方面）矛盾。 

1、 國外大型IT網站的成功之道 
(一) MySpace 
    今天，MySpace已經成爲全球衆口皆碑的社區網站之王。儘管一流和營銷和管理經驗天然是每一個IT企業取得成功的首要因素，可是本節中咱們卻拋棄這一點，而主要着眼於探討在數次面臨系統擴張的緊急關頭MySpace是如何從技術方面採起應對策略的。 
第一代架構—添置更多的Web服務器 
    MySpace最初的系統很小，只有兩臺Web服務器（分擔處理用戶請求的工做量）和一個數據庫服務器（全部數據都存儲在這一個地方）。那時使用的是Dell雙CPU、4G內存的系統。在早期階段，MySpace基本是經過添置更多Web服務器來對付用戶暴增問題的。但到在2004年早期，在 MySpace用戶數增加到五十萬後，其數據庫服務器已經開始疲於奔命了。 

第二代架構—增長數據庫服務器 
    與增長Web服務器不一樣，增長數據庫並沒那麼簡單。若是一個站點由多個數據庫支持，設計者必須考慮的是，如何在保證數據一致性的前提下讓多個數據庫分擔壓力。

    MySpace運行在三個SQL Server數據庫服務器上—一個爲主，全部的新數據都向它提交，而後由它複製到其它兩個；另兩個數據庫服務器全力向用戶供給數據，用以在博客和我的資料欄顯示。這種方式在一段時間內效果很好——只要增長數據庫服務器，加大硬盤，就能夠應對用戶數和訪問量的增長。

    這一次的數據庫架構按照垂直分割模式設計，不一樣的數據庫服務於站點的不一樣功能，如登陸、用戶資料和博客。垂直分割策略利於多個數據庫分擔訪問壓力，當用戶要求增長新功能時，MySpace只須要投入新的數據庫加以支持。在帳戶到達二百萬後，MySpace還從存儲設備與數據庫服務器直接交互的方式切換到SAN（存儲區域網絡）—用高帶寬、專門設計的網絡將大量磁盤存儲設備鏈接在一塊兒，而數據庫鏈接到SAN。這項措施極大提高了系統性能、正常運行時間和可靠性。然而，當用戶繼續增長到三百萬後，垂直分割策略也變得難以維持下去。

第三代架構—轉到分佈式計算架構 
    幾經折騰，最終，MySpace將目光移到分佈式計算架構——它在物理上分佈的衆多服務器，總體必須邏輯上等同於單臺機器。拿數據庫來講，就不能再像過去那樣將應用拆分，再以不一樣數據庫分別支持，而必須將整個站點看做一個應用。如今，數據庫模型裏只有一個用戶表，支持博客、我的資料和其餘核心功能的數據都存儲在相同數據庫。

    既然全部的核心數據邏輯上都組織到一個數據庫，那麼MySpace必須找到新的辦法以分擔負荷——顯然，運行在普通硬件上的單個數據庫服務器是無能爲力的。此次，再也不按站點功能和應用分割數據庫，MySpace開始將它的用戶按每百萬一組分割，而後將各組的所有數據分別存入獨立的SQL Server實例。目前，MySpace的每臺數據庫服務器實際運行兩個SQL Server實例，也就是說每臺服務器服務大約二百萬用戶。據MySpace的技術人員說，之後還能夠按照這種模式以更小粒度劃分架構，從而優化負荷分擔。 

第四代架構—求助於微軟方案 
    2005年早期，帳戶達到九百萬，MySpace開始用微軟的C#編寫ASP.NET程序。在收到必定成效後，MySpace開始大規模遷移到ASP.NET。 
    帳戶達到一千萬時，MySpace再次遭遇存儲瓶頸問題。SAN的引入解決了早期一些性能問題，但站點目前的要求已經開始週期性超越SAN的I/O容量——即它從磁盤存儲系統讀寫數據的極限速度。 

第五代架構—增長數據緩存層並轉到支持64位處理器的SQL Server 2005 
    2005年春天，MySpace帳戶達到一千七百萬，MySpace又啓用了新的策略以減輕存儲系統壓力，即增長數據緩存層——位於Web服務器和數據庫服務器之間，其惟一職能是在內存中創建被頻繁請求數據對象的副本，如此一來，不訪問數據庫也能夠向Web應用供給數據。

    2005年中期，服務帳戶數達到兩千六百萬時，MySpace由於咱們對內存的渴求而切換到了還處於beta測試的支持64位處理器的SQL Server 2005。升級到SQL Server 2005和64位Windows Server 2003後，MySpace每臺服務器配備了32G內存，後於2006年再次將配置標準提高到64G。

    事實上，MySpace的Web服務器和數據庫仍然常常發生超負荷，其用戶頻繁遭遇「意外錯誤」和「站點離線維護」等告示，他們不得不在論壇抱怨不停…… 

    MySpace正是在這樣不斷重構站點軟件、數據庫和存儲系統中，才一步步走到今天。事實上，MySpace已經成功解決了不少系統擴展性問題，其中存在至關的經驗值得咱們借鑑。MySpace系統架構到目前爲止保持了相對穩定，但其技術人員仍然在爲SQL Server支持的同時鏈接數等方面繼續攻堅，儘量把事情作到最好。 

(二) Amazon 
    亞馬遜書店無疑是電子商務發展的里程碑。2000年到如今，世界網絡業腥風血雨。Amazon曾經成爲網絡泡沫的頭號表明。現在，當這個「最大的泡沫」用幾經易改的數字把本身變成了堅實的IT巨人。 

    歷覽Amazon發展過程，其成功經驗在於，它創造性地進行了電子商務中每一環節的探索，包括系統平臺的建設，程序編寫、網站設立、配送系統等等方面。用Amazon當家人貝索斯的話說就是，「在現實世界的商店最有力的武器就是地段，地段，地段，而對於咱們來講最重要的三件事就是技術，技術，技術。」 

(三) eBay 
    eBay是世界聞名的拍賣網站，eBay公司通訊部主管凱文•帕斯格拉夫認爲，「eBay成功的最重要緣由在於公司管理和服務。」 
    其成功的奧祕能夠列舉爲如下幾點： 
    ①敢爲天下先—在網絡尚不普及的時代，eBay率先進入網絡拍賣領域； 
    ②依託虛擬商場所產生的特有的「零庫存」是eBay公司取得成功的另外一個重要緣由。該公司的核心業務沒有任何庫存風險，全部的商品都是由客戶提供，它只須要負責提供虛擬的拍賣平臺—網絡和軟件。因此，eBay公司的財務報表上不會出現「庫存費用」和「保管費用」等。 
③自eBay公司成立開始，它就一直遵循兩條「黃金原則」：建設虛擬社區，給網民以家的感受；保證網站穩定安全地運行。

2、 國內大型網站開發時的幾點建議 
    從本節開始，咱們將結合國內外大型IT網站在技術擴展方面的沉痛教訓和成功經驗，探討在現在剛剛開始的Web 2.0時代如何應對國內網站即將面臨的數據訪問量增長（甚至是急劇膨脹）的問題，並提出一些供參考的策略和建議。 

(四) 搭建科學的系統架構 
    構建大型的商業網站絕對不可能像構建普通的小型網站同樣一蹴而就，須要從嚴格的軟件工程管理的角度進行認真規劃，有步驟有邏輯地進行開發。對於大型網站來講，所採用的技術涉及面極其普遍，從硬件到軟件、編程語言、數據庫、Web服務器、防火牆等各個領域都有了很高的要求，已經不是原來簡單的 html靜態網站所能比擬的。以著名的Yahoo!爲例，他們的每個大型網站工程都須要大量相應專業人員的參與。 

(五) 頁面靜態化 
    可不要小看純靜態化的HTML頁面！其實在不少狀況下，HTML每每意味着「效率最高、消耗最小」，因此咱們儘量使咱們的網站上的頁面採用靜態頁面來實現。可是，對於大量內容而且頻繁更新的網站，咱們沒法所有手動實現，所以能夠開發相應的自動化更新工具，例如咱們常見的信息發佈系統CMS。像咱們常常訪問的各個門戶站點的新聞頻道，甚至他們的其餘頻道，都是經過信息發佈系統來管理和實現的。信息發佈系統能夠實現最簡單的信息錄入自動生成靜態頁面，還能具有頻道管理、權限管理、自動抓取等功能，對於一個大型網站來講，擁有一套高效、可管理的CMS是必不可少的。 

(六) 存儲問題 
    存儲也是一個大問題，一種是小文件的存儲，好比圖片這類；另外一種是大文件的存儲，好比搜索引擎的索引。 
你們知道，對於Web服務器來講，無論是Apache、IIS仍是其餘容器，圖片是最消耗資源的，因而咱們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片服務器，甚至不少臺圖片服務器。這樣的架構能夠下降提供頁面訪問請求的服務器系統壓力，而且能夠保證系統不會由於圖片問題而崩潰，在應用服務器和圖片服務器上，能夠進行不一樣的配置優化以保證更高的系統消耗和執行效率。

(七) 數據庫技術—集羣和庫表散列 
    對於大型網站而言，使用大型的數據庫服務器是必須的事情。可是，在面對大量訪問的時候，數據庫的瓶頸仍然會顯現出來，這時一臺數據庫將很快沒法知足應用，因而咱們須要藉助於數據庫集羣或者庫表散列技術。

    在數據庫集羣方面，不少數據庫廠商都有本身的解決方案，Oracle、Sybase、SQL Server等都有很好的方案，經常使用的MySQL提供的Master/Slave也是相似的方案。所以，你使用了什麼樣的數據庫，就參考相應的解決方案來實施便可。 

    上面提到的數據庫集羣因爲在架構、成本、擴張性方面都會受到所採用數據庫類型的限制，因而咱們須要從應用程序的角度來考慮改善系統架構，其中，庫表散列是經常使用而且最有效的解決方案。咱們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不一樣的模塊對應不一樣的數據庫或者表，再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，好比用戶表，按照用戶ID進行表散列，這樣就可以低成本的提高系統的性能而且有很好的擴展性。在這一方面一個現成的例子就是搜狐。它的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，而後對帖子、用戶按照板塊和ID進行散列數據庫和表，最終能夠在配置文件中進行簡單的配置便能讓系統隨時增長一臺低成本的數據庫進來補充系統性能。 

(八) 緩存策略 
    這絕對不單指低級的緩存技術相關的編程，應從整個架構角度着眼，深刻研究Web服務器、數據庫服務器的各層級的緩衝策略，最後纔是低級的緩衝技術的編程。不一樣的Web服務器、數據庫服務器及Web編程語言都有本身不一樣的緩衝策略。例如數據庫存儲方面，SQL Serve 2005中的主動式緩存機制，Oracle數據的cache group技術，Hibernate的緩存包括Session的緩存和SessionFactory的緩存；Web服務器方面，Apache提供了本身的緩存模塊，也能夠使用外加的Squid模塊進行緩存，這兩種方式都可以有效的提升Apache的訪問響應能力，IIS緩衝器技術；至於web開發語言，所用緩存技術更存在很大不一樣，例如ASP.NET 2.0中提出了兩種緩存應用程序數據和緩存服務頁輸出的策略，這兩種緩存技術相互獨立但不相互排斥，PHP有Pear的Cache模塊，等等。 

(九) 鏡像 
    鏡像是大型網站常採用的提升性能和數據安全性的方式，鏡像的技術能夠解決不一樣網絡接入商和地域帶來的用戶訪問速度差別。在鏡像的細節技術方面，這裏不闡述太深，有不少專業的現成的解決架構和產品可選。也有廉價的經過軟件實現的思路，好比Linux上的rsync等工具。 

(十) 負載均衡 
    負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。 
負載均衡技術發展了多年，有不少專業的服務提供商和產品能夠選擇，基於LAMP解決方案的Lighttped+Squid是至關不錯的解決負載均衡和加速系統的有效方式。

(十一) 硬件四層交換 
    第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。第四層交換功能就象是虛IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其餘協議。這些業務在物理服務器基礎上，須要複雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。

    在硬件四層交換產品領域，有一些知名的產品能夠選擇，好比Alteon、F5等，這些產品很昂貴，可是物有所值，可以提供很是優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。

(十二) 軟件四層交換 
    你們知道了硬件四層交換機的原理後，基於OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。可是知足必定量的壓力仍是遊刃有餘的。

    一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣，這種思路在不少大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都很是容易。 

(十三) 軟件投資問題 
    據報導，目前國內除了一些上市企業和特別大知名大公司之外，不多有企業在成本中考慮正版軟件的購置費用。這種思惟極有可能給中國互聯網帶來噩夢。若是一些公司真正面臨軟件資金方面的困難，徹底能夠考慮使用開源世界的LAMP解決方案（Linux＋Apache＋MySQL＋Perl、PHP或者 Python Web編程語言）；不然，隨着我國加入WTO範圍的不斷擴大，盜版打擊必然愈來愈嚴。所以，「苟且偷生」必將自作自受。 

    另外，隨着網絡帶寬日漸提高，WEB 2.0技術必將影響到網絡世界的幾乎每個角落。所以，如何積聚技術人員進行技術攻關並進一步增強安全防範也成爲一個日益嚴峻的問題，宜儘早歸入到公司的議事日程。 
   
4、 總結 
    中國電子商務真正理性發展的一個標誌，是大量的傳統企業實實在在地開始用互聯網來處理商務、作生意，而如今這樣的浪潮已經開始。北京發行集團，聯合SINA、6688.com等單位共同推出的網上虛擬書店—新新書店就是這樣的一個標誌。 

    隨着網絡帶寬日漸提高，隨着網絡理念和WEB 2.0技術的斷深刻人心，各類B2B、B2C、C2C等電子商務模式極可能以立體交叉方式整合到各類大型商務網站中來。所以，做爲公司的技術人員，做爲臨危救駕的「白衣騎士」，如何應對海量存儲、海量訪問問題，海量信息檢索的問題，日益嚴峻的安全問題，等等，已經刻不容緩。

當互聯網吵吵嚷嚷的進入2.0時代，當互聯網的技術再也不是那麼遙不可及，當複製變成屢見不鮮，互聯網熱鬧起來了

     myspace火了，中國冒出更多的myspace

     youtube剛剛起來，中國的視頻網站就遍地開花

     51拔地而起，中國出了無數的SNS

     facebook則改變了中國站長的抄襲方式，再也不學chianren了，校內火了
     ..........

     當抄襲變成習慣，我想說的是，模仿，站長，你準備好了嗎？

     若是你打算作垃圾站，或者賺點廣告費的網站，請不要點擊這篇文章，我從技術角度方面談談WEB2.0網站的模仿問題。

     當投資和流量都不是問題的時候，我想說的是，您真的一路順風嗎？

     拿SNS網站來講，當匆匆上線的2.0，當一筆筆投資砸進去的時候，當流量上去的時候，您的困惑在什麼地方？

     我作過多個2.0公司的技術顧問，簡單的談談2.0公司遇到的問題(涉及隱私，我用A B C D代替)，這裏就再也不贅述你們衆所周知的頁面靜態化，緩存和代碼安全等問題了，有點技術的2.0公司的CTO都知道這些東西，咱們談點發展以後的問題

A公司

     A公司作的是SNS網站，程序是兩個毛頭小夥子作的，目標直指51，程序開發是一路順風，功能也比51牛多了，推廣也是一路順風（A公司有本身獨到的推廣 方式。可是當ALEXA到2W的時候問題出來了，天天下午4點左右，網站速度慢的驚人，基本上打不開，公司三臺服務器CPU100%，讓人鬱悶的是公司的 網絡配置方式，竟然是雙WEB的集羣，而單獨一臺DB數據庫。整個瓶頸在數據庫，因而我建議作DB的集羣，分析了一下數據結構，MD，典型的WEB程序員 的做品，沒有一點數據庫設計規範，功能實現是能夠，若是要擴展，不可能，集羣基本上是不可能的，怎麼辦？不能辦，因而，一個月的時間修改程序，數據結構基 本上換了一遍 前期砸進去的幾十萬打了水飄，用戶走光了。

     結論：WEB2.0前期設計的時候不該該只考慮功能，應該認真考慮一下底層和數據結構了。

B公司

     B公司也是作的SNS網站，程序是3我的開發的，CEO是某名牌大學的經濟學碩士，有點知己網的味道，又有一些特點出來，說實話，公司的潛力不錯，CEO 有很強的運做能力，感受前景不錯。系統架構還行，可是---可是系統崩潰了，why?系統沒有考慮到用戶有個海量的說法，文件也有個海量的說法，用戶的相 冊，圖片所有存貯在WEB服務器的一個分區上，每一個用戶一個目錄，而打開性能監視器，磁盤的IO高的驚人，基本上無暇響應。衆所周知，文件系統也是一個數 據庫，單獨大文件無所謂，關鍵是整個是300多個G的零碎文件，大量的讀寫操做，系統崩潰，數據丟失，文件系統的一個鏈斷了，用戶數據所有丟失！！！這是 一個很是沉重的問題，系統整整停了一個月來作數據恢復（單獨文件很容易，可是海量文件目前尚未一個軟件能組織起來軟件架構）。解決方案：修改程序架構， 作分佈式文件存貯（程序修改用了8天，可是文件轉移卻又用去了將近一個月），20萬用戶損失殆盡

     結論：WEB2.0前期的設計應該有應付海量存貯的考慮，整個涉及了程序架構的修改，前期規劃很差的話基本上思路一條。

C公司

     C公司是一個值得尊敬的公司，CEO技術出身，和比爾蓋茨同樣，大學未畢業出來作網絡，01到03年作短信狠賺了一筆，後來作的小項目也小有所成，說實 話，我很佩服。公司作的是校友方面，可是更偏重myspace風格，注重我的主頁，推廣方面也下了大手筆。系統崩潰的緣由其實很簡單，因爲採用的是微軟的 SqlServer，而微軟直接就告訴了咱們，SQLSERVER不支持集羣，他們的數據庫超負載，100%就沒有下去過，只能橫向增長配置，採用了4路 4核CPU系統，可是系統仍是崩潰了... 高互動註定了高負載。解決方案： 現從基本入手，解決掉幾個程序耗能大戶，對數據庫採用橫向切割，將用戶每10萬進行分組，同時對數據庫系統進行散列，將多個表垂直分割，同時進行文件分組 ，解決問題. 由於修改了數據結構，程序也基本上大動了一下。 好在系統沒有出大錯，損失不算很大，不過對用戶體驗形成了很壞的影響。

     結論：WEB2.0前期設計應該有良好的散列考慮，程序應該能有配合的擴充性，符合數據庫的擴充

D公司

     D公司是一個各個方面作的比較好的公司，作了CDN加速，圖片也獨立分出了N個服務器，數據庫不錯的一個，(CTO是個數據庫專家），系統崩潰的緣由在於 WEB，按道理說WEB很容易作集羣的，可是發現集羣並解決不掉問題，他們的集羣只容許作4臺的WEB集羣，可是4臺都當掉了。仔細分析，找到緣由，我估 計整個也是大部分CTO最容易犯的一個錯誤，或者說他們根本就想不到的問題，就是WEB上傳的問題，上傳的時候因爲時間的緣由，線程是保持連接的，300 個線程就能夠把一個WEB Server當掉了。解決方案：這個最簡單，把上傳和其餘耗能大戶分離出獨立出來。程序改動不是很大，可是以前半個月速度滿對用戶體驗的損失也不可小視。

     結論：沒有什麼結論了，畢竟有海量訪問經驗的CTO很少，也就是那幾個大站的。

     總結：不是潑冷水，模仿實際上是很容易的，隨便找幾個WEB程序員就能作到，而且很簡單，速度可能還很高效，由於WEB2.0無非就是跟數據庫打交道，會操 做數據庫就會作。可是真正作大並不容易，由於能應付海量訪問的程序並不簡單，如今的程序員都太自命不凡，其實真正有經驗的並很少，不要相信一個月薪5K- -10K的程序員能給你多大的驚喜，能應付海量訪問的程序員不是那個價格。若是您想作2.0，想作大，有幾個個建議：

     一.找DBMS的專家設計好數據庫，大部分程序員都不知道分區視圖，數據散列，數據組的概念

     二.設計好程序架構（這個其實不難，有個高人指導就好了），保持良好的擴展性，成本考慮能夠找兼職的系統架構設計師作好系統架構，肯定未來的發展瓶頸。

     三.考慮好文件存貯的問題。文件存貯的技術含量看起來很低，實際上是很高的，能夠考慮反向代理的方案。文件存貯出問題了，站點基本上就完蛋了，不只僅是RAID的問題和存貯服務器的問題，不過道理卻是一點就破的

     四.中國國情考慮，這個最致命，須要考慮電信和網通的問題，CDN並不能解決全部問題。互動性的東西並CDN並非頗有效。最關鍵的是，現有的雙線機房遇 到DDOS攻擊基本上都會當掉，緣由很簡單，雙線機房都是私人機房，自己就不會有過高的帶寬，隨便攻擊一下就能夠D掉（順帶提一個笑話，我知道一個雙線機 房的老總總共1G的帶寬卻買了4G的金盾牆，很簡單800M的攻擊就能夠搞定）。

     五.網絡延遲的問題，這是分佈式系統必需要考慮的，程序要能容忍0到100秒的數據延遲的功能，也就是同步的問題。不要小看這幾十秒，問題很大的，若是你 的站點有交互式功能，好比即時聊天，你能夠想象一下是個什麼結果。對於即時聊天的東西，能夠用反向代理來解決（成本較高）。可是對於留言和評論的影響不 大，可是若是系統爲了健壯作了緩存和靜態化的時候，這個東西可能就是災難性的了。

     六.分散你的程序，若是你沒有太多的資金構築動輒百萬的服務器，建議把功能分散開來，好比相冊一臺服務器，留言一臺服務器

     七.看好你的程序員，若是沒有很好的激勵措施的話你的程序員很容易寫出敷衍性的代碼，而這個可能就是未來的大患，程序架構定下來後要修改可能就要費牛勁了。最好你的CTO能對你100%的衷心，100%的負責。

     八.文件同步的問題，這個問題可能你以爲沒有必要，若是你看一下網通和電信的TTL就明白了，同步要支持續傳，而且不能是持續的，不然你的成本會高出N倍，不要指望能經過你的軟件實現，交給你的程序員吧，把上面的話告訴他他就知道怎麼作了。

     九.最狠的一個問題了，也是吃虧最大的問題，無論您跟網警的關係多好，看好你的用戶，審覈好你的東西，一被停機可能就致命，本人就吃過N次虧。

大型高負載的網站的體系結構和web2.0時代的網站高負載解決方案

從事發布系統(web publish system)的研究和開發快兩年了，從小型應用到中型應用，基本上沒有參與大型應用(千萬pv/day)的部署，網絡上這種技術的探討都不是特別全面，有的說起發佈系統對分佈式部署，以及海量負載，有的乾脆只層網絡層面進行講解，我感受這是個系統工程，不只要考慮到應用層面(user layer or app layer)，也要考慮到系統層面(kernel layer or system layer)，還要考慮到數據庫層面(database layer)，不然可能有失偏頗。

       我如今從三個層面就個人理解說一些個人一些見解，礙於知識和實踐的侷限性，也會至關有限。

       所謂應用層面指的是前端應用，由於對網站來講，網友接觸最多的就是前端頁面，影響負載的很大程度上也是天天上千萬的page view帶來的visit，對web1.0的網站來講，前端頁面每每都是靜態化的，即html化的，這也是爲了下降負載，由於web應用服務器解析 html頁面的速度是最快的，而頁面的靜態化通常都是由web級的(主要)和桌面局域網級別的(不多)發佈平臺發佈的，基於分佈式的考慮，發佈系統最好可以分發產生的html頁，分發到光纖或者高速局域網中的不一樣host上，以便分散訪問壓力。固然也能夠使用系統層的同步工具完成這個工做，注意要對頁面的域名對應信息進行保存，防止產生404 error。我我的比較喜歡系統層的網絡同步，速度比較快，穩定性也比較高。應用層的分發通常藉助ftp的方式，速度不是特別快，容易產生擁塞，穩定性天然降低。

       若是分佈式的分發靜態頁面仍然存在瓶頸，怎麼辦？國內大型的門戶網站每每採起可緩存的反向代理方式部署的負載均衡技術來解決，通常都是squid作前端 cache和反向代理。負載均衡也有軟件級的(dns 輪詢)負載均衡和硬件上的負載均衡甚至二者的結合進行實現，具體實施細則將在下一篇中進行闡述。說到靜態化，也不僅是web1.0的傳統新聞門戶採用， web2.0的應用前端也可靜態化，或者部分靜態化，好比：社區型門戶，帖子就能夠靜態化，能夠採起即時靜態或者異步靜態的方式，也能夠觸發靜態化。這種靜態化能夠下降數據庫層的壓力，數據庫服務器若是始終工做在大負載的訪問壓力下，很容易崩潰，儘量的將常常用到的數據靜態化，緩存起來會極大的下降壓力。（貓撲、網易、搜狐等社區都是採用的這種方式）

        上文提到了靜態化能減輕數據庫服務器的壓力，但是卻影響了更新的即時性，有些應用須要數據的即時顯示，不容許緩存或者靜態化，這就須要對數據庫服務器的結構進行合理部署。除了要在設計應用之初，很好的設計數據庫結構，使用好的模式以外，還要對數據庫服務器進行分佈式部署甚至庫表散列。在數據庫集羣(database culuster)方面，不少數據庫都有不錯的解決方案，包括Oracle、Sybase甚至mysql，只不過mysql採用的是master+ slave的結構，選用了何種數據庫，就參照相應的解決方案進行部署。除了在數據庫選擇上進行負載均衡以外，也能夠在單數據庫自己進行考慮，好比庫表的散列，根據應用的特色，將大的、影響性能的數據庫或者數據庫的單表進行散列、拆分。好比：按用戶id進行散列，按分類進行散列，或者按地區進行散列。

         說到系統層，可能就是OS和Web Server了，大型應用的OS基本都是Unix(包括freebsd或者HP Unix等)或者類Unix(各類linux版本，redhat居多)，這不是說Microsoft的OS就不合理了，合理的應用也可部署大型應用，只不過效能會很受限制。Web Server層面，仍是apache當家，尤爲是靜態頁和圖片，固然也能夠根據具體的需求，根據內容的特殊性選擇Lighttpd(比較適合作純靜態、圖片服務器、視頻服務器等)、甚至iis（windows下用的居多），系統層的web服務器的配置仍是頗有講究的，好比對cache的配置，反向代理的配置等。比較好的web加速和代理服務器有：Squid、Nginx、HAProxy、Lighttpd，這四個多是用的比較多的了。其中業內比較出名的Flickr、tudou用的是lighttpd，sina和51.com使用了，至少部分使用了Nginx。

        緩存系統對高負載的重要性是不言而喻的，前面提到的靜態化，須要進行有效緩存，常常用到的查詢和結果須要進行緩存，只要設定好更新緩存的規則，對性能的提高是n個數量級的。Linux下，有內存級別的緩存，高速緩存，不少應用都是用tmpfs來進行數據中轉，php上用的最多的是memcached， apache有文件系統級別的cache，squid也是作前端cache的主要手段。騰訊、網易等都是用了squid作前端cache server。

       前面提到的負載均衡，有軟件級別的，好比LVS、HAProxy、Linux-HA項目等，硬件層面的諸如：f5的BigIp、3DNS，alton的解決方案，北電的方案等，都是比較成熟的，不過都須要付出至關可觀的￥。

       之前談到過關於高負載、大訪問量的門戶型web1.0網站的體系結構，提到了許多諸如front-end cache，clustered database，proxy server，cdn等技術，隨着web2.0的溫度愈來愈high，web2.0的一些表明性網站的體系結構也被曬了出來，我在這裏進行簡單的整理，呈現給你們。

       案例1：豆瓣

      豆瓣是由阿北(楊勃) 花4個多月時間(很神速，關鍵是成竹在胸)，基於linux+lighttpd+fastcgi+python+quixote+mysql架構部署的 web2.0網站，豆瓣的搜索引擎使用twisted，這個是豆瓣的後臺，書的價格以及比較信息都是在此之上搜索各大購物網站而來的，mysql用了 innodb和myisam兩種引擎，讀/寫頻繁的用innodb，讀多寫少、寫多讀少(好比log)或者須要full text index的用myisam，replication/cluster作數據複製和集羣，晚上用mysqldump作backup。

        案例2：youtube

       出於開發效率的考慮，youtube的大部分代碼都是python的， web server有兩種，一種是apache+fastcgi，另外一種是lighttpd(主要作爲視頻內容服務器)，youtube多是lighttpd 最好的案例。youtube每個視頻都有4個縮略圖(Thumbnails)，這個縮略圖的產生對服務器的負載是個極大的考驗，每一秒都給disk的 i/o帶來壓力，youtube採用了獨立的服務器culuster來應對這方面的壓力，也對操做系統和緩存作了優化。另外，縮略圖的request也致使了lighttpd性能降低，經過 Hack Lighttpd 增長更多的 worker thread很大程度解決了這個問題，被google收購之後，開始使用google的存儲法寶bigtable，一會兒提高了在 performance、redundancy、cache等方面的表現。(看來此次收購仍是效果頗大)出於redundancy的考慮，每個 video都放到一組mini cluster上，這組mini cluster上存儲了相同內容的視頻，the hotest video放在了cdn上，使壓力分佈到不一樣的節點上，非熱門的，訪問量不高的本身進行單獨處理。維護的工具也是常見的rsync(同步工具)、ssh (遠程登陸)等。數據庫上，youtube跟不少web2.0的站點同樣，偏向使用mysql，主要是存儲一些meta data，諸如視頻信息、圖片信息、用戶信息等。youtube經過刪除swap交換分區來解決數據庫遇到的swap顛簸問題。

         youtube最初的 DB 只有 10 塊硬盤，後來追加了一組RAID1。在擴展性方面，採用的是主流的方式，master/slave複製(replication)，分散IO。最終的解決之道是是業務層面的分區(在用戶名字或者 ID 上作文章,應用程序控制查找機制)，而不是物理上的數據庫層面的表分區。youtube也用了memcached。

       案例3：myspace

       myspace有6500萬的訂閱者(還在上升)，是因特網上增加最快的網站之一，天天還有260，000新用戶註冊。它常常由於性能問題而受指責， MySpace不得不處理其餘網站不多碰到的或大或小的一些問題。它們是怎麼作的呢？使用的平臺是 ASP.NET 2.0 + Windows + IIS + SQL Server ，myspace 天天處理15億的頁面查看，白天處理230萬併發的用戶，在50萬用戶的時候，採用簡單的磕磕絆絆的體系結構，100萬用戶時進行了痛苦的垂直分割解決伸縮性，300萬用戶時Scale-Out 賽過Scale-Up（按比例增長）， 900萬用戶的時候，站點遷移到ASP.NET，增長了虛擬存儲，260萬用戶的時候myspace採用了64位技術，當小於300萬個賬號的時候，他們使用了一種數據庫體系結構，圍繞着垂直分割的概念，提供不一樣服務好比界面登陸，用戶資料和博客等的網站的各部分都有單獨的數據庫。垂直分割方案有助於分開數據庫讀和寫的工做量，而且當用戶須要一個新特徵時，MySpace 將會加入一個新的在線數據庫來支持它。MySpace 從直接使用附着於它的數據庫的服務器的存儲設備轉換到一個存儲區域網絡（SAN），裏面大量的磁盤存儲設備由一個高速，專用網絡聯繫到一塊，同時數據庫鏈接到SAN。到SAN的改變提升了性能，正常運行時間和可靠性。當超過300萬個賬號的時候，垂直分割解決方案就很差使了，由於它們重複了一些水平的信息像跨過全部垂直片的用戶賬號。有這麼多的重複它會使系統變慢，確定要失敗。我的應用好比Web 站點子部分上的博客將會增加到對於單獨一個數據庫服務器來講太大的程度，在邏輯上重組全部核心數據到一個數據庫裏 
，把它的用戶基本信息分紅100萬賬號一個的塊，而後把全部有鍵的數據放到SQL Server不一樣實例的這些賬號中，在 900萬-1700萬賬號這個階段，遷移到ASP.NET後，使用了比先前的體系結構更少的資源。150個服務器運行新的代碼就可以作原來246個服務器作的一樣的工做。再看看存儲瓶頸，實施SAN解決了原來的一些性能問題，可是如今Web站點的需求開始間歇性地超過了SAN的I/O能力，它從磁盤存儲讀寫的速度，使用每一個數據庫100個賬號的分開方式達到了極限，由於這已經超過了極限；遷移到一個虛擬存儲體系結構，那裏整個SAN被看成一個大的存儲池來對待，不須要特定的磁盤爲特定的應用服務。如今MySpace在設備上從相對新的SAN廠商，3PARdata方面已經標準化了。增長了一個高速緩存層，服務器放在Web服務器和數據庫服務器之間，它惟一的工做就是捕獲內存中頻繁訪問的數據對象的副本，而後把它們用於Web應用，不須要數據庫查詢。超過2600萬註冊賬號後，開始遷移到64位SQL server以解決它們的內存瓶頸問題。它們的標準數據庫服務器配置使用64GB的RAM。

      Myspace的經驗告訴咱們：你能夠使用微軟的技術構建大型網站；從一開始就應該使用緩存；高速緩存是一個更好的地方存儲臨時數據，好比Web站點上跟蹤一個特定用戶的會話產生的臨時文件，就再也不須要記錄到數據庫裏；嵌入OS特徵來檢測拒絕服務攻擊會產生沒法解釋的錯誤；把數據分佈到地理位置不一樣的數據中心，以避免發生斷電事故。從開始就考慮使用虛擬存儲/簇文件系統。它能讓你大量並行IO訪問，並且不須要任何重組就可以增長所須要的磁盤。

一個剛入門的初學者開發一個網站後,能從哪些方面對系統的性能進行提高呢?

1. 編碼級別.這個是最小的級別,可能也是對性能的提高產生效果最小的.不過,咱們須要特別注意一些寶貴的資源釋放,每每這些錯誤在測試的時候不容易發現,系統一旦上線接受高訪問量的考驗就崩潰了.
2. 頁面級別.對於WEB系統來講,頁面是一個很重要的一部分,客戶端和服務端就是經過靜態的HTML,JS等代碼進行交互的.頁面的緩存策略,頁面的大小直接決定了客戶端訊問網站的速度和網絡流量.頁面級別的性能優化比編碼級別更有效一點.
3. 構架級別.一個好的構架能提高系統性能,而構架也可能成爲整個系統的殺手.對於分佈式的系統更是如此.若是在一個環節發生了問題就可能致使整個系統的性能產生明顯巨大的問題.
4. 配置與部署.一個一樣的系統可能在兩個相同硬件配置的服務器上產生明顯的性能差別.因爲網站是須要IIS進行解析的,換句話說,網站全部的流量都要通過IIS這個關口,若是IIS的配置不當的話,對網站形成的影響是致命的.

    下面,我將就這幾個方面介紹網站性能優化的一個具體作法,固然,方法並非絕對的,全部方法都僅供參考.其中不少的方法我也是從一些網站性能優化的書上摘抄下來的.

1、編碼級別的優化.

1.     數據鏈接.

o                                儘可能晚打開鏈接,儘可能早關閉鏈接.

o                                優化SQL語句或者存儲過程,儘可能縮短查詢運行時間

下面兩個鏈接方法就有很大的差異:

1.                  SQLConnection conn=new SQLConnection(".....");  

2.                  //打開鏈接  

3.                  conn.open();  

4.                  SqlCommand cmd=new SqlCommand("....",conn);  

5.                  ...  

6.                  ...  

7.                  cmd.ExecuteNonQuery();  

8.                  //關閉鏈接  

9.                  conn.Close(); 

10.               SQLConnection conn=new SQLConnection(".....");  

11.               SqlCommand cmd=new SqlCommand("....",conn);  

12.               ...  

13.               ...  

14.               //打開鏈接  

15.               conn.open();  

16.               cmd.ExecuteNonQuery();  

17.               //關閉鏈接  

18.               conn.Close(); 

上面的第一種方法就是過早的打開了數據鏈接,這樣是很是消耗資源的,要像第二種方法樣,在要執行查詢的時候纔打開鏈接.

2.     數據查詢

o                                Select記錄的時候,只返回須要的字段,不要Select * 把全部的字段都返回,數據越多對於服務器的壓力就越大.對於分佈式程序還會佔用更多的網絡流量.

o                                不要一次取出全部行,僅取出當前頁面須要的數據,這就涉及到分頁了.

o                                儘可能使用DataReader來進行數據讀取,DataReader是隻讀向前形式讀取數據的,性能要比Dataset高.

o                                使用DataReader的時候,儘可能一次返回多個記錄集,需不是爲每一個記錄打開一次數據庫.

o                                若是須要在一個代碼段中執行多個SQL語句,能夠使用存儲過程來優化性能.

3.     釋放資源

o                                使用Using來自動釋放對像. 

4.     其它優化

o                                不要依賴異常.異常是不可知的錯誤,

o                                使用泛型集合代替普通的集合. net2.0以上提供了不少泛型集合,使用泛型集合代替普通集合能提升性能.好比下面的代碼耗時2908毫秒:

1.                  ArrayList list=new ArrayList();  

2.                  for(int i=0;i<10000000; i++)  

3.                  list.add(i);  

4.                  int count=0;  

5.                  for(int i=0;i<list.Count;i++)  

6.                  count=(int)list[i]; 

改用泛型集合後代碼耗時只用370毫秒

7.                  List<int> list=new List<int>();  

8.                  for(int i=0;i<10000000; i++)  

9.                  list.add(i);  

10.               int count=0;  

11.               for(int i=0;i<list.Count;i++)  

12.               count=(int)list[i]; 

o                                不要大量使用反射,反射雖能減小項目依賴,可是會有比較大的性能損失,不推薦大量使用.

 

1. 網站配置

o                                發佈前禁用調試
發佈前記得要把Web.config 中compilation節點的debug設置爲False來禁用調試.不然應用程序性能會有很大的影響.在VS2005裏面新建一個網站後,在Web.config中會有這樣一個節點:

1.                  <!--   

2.                  設置 compilation debug="true" 將調試符號插入已編譯的頁面中  

3.                  。但因爲這會 影響性能，所以只在開發過程當中將此值 設置爲 true。  

4.                  -->  

5.                  <compilation debug="true"></compilation> 

在開發網站的時候設置的是True,可是在發佈的時候必定要記得把它設爲False.

o                                避免將錯誤頁設置爲同一個網站的某個頁面.(事實上不少網站都是把錯誤頁設置爲本站的某個頁面),這個設置不是很合理.之前我也不怎麼以爲這有多大的關係統.可是在我前不久訪問一個好友網站的時候,因爲出錯,它把我引向了錯誤頁,那個錯誤頁又是設置爲自動跳轉到網站首頁的,因此跳到首頁後出錯又把我引向錯誤頁,錯誤頁再一次幫我跳到首頁......這樣就致使了惡性循環.這種狀況通常不常見,可是在網站過於繁忙致使沒有足夠線程的時候會發生這樣的異常.把錯誤頁設置爲其它網站的某個友好頁面能解決這個問題.

2. 網站部署

o                                發佈前先編譯.
asp.net2.0提供了預編譯機制,能避免首次訪問網站編譯帶來的性能損失.使用IDE的發佈操做能很方便地進行編譯.

o                                HTTP壓縮.
在IIS中配置HTTP壓縮能減小30%的網絡流量.對於CPU佔用不高而網絡帶寬有限的網站來講,能夠採用壓縮來減小頁面加載時間.

3. 頁面加整
   • 儘量把幾個圖片合成一個圖片來減小向服務器請求的次數.(之前我一直覺得要把大圖切成小塊加載速度纔會快,事實恰好相反,實驗證實加載一張大圖要比加載這張大圖切成的小塊的時間要快得多.)
   • 儘可能不要使用表格進行佈局,特別是不要把整個頁面放在一個大表格里,使用這個表格來定義整個頁面(好比居中).由於瀏覽器只有讀到了一個標記的結束後纔會呈現(好比讀到表格的</table>),若是把整個頁面放在一個大表格中的話,那麼只有等整個頁面加載完畢了纔會呈如今觀衆面前,用css佈局的話,就算是網速慢,也會加載一點內容就呈現一點內容.不會出現速個屏幕爲白色.
   • 分離CSS,儘可能把CSS分離到單個文件中去,而不要在每一個頁面的頂部都生成一段CSS代碼.css文件能被客戶端緩存,使用獨立的CSS文件能減小頁面的數據量.
   • 最後,千萬不要用WORD生成HTML文件,那是外行作!
4. 其化優化
   • 減小沒必要要的服務端事件.好比清空TextBox的操做,能夠直接用一個不回發的客戶端按鈕來實現.

1.     <input type="reset" valie="重置"> 

而沒必要要用 :

2.     <asp:Button ID="..." Runat="server" text="重置" OnClick="..." />  

3.     在後臺寫按鈕事件:  

4.     textbox1.text="";  

5.     textbox2.text="";  

6.     ......... 

•   使用Page.IsPostBack來減小沒必要要的處理.一般咱們可能須要在頁面首次加載的時候初始化一些數據,而在單擊頁面上的按鈕回發頁面後不須要進行這些處理,能夠經過Page.IsPostBack判斷頁面是不是首次加載.來避免重複執行一些不要的代碼.

從LiveJournal後臺發展看大規模網站性能優化方法

於敦德 2006-3-16

1、LiveJournal發展歷程

LiveJournal是99年始於校園中的項目，幾我的出於愛好作了這樣一個應用，以實現如下功能：

• 博客，論壇
• 社會性網絡，找到朋友
• 聚合，把朋友的文章聚合在一塊兒

LiveJournal採用了大量的開源軟件，甚至它自己也是一個開源軟件。

在上線後，LiveJournal實現了很是快速的增加：

• 2004年4月份：280萬註冊用戶。
• 2005年4月份：680萬註冊用戶。
• 2005年8月份：790萬註冊用戶。
• 達到了每秒鐘上千次的頁面請求及處理。
• 使用了大量MySQL服務器。
• 使用了大量通用組件。

2、LiveJournal架構現狀概況

3、從LiveJournal發展中學習

LiveJournal從1臺服務器發展到100臺服務器，這其中經歷了無數的傷痛，但同時也摸索出瞭解決這些問題的方法，經過對LiveJournal的學習，可讓咱們避免LJ曾經犯過的錯誤，而且從一開始就對系統進行良好的設計，以免後期的痛苦。

下面咱們一步一步看LJ發展的腳步。

1、一臺服務器

一臺別人捐助的服務器，LJ最初就跑在上面，就像Google開始時候用的破服務器同樣，值得咱們尊敬。這個階段，LJ的人以驚人的速度熟悉的Unix的操做管理，服務器性能出現過問題，不過還好，能夠經過一些小修小改應付過去。在這個階段裏LJ把CGI升級到了FastCGI。

最終問題出現了，網站愈來愈慢，已經沒法經過優過化來解決的地步，須要更多的服務器，這時LJ開始提供付費服務，多是想經過這些錢來購買新的服務器，以解決當時的困境。
毫無疑問，當時LJ存在巨大的單點問題，全部的東西都在那臺服務器的鐵皮盒子裏裝着。

2、兩臺服務器

用付費服務賺來的錢LJ買了兩臺服務器：一臺叫作Kenny的Dell 6U機器用於提供Web服務，一臺叫作Cartman的Dell 6U服務器用於提供數據庫服務。

LJ有了更大的磁盤，更多的計算資源。但同時網絡結構仍是很是簡單，每臺機器兩塊網卡，Cartman經過內網爲Kenny提供MySQL數據庫服務。

暫時解決了負載的問題，新的問題又出現了：

• 原來的一個單點變成了兩個單點。
• 沒有冷備份或熱備份。
• 網站速度慢的問題又開始出現了，沒辦法，增加太快了。
• Web服務器上CPU達到上限，須要更多的Web服務器。

3、四臺服務器

又買了兩臺，Kyle和Stan，此次都是1U的，都用於提供Web服務。目前LJ一共有3臺Web服務器和一臺數據庫服務器。這時須要在3臺Web服務器上進行負載均橫。

LJ把Kenny用於外部的網關，使用mod_backhand進行負載均橫。

而後問題又出現了：

• 單點故障。數據庫和用於作網關的Web服務器都是單點，一旦任何一臺機器出現問題將致使全部服務不可用。雖然用於作網關的Web服務器能夠經過保持心跳同步迅速切換，但仍是沒法解決數據庫的單點，LJ當時也沒作這個。
• 網站又變慢了，此次是由於IO和數據庫的問題，問題是怎麼往應用裏面添加數據庫呢？

4、五臺服務器

又買了一臺數據庫服務器。在兩臺數據庫服務器上使用了數據庫同步(Mysql支持的Master-Slave模式)，寫操做所有針對主數據庫（經過Binlog，主服務器上的寫操做能夠迅速同步到從服務器上），讀操做在兩個數據庫上同時進行(也算是負載均橫的一種吧)。

實現同步時要注意幾個事項：

• 讀操做數據庫選擇算法處理，要選一個當前負載輕一點的數據庫。
• 在從數據庫服務器上只能進行讀操做
• 準備好應對同步過程當中的延遲，處理很差可能會致使數據庫同步的中斷。只須要對寫操做進行判斷便可，讀操做不存在同步問題。

5、更多服務器

有錢了，固然要多買些服務器。部署後快了沒多久，又開始慢了。此次有更多的Web服務器，更多的數據庫服務器，存在 IO與CPU爭用。因而採用了BIG-IP做爲負載均衡解決方案。

6、如今咱們在哪裏：

如今服務器基本上夠了，但性能仍是有問題，緣由出在架構上。

數據庫的架構是最大的問題。因爲增長的數據庫都是以Slave模式添加到應用內，這樣惟一的好處就是將讀操做分佈到了多臺機器，但這樣帶來的後果就是寫操做被大量分發，每臺機器都要執行，服務器越多，浪費就越大，隨着寫操做的增長，用於服務讀操做的資源愈來愈少。

由一臺分佈到兩臺

最終效果

如今咱們發現，咱們並不須要把這些數據在如此多的服務器上都保留一份。服務器上已經作了RAID，數據庫也進行了備份，這麼多的備份徹底是對資源的浪費，屬於冗餘極端過分。那爲何不把數據分佈存儲呢？

問題發現了，開始考慮如何解決。如今要作的就是把不一樣用戶的數據分佈到不一樣的服務器上進行存儲，以實現數據的分佈式存儲，讓每臺機器只爲相對固定的用戶服務，以實現平行的架構和良好的可擴展性。

爲了實現用戶分組，咱們須要爲每個用戶分配一個組標記，用於標記此用戶的數據存放在哪一組數據庫服務器中。每組數據庫由一個master及幾個slave組成，而且slave的數量在2-3臺，以實現系統資源的最合理分配，既保證數據讀操做分佈，又避免數據過分冗餘以及同步操做對系統資源的過分消耗。

由一臺（一組）中心服務器提供用戶分組控制。全部用戶的分組信息都存儲在這臺機器上，全部針對用戶的操做須要先查詢這臺機器獲得用戶的組號，而後再到相應的數據庫組中獲取數據。

這樣的用戶架構與目前LJ的架構已經很相像了。

在具體的實現時須要注意幾個問題：

• 在數據庫組內不要使用自增ID，以便於之後在數據庫組之間遷移用戶，以實現更合理的I/O，磁盤空間及負載分佈。
• 將userid，postid存儲在全局服務器上，能夠使用自增，數據庫組中的相應值必須以全局服務器上的值爲準。全局服務器上使用事務型數據庫InnoDB。
• 在數據庫組之間遷移用戶時要萬分當心，當遷移時用戶不能有寫操做。

7、如今咱們在哪裏

問題：

• 一個全局主服務器，掛掉的話全部用戶註冊及寫操做就掛掉。
• 每一個數據庫組一個主服務器，掛掉的話這組用戶的寫操做就掛掉。
• 數據庫組從服務器掛掉的話會致使其它服務器負載過大。

對於Master-Slave模式的單點問題，LJ採起了Master-Master模式來解決。所謂Master-Master其實是人工實現的，並非由MySQL直接提供的，實際上也就是兩臺機器同時是Master，也同時是Slave，互相同步。

Master-Master實現時須要注意：

• 一個Master出錯後恢復同步，最好由服務器自動完成。
• 數字分配，因爲同時在兩臺機器上寫，有些ID可能會衝突。

解決方案：

• 奇偶數分配ID，一臺機器上寫奇數，一臺機器上寫偶數
• 經過全局服務器進行分配(LJ採用的作法)。

Master-Master模式還有一種用法，這種方法與前一種相比，仍然保持兩臺機器的同步，但只有一臺機器提供服務（讀和寫），在天天晚上的時候進行輪換，或者出現問題的時候進行切換。

8、如今咱們在哪裏

如今插播一條廣告，MyISAM VS InnoDB。

使用InnoDB：

• 支持事務
• 須要作更多的配置，不過值得，能夠更安全的存儲數據，以及獲得更快的速度。

使用MyISAM：

• 記錄日誌（LJ用它來記網絡訪問日誌）
• 存儲只讀靜態數據，足夠快。
• 併發性不好，沒法同時讀寫數據（添加數據能夠）
• MySQL非正常關閉或死機時會致使索引錯誤，須要使用myisamchk修復，並且當訪問量大時出現很是頻繁。

9、緩存

去年我寫過一篇文章介紹memcached，它就是由LJ的團隊開發的一款緩存工具，以key-value的方式將數據存儲到分佈的內存中。LJ緩存的數據：

• 12臺獨立服務器（不是捐贈的）
• 28個實例
• 30GB總容量
• 90-93%的命中率（用過squid的人可能知道，squid內存加磁盤的命中率大概在70-80%）

如何創建緩存策略？

想緩存全部的東西？那是不可能的，咱們只須要緩存已經或者可能致使系統瓶頸的地方，最大程度的提交系統運行效率。經過對MySQL的日誌的分析咱們能夠找到緩存的對象。

緩存的缺點？

• 沒有完美的事物，緩存也有缺點：
• 增大開發量，須要針對緩存處理編寫特殊的代碼。
• 管理難度增長，須要更多人蔘與系統維護。
• 固然大內存也須要錢。

10、Web訪問負載均衡

在數據包級別使用BIG-IP，但BIG-IP並不知道咱們內部的處理機制，沒法判斷由哪臺服務器對這些請求進行處理。反向代理並不能很好的起到做用，不是已經夠快了，就是達不到咱們想要的效果。

因此，LJ又開發了Perlbal。特色：

• 快，小，可管理的http web 服務器/代理
• 能夠在內部進行轉發
• 使用Perl開發
• 單線程，異步，基於事件，使用epoll , kqueue
• 支持Console管理與http遠程管理，支持動態配置加載
• 多種模式：web服務器，反向代理，插件
• 支持插件：GIF/PNG互換？

11、MogileFS

LJ使用開源的MogileFS做爲分佈式文件存儲系統。MogileFS使用很是簡單，它的主要設計思想是：

• 文件屬於類（類是最小的複製單位）
• 跟蹤文件存儲位置
• 在不一樣主機上存儲
• 使用MySQL集羣統一存儲分佈信息
• 大容易廉價磁盤

原文來自於：http://blog.csdn.net/wangyunpeng0319/article/details/8252796