【轉】大訪問量系統的設計（二）——高併發高流量網站架構

時間 2019-11-07

原文原文鏈接

博客分類：

大訪問量、高併發

目錄
1.網絡層架構
1.1 鏡像網站技術
1.2 CDN內容分發網絡——調整服務器的域名解析來實現
1.3 應用層分佈式設計——查詢、定向

2.交換層架構
2.1 第四層交換簡介
2.2 硬件實現
2.3 軟件實現——LVS，負載均衡

3.應用程序層優化
3.1 網站服務器程序的選擇
3.2 數據庫選擇——mysqL主輔、集羣設計
3.3 服務器端腳本解析器的選擇——JSP、PHP、ASP
3.4 可配置性
3.5 封裝和中間層思想

4.服務器優化（接收請求的服務器優化）
4.1 Socket優化——調相關內核參數，再用命令檢測效果
4.2 硬盤級緩存——squid
4.3 內存級緩存——memcached
4.4 CPU與IO均衡
4.5 讀寫分離——文件系統改進

5.擴容、容錯處理
5.1 擴容
5.2 容錯

1.網絡層架構
1.1 鏡像網站技術
    鏡像網站是指將一個徹底相同的站點放到幾個服務器上，分別有本身的URL，這些服務器上的網站互相稱爲鏡像網站［13］。鏡像網站和主站並無太大差異，或者能夠視爲主站的拷貝。鏡像網站的好處是：若是不能對主站做正常訪問（如服務器故障，網絡故障或者網速太慢等），仍能經過鏡像服務器得到服務。不便之處是：更新網站內容的時候，須要同時更新多個服務器；須要用戶記憶超過一個網址，或須要用戶選擇訪問多個鏡像網站中的一個，而用戶選擇的，不必定是最優的。在用戶選擇的過程當中，缺少必要的可控性。

          在互聯網發展的初期，互聯網上的網站內容不多，並且大都是靜態內容，更新頻率底。但由於服務器運算能力低，帶寬小，網速慢，熱門網站的訪問壓力仍是很大。鏡像網站技術在這種狀況下做爲一種有效解決方案，被普遍採用。隨着互聯網的發展，愈來愈多的網站使用服務器端腳本動態生成內容，同步更新愈來愈困難，對可控性要求愈來愈高，鏡像技術由於不能知足這類網站的須要，漸漸的淡出了人們的視線。但有一些大型的軟件下載站，由於符合鏡像網站的條件——下載的內容是靜態的，更新頻率較低，對帶寬，速度要求又比較高，如國外的SourceForge （ http://www.SourceForge.net，著名開源軟件託管網站），Fedora（ http://fedoraproject.org，RedHat贊助的Linux發行版），國內的華軍軟件園（ http://www.onlinedown.net），天空軟件站（ http://www.skycn.com）等，還在使用這項技術（圖1）。

1.2 CDN內容分發網絡

          CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是經過在現有的互聯網中增長一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡「邊緣」，使用戶能夠就近取得所需的內容，分散服務器的壓力，解決互聯網擁擠的情況，提升用戶訪問網站的響應速度。從而解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均等緣由所形成的用戶訪問網站響應速度慢的問題［14］。

          CDN與鏡像網站技術的不一樣之處在於網站代替用戶去選擇最優的內容服務器，加強了可控制性。CDN實際上是夾在網頁瀏覽者和被訪問的服務器中間的一層鏡像或者說緩存，瀏覽者訪問時點擊的仍是服務器原來的URL地址，可是看到的內容實際上是對瀏覽者來講最優的一臺鏡像服務器上的頁面緩存內容。這是經過調整服務器的域名解析來實現的。使用CDN技術的域名解析服務器須要維護一個鏡像服務器列表和一份來訪IP到鏡像服務器的對應表。當一個用戶的請求到來的時候，根據用戶的IP，查詢對應表，獲得最優的鏡像服務器的IP地址，返回給用戶。這裏的最優，須要綜合考慮服務器的處理能力，帶寬，離訪問者的距離遠近等因素。當某個地方的鏡像網站流量過大，帶寬消耗過快，或者出現服務器，網絡等故障的時候，能夠很方便的設置將用戶的訪問轉到另一個地方（圖2）。這樣就加強了可控制性。

