網站千萬級訪問量優化服務器負載方案

*一、HTML 靜態化
其實你們都知道，效率最高、消耗最小的就是純靜態化的 html 頁面，因此咱們儘量使咱們的網站上的頁面採用靜態頁面來實現，這個最簡單 的方法其實也是最有效的方法。可是對於大量內容而且頻繁更新的網站，咱們無 法所有手動去挨個實現，因而出現了咱們常見的信息發佈系統 CMS，像咱們常 訪問的各個門戶站點的新聞頻道，甚至他們的其餘頻道，都是經過信息發佈系統 來管理和實現的，信息發佈系統能夠實現最簡單的信息錄入自動生成靜態頁面， 還能具有頻道管理、權限管理、自動抓取等功能，對於一個大型網站來講，擁有 一套高效、可管理的 CMS 是必不可少的。除了門戶和信息發佈類型的網站，對 於交互性要求很高的社區類型網站來講， 儘量的靜態化也是提升性能的必要手 段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再從新靜態化也是 大量使用的策略，像 Mop 的大雜燴就是使用了這樣的策略，網易社區等也是如 此。同時，html 靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用數 據庫查詢可是內容更新很小的應用，能夠考慮使用 html 靜態化來實現，好比論 壇中論壇的公用設置信息， 這些信息目前的主流論壇均可以進行後臺管理而且存 儲再數據庫中，這些信息其實大量被前臺程序調用，可是更新頻率很小，能夠考 慮將這部份內容進行後臺更新的時候進行靜態化， 這樣避免了大量的數據庫訪問 請求。

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

*三、數據庫集羣和庫表散列
大型網站都有複雜的應用，這些應用必須使用數據庫， 那麼在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫 將很快沒法知足應用，因而咱們須要使用數據庫集羣或者庫表散列。在數據庫集 羣方面，不少數據庫都有本身的解決方案，Oracle、Sybase 等都有很好的方案， 經常使用的 MySQL 提供的 Master/Slave 也是相似的方案，您使用了什麼樣的 DB，就 參考相應的解決方案來實施便可。上面提到的數據庫集羣因爲在架構、成本、擴 張性方面都會受到所採用 DB 類型的限制，因而咱們須要從應用程序的角度來考 慮改善系統架構，庫表散列是經常使用而且最有效的解決方案。咱們在應用程序中安 裝業務和應用或者功能模塊將數據庫進行分離， 不一樣的模塊對應不一樣的數據庫或 者表，再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，好比用戶 表，按照用戶 ID 進行表散列，這樣就可以低成本的提高系統的性能而且有很好 的擴展性。sohu 的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等 信息進行數據庫分離，而後對帖子、用戶按照板塊和 ID 進行散列數據庫和表， 最終能夠在配置文件中進行簡單的配置便能讓系統隨時增長一臺低成本的數據 庫進來補充系統性能。

*四、緩存
緩存一詞搞技術的都接觸過，不少地方用到緩存。網站架構和網站開發 中的緩存也是很是重要。這裏先講述最基本的兩種緩存。高級和分佈式的緩存在 後面講述。架構方面的緩存，對 Apache 比較熟悉的人都能知道Apache 提供了自 己的緩存模塊，也可使用外加的 Squid 模塊進行緩存，這兩種方式都可以有效 的提升Apache 的訪問響應能力。網站程序開發方面的緩存，Linux 上提供的 Memory Cache 是經常使用的緩存接口，能夠在 web 開發中使用，好比用 Java 開發的 時候就能夠調用 MemoryCache 對一些數據進行緩存和通信共享， 一些大型社區使 用了這樣的架構。另外，在使用 web 語言開發的時候，各類語言基本都有本身的 緩存模塊和方法， PHP 有 Pear 的 Cache 模塊， Java 就更多了， .net 不是很熟悉， 相信也確定有。

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

*六、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極 解決辦法。 負載均衡技術發展了多年， 有不少專業的服務提供商和產品能夠選擇， 我我的接觸過一些解決方法，其中有兩個架構能夠給你們作參考。

*七、硬件四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用 區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。 第四層交換功能就象是虛 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 參數設置，對 於系統性能的影響就會很大，但願你們一塊兒討論，達到拋磚引玉之效。 用 squid 作 web cache server，而 apache 在 squid 的後面提供真正的 web 服務。 固然使用這樣的架構必需要保證主頁上大部分都是靜態頁面。 這就須要程序員的 配合將頁面在反饋給客戶端以前將頁面所有轉換成靜態頁面。 基本看出 sina 和 sohu 對於頻道等欄目都用了相同的技術， squid 來監聽這些 即 IP 的 80 端口，而真正的 web server 來監聽另一個端口。從用戶的感受上來 說不會有任何的區別，而相對於將 web server 直接和客戶端連在一塊兒的方式， 這樣的方式明顯的節省的帶寬和服務器。用戶訪問的速度感受也會更快。