CDN網絡加速技術也有它的侷限性。首先，由於內容更新的時候，須要同步更新多臺鏡像服務器，因此它也只適用於內容更新不太頻繁，或者對實時性要求不是很高的網站；其次，DNS解析有緩存，當某一個鏡像網站的訪問須要轉移時，主DNS服務器更改了IP解析結果，但各地的DNS服務器緩存更新會滯後一段時間，這段時間內用戶的訪問仍然會指向該服務器，可控制性依然有不足。

目前，國內訪問量較高的大型網站如新浪、網易等的資訊頻道，均使用CDN網絡加速技術（圖3），雖然網站的訪問量巨大，但不管在什麼地方訪問，速度都會很快。但論壇，郵箱等更新頻繁，實時性要求高的頻道，則不適合使用這種技術。

1.3 應用層分佈式設計

          新浪播客爲了得到CDN網絡加速的優勢，又必須避免CDN的不足，在應用層軟件設計上，採起了一個替代的辦法。新浪播客提供了一個供播放器查詢視頻文件地址的接口。當用戶打開視頻播放頁面的時候，播放器首先鏈接查詢接口，經過接口得到視頻文件所在的最優的鏡像服務器地址，而後再到該服務器去下載視頻文件。這樣，用一次額外的查詢得到了所有的控制性，而此次查詢的通信流量很是小，幾乎能夠忽略不計。CDN中由域名解析得到的靈活性也保留了下來：由接口程序維護鏡像網站列表及來訪IP到鏡像網站的對應表便可。鏡像網站中不須要鏡像全部的內容，而是隻鏡像更新速度較慢的視頻文件。這是徹底能夠承受的。

網絡層架構小結

          從整個互聯網絡的高度來看網站架構，努力的方向是明確的：讓用戶就近取得內容，但又要在速度和可控制性之間做一個平衡。對於更新比較頻繁內容，因爲難以保持鏡像網站之間的同步，則須要使用其餘的輔助技術。

2.交換層架構
2.1 第四層交換簡介

第四層交換的一個簡單定義是：它是一種傳輸功能，它決定傳輸不只僅依據MAC地址(第二層網橋)或源/目標IP地址(第三層路由)，並且依據IP 地址與 TCP/UDP (第四層) 應用端口號的組合（Socket）［17］。第四層交換功能就像是虛擬IP，指向實際的服務器。它傳輸的數據支持多種協議，有HTTP、FTP、NFS、 Telnet等。

          以HTTP協議爲例，在第四層交換中爲每一個服務器組設立一個虛擬IP（Virtue IP，VIP），每組服務器支持某一個或幾個域名。在域名服務器（DNS）中存儲服務器組的VIP，而不是某一臺服務器的真實地址。

          當用戶請求頁面時，一個帶有目標服務器組的VIP鏈接請求發送給第四層交換機。第四層交換機使用某種選擇策略，在組中選取最優的服務器，將數據包中的目標 VIP地址用實際服務器的IP地址取代，並將鏈接請求傳給該服務器。第四層交換通常都實現了會話保持功能，即同一會話的全部的包由第四層交換機進行映射後，在用戶和同一服務器間進行傳輸
2.2 硬件實現

2.3 軟件實現

軟件四層交換經常使用的有 Linux上的LVS（Linux Virtual Server），它提供了基於心跳（heart beat）的實時災難應對解決方案，提升了系統的魯棒性，同時提供了靈活的VIP配置和管理功能，能夠同時知足多種應用需求

3.應用程序層優化
3.1 網站服務器程序的選擇

經統計［40］，當前互聯網上有超過50%的網站主機使用Apache［41］服務器程序。 Apache是開源界的首選Web服務器，由於它的強大和可靠，並且適用於絕大部分的應用場合。可是它的強大有時候卻顯得笨重，配置文件複雜得讓人望而生畏，高併發狀況下效率不過高。而輕量級的Web服務器Lighttpd［42］倒是後起之秀，基於單進程多路複用技術，其靜態文件的響應能力遠高於 Apache。 Lighttpd對PHP的支持也很好，還能夠經過Fastcgi方式支持其餘的語言，好比Python等。雖然Lighttpd是輕量級的服務器，功能上不能跟Apache比，某些複雜應用沒法勝任，但即便是大部份內容動態生成的網站，仍免不了會有一些靜態元素，好比圖片、JS腳本、CSS等等，能夠考慮將Lighttpd放在Squid的前面，構成 Lighttpd->Squid->Apache的一條處理鏈，Lighttpd在最前面，專門處理靜態內容的請求，把動態內容請求經過 Proxy模塊轉發給Squid，若是Squid中有該請求的內容且沒有過時，則直接返回給Lighttpd。新請求或者過時的頁面請求交由Apache 中的腳本程序來處理。通過Lighttpd和Squid的兩級過濾，Apache須要處理的請求大大減小，減小了Web應用程序的壓力。同時這樣的構架，便於把不一樣的處理分散到多臺計算機上進行，由Lighttpd在前面統一分發。

在這種架構下，每一級都是能夠進行單獨優化的，好比Lighttpd能夠採用異步IO方式，Squid能夠啓用內存來緩存，Apache能夠啓用MPM （Multi -Processing Modules，多道處理模塊）等，而且每一級均可以使用多臺機器來均衡負載，伸縮性好。

著名視頻分享網站YouTube就是選擇使用Lighttpd做爲網站的前臺服務器程序。

3.2 數據庫選擇
MySQL提供多種後臺存儲引擎的選擇，如MyISAM， Heap， InnoDB，Berkeley Db等。缺省格式爲MyISAM。 MyISAM 存儲引擎與磁盤兼容的很是好

主輔結構

MySQL也有一些它自身的缺陷，如缺少圖形界面，缺少存儲過程，還不支持觸發器，參照完整性，子查詢和數據表視圖等，但這些功能都在開發者的TO-DO列表當中。這就是開源的力量：你永遠能夠期待更好。

國外的Yahoo!，國內的新浪，搜狐等不少大型商業網站都使用MySQL 做爲後臺數據庫。對於通常的網站系統，不管從成本仍是性能上考慮，MySQL應該是最佳的選擇。

3.3 服務器端腳本解析器的選擇

3.4 可配置性

3.5 封裝和中間層思想

4.服務器優化
常見的影響服務器的處理速度的因素有：網絡鏈接，硬盤讀寫，內存空間，CPU速度。

4.1 Socket優化
GNU/Linux 提供了不少可調節的內核參數，可使用這些參數爲服務器進行動態配置，包括影響 Socket 性能的一些重要的選項。這些選項包含在 /proc 虛擬文件系統中。這個文件系統中的每一個文件都表示一個或多個參數，它們能夠經過 cat 工具進行讀取，或使用 echo 命令進行修改。這裏僅列出一些影響TCP/IP 棧性能的可調節內核參數

若是重啓了 GNU/Linux 系統，設置的內核參數都會恢復成默認值。爲了將所設置的值做爲這些參數的默認值，可使用 /etc/rc.local 文件，在系統每次啓動時自動將這些參數配置成所須要的值。

4.2 硬盤級緩存——squid
硬盤級別的緩存是指將須要動態生成的內容暫時緩存在硬盤上，在一個可接受的延遲時間範圍內，一樣的請求再也不動態生成，以達到節約系統資源，提升網站承受能力的目的。Linux環境下硬盤級緩存通常使用Squid。當前的Squid能夠處理HTTP， FTP， GOPHER， SSL和WAIS等協議。
Squid默認經過檢測HTTP協議頭的Expires和 Cache-Control字段來決定緩存的時間。

Squid 運行的時候，默認會在硬盤上建兩層hash目錄，用來存儲緩存的Object。它還會在內存中創建一個Hash Table，用來記錄硬盤中Object分佈的狀況。若是Squid配置成爲一個Squid集羣中的一個的話，它還會創建一個 Digest Table(摘要表)，用來存儲其它 Squid 上的Object摘要。當用戶端想要的資料本地硬盤上沒有時，能夠很快的知道應該去集羣中的哪一臺機器得到。在硬盤空間快要達到配置限額的時候，能夠配置使用某種策略（默認使用LRU：Least Recently Used-最近最少用）刪除一些Object，從而騰出空間

集羣中的Squid Server 之間能夠有兩種關係：第一種關係是：Child 和 Parent。當 Child Squid Server 沒有資料時，會直接向 Parent Squid Server 要資料，而後一直等，直到 Parent 給它資料爲止。第二種關係是：Sibling 和 Sibling。當 Squid Server 沒有資料時，會先向 Sibling 的 Squid Server 要資料，若是 Sibling 沒資料，就跳過它向 Parent 要或直接上原始網站去拿。

默認配置的Squid，沒有通過任何優化的時候，通常能夠達到 50% 的命中率［30］（圖4）。若是須要，還能夠經過參數優化，拆分業務，優化文件系統等辦法，使得Squid達到 90% 以上的緩存命中率。 Squid處理TCP鏈接消耗的服務器資源比真正的HTTP服務器要小的多，當Squid分擔了大部分鏈接，網站的承壓能力就大大加強了。

4.3 內存級緩存——memcached
Memcached也有它的不足。首先它的數據是保存在內存當中的，一旦服務進程重啓（進程意外被關掉，機器重啓等），數據會所有丟失。其次 Memcached以root權限運行，並且Memcached自己沒有任何權限管理和認證功能，安全性不足。第一條是Memcached做爲內存緩存服務使用沒法避免的，固然，若是內存中的數據須要保存，能夠採起更改Memcached的源代碼，增長按期寫入硬盤的功能。對於第二條，咱們能夠將 Memcached服務綁定在內網IP上，經過Linux防火牆進行防禦。

4.4 CPU與IO均衡
在一個網站提供的全部功能中，有的功能可能須要消耗大量的服務器端IO資源，像下載，視頻播放等，而有的功能則可能須要消耗大量的服務器CPU資源，像視頻格式轉換，LOG統計等。在一個服務器集羣中，當咱們發現某些機器上CPU和IO的利用率相差很大的時候，例如CPU負載很高而IO負責很低，咱們能夠考慮將該服務器上的某些耗CPU資源的進程換成耗IO的進程，以達到均衡的目的。均衡每一臺機器的CPU和IO消耗，不只能夠得到更充分的服務器資源利用，並且還可以支持暫時的過載，遇到突發事件，訪問流量劇增的時候，實現得體的性能降低(Graceful performance degradation)［34］，而不是當即崩潰。

4.5 讀寫分離

總結
對於一個高併發高流量的網站來講，任何一個環節的瓶頸都會形成網站性能的降低，影響用戶體驗，進而形成巨大的經濟損失。在全互聯網層面，應該使用分佈式設計，縮短網站與用戶的網絡距離，減小主幹網上的流量，以及防止在網絡意外狀況下網站沒法訪問的問題。在局域網層面，應該使用服務器集羣，一方面可以支撐更大的訪問量，另外一方面也做爲冗餘備份，防止服務器故障致使的網站沒法訪問。在單服務器層面，應該配置操做系統，文件系統及應用層軟件，均衡各類資源的消耗，消除系統性能瓶頸，充分發揮服務器的潛能。在應用層，能夠經過各類緩存來提高程序的效率，減小服務器資源消耗（圖6）。另外，還須要合理設計應用層程序，爲之後的需求變動，擴容作好準備。