高併發高流量網站架構詳解

鏡像網站技術
鏡像網站是指將一個徹底相同的站點放到幾個服務器上，分別有本身的URL，這些服務器上的網站互相稱爲鏡像網站。鏡像網站和主站 並無太大差異，或者能夠視爲主站的拷貝。鏡像網站的好處是：若是不能對主站做正常訪問（如服務器故障，網絡故障或者網速太慢等），仍能經過鏡像服務器得到服務。不便之處是：更新網站內容的時候，須要同時更新多個服 務器；須要用戶記憶超過一個網址，或須要用戶選擇訪問多個鏡像網站中的一個，而用戶選擇的，不必定是最優的。在用戶選擇的過程當中，缺少必要的可控性。
在互聯網發展的初期，互聯網上的網站內容不多，並且大都是靜態內容，更新頻率底。但由於服務器運算能力低，帶寬小，網速慢，熱門網站的訪問壓力仍是很大。 鏡像網站技術在這種狀況下做爲一種有效解決方案，被普遍採用。隨着互聯網的發展，愈來愈多的網站使用服務器端腳本動態生成內容，同步更新愈來愈困難，對可 控性要求愈來愈高，鏡像技術由於不能知足這類網站的須要，漸漸的淡出了人們的視線。但有一些大型的軟件下載站，由於符合鏡像網站的條件——下載的內容是靜態的，更新頻率較低，對帶寬，速度要求又比較高， 如國外的SourceForge （http://www.SourceForge.net， 著名開源軟件託管網站），Fedora（http://fedoraproject.org，RedHat 贊助的Linux發行版），國內的華軍軟件園（http://www.onlinedown.net）， 天空軟件站（http://www.skycn.com）等，還在使用這項技術。在網站建設的過程當中，能夠根據實際狀況，將靜態內容做一些鏡像，以加快訪問速度，提高用戶體驗。

CDN內容分發網絡
CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是經過在現有的互聯網中增長一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡「邊緣」，使用戶能夠就近取得 所需的內容，分散服務器的壓力，解決互聯網擁擠的情況，提升用戶訪問網站的響應速度。從而解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均等緣由所形成的 用戶訪問網站響應速度慢的問題。
CDN與鏡像網站技術的不一樣之處在於網站代替用戶去選擇最優的內容服務器，加強了可控制性。CDN實際上是夾在網頁瀏覽者和被訪問的服務器中間的一層鏡像或 者說緩存，瀏覽者訪問時點擊的仍是服務器原來的URL地址，可是看到的內容實際上是對瀏覽者來講最優的一臺鏡像服務器上的頁面緩存內容。這是經過調整服務器 的域名解析來實現的。使用CDN技術的域名解析服務器須要維護一個鏡像服務器列表和一份來訪IP到鏡像服務器的對應表。當一個用戶的請求到來的時候，根據 用戶的IP，查詢對應表，獲得最優的鏡像服務器的IP地址，返回給用戶。這裏的最優，須要綜合考慮服務器的處理能力，帶寬，離訪問者的距離遠近等因素。當 某個地方的鏡像網站流量過大，帶寬消耗過快，或者出現服務器，網絡等故障的時候，能夠很方便的設置將用戶的訪問轉到另一個地方。這樣就加強了可控制性。
CDN網絡加速技術也有它的侷限性。首先，由於內容更新的時候，須要同步更新多臺鏡像服務器，因此它也只適用於內容更新不太頻繁，或者對實時性要求不是很高的網站；其次，DNS解析有緩存，當某 一個鏡像網站的訪問須要轉移時，主DNS服務器更改了IP解析結果，但各地的DNS服務器緩存更新 會滯後一段時間，這段時間內用戶的訪問仍然會指向該服務器，可控制性依然有不足。
目前，國內訪問量較高的大型網站如新浪、網易等的資訊頻道，均使用CDN網絡加速技術，雖然網站的訪問量巨大，但不管在什麼地方訪問，速度都會很 快。但論壇，郵箱等更新頻繁，實時性要求高的頻道，則不適合使用這種技術。

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

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

硬盤級緩存
硬盤級別的緩存是指將須要動態生成的內容暫時緩存在硬盤上，在一個可接受的延遲時間範圍內，一樣的請求再也不動態生成，以達到節約系統資源，提升網站承受能 力的目的。Linux環境下硬盤級緩存通常使用Squid。
Squid是一個高性能的代理緩存服務器。和通常的代理緩存軟件不一樣，Squid用一個單獨的、非模塊化的、I/O驅動的進程來處理全部的客戶端請求。它接受來自客戶端對目標對象的請求並適當地處理這些請求。好比說，用戶經過 瀏覽器想下載（即瀏覽）一個web頁面，瀏覽器請求Squid爲它取得這個頁面。Squid隨之鏈接到頁面所在的原始服務器並向服務器發出取得該頁面的請 求。取得頁面後，Squid再將頁面返回給用戶端瀏覽器，而且同時在Squid本地緩存目錄裏保存一份副本。當下一次有用戶須要同一頁面時，Squid可 以簡單地從緩存中讀取它的副本，直接返回給用戶，而不用再次請求原始服務器。當前的Squid能夠處理HTTP， FTP， GOPHER， SSL和WAIS等協議。

內存級緩存
內存級別的緩存是指將須要動態生成的內容暫時緩存在內存裏，在一個可接受的延遲時間範圍內，一樣的請求再也不動態生成，而是直接從內存中讀取。Linux環 境下內存級緩存Memcached是一個不錯的選擇。
Memcached是一套很是優秀的分佈式內存對象緩存系統，用於在動態系統中減小數據庫負載，提高性能。和 Squid 的前端緩存加速不一樣，它是經過基於內存的對象緩存來減小數據庫查詢的方式改善網站的性能，而其中最吸引人的一個特性就是支持分佈式部署；也就是說能夠在一 羣機器上創建一堆 Memcached 服務，每一個服務能夠根據具體服務器的硬件配置使用不 同大小的內存塊，這樣，理論上能夠創建一個無限大的基於內存的緩存系統。Memcached 是以守護程序方式運行於一個或多個服務器中，隨時接受客戶端的鏈接操做，客戶端能夠由各類語 言編寫，目前已知的客戶端 API 包括 Perl/PHP/Python/Ruby/Java/C#/C 等等[附錄1]。客戶端首先與 Memcached 服務創建鏈接，而後存取對象。每一個被存取的對象都有一個惟一的標識符 key，存取操做均經過這個 key 進行，保存的時候還能夠設置有效期。保存在 Memcached 中的對象其實是放置在內存中的，而不是在硬盤上。Memcached 進程運行以後，會預申請一塊較大的內存空間，本身進行管理，用完以後再申請一塊，而不是每次須要的時候去向操做系統申請。Memcached將對象保存在一個巨大 的Hash表中，它還使用NewHash算法來管理Hash表，從而得到進一步的性能提高。因此當分配給Memcached的內存足夠大的時候，Memcached的時間消耗基本上只是網絡Socket鏈接了［33］。
Memcached也有它的不足。首先它的數據是保存在內存當中的，一旦服務進程重啓（進程意外被關掉，機器重啓等），數據會所有丟失。其次 Memcached以root權限運行，並且Memcached自己沒有任何權限管理和認證功能，安全性不足。第一條是Memcached做爲內存緩存服務使用沒法避免的，固然，若是內存中的數據須要保存，可 以採起更改Memcached的源代碼，增長按期寫入硬盤的功能。對於第二條，咱們能夠將Memcached服務綁定在內網IP上，經過Linux防火牆進行防禦。

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

讀寫分離
若是網站的硬盤讀寫性能是整個網站性能提高的一個瓶頸的話，能夠考慮將硬盤的讀，寫功能分開，分別進行優化。在專門用來寫的硬盤上，咱們能夠在Linux 下使用軟件RAID-0（磁盤冗餘陣列0級）。RAID-0在得到硬盤IO提高的同時， 也會增長整個文件系統的故障率——它等於RAID中全部驅動器的故障率之和。若是 須要保持或提升硬盤的容錯能力，就須要實現軟件RAID-1，4或5，它們能在某一個（甚至幾個）磁盤驅動器故障以後仍然保持整個文件系統的正常運行，但文件讀寫效率不如RAID-0。而專門用來讀的硬盤，則不用如此麻煩，可使用普通的服務器硬盤，以下降開銷。
通常的文件系統，會綜合考慮各類大小和格式的文件的讀，寫效率，於是對特定的文件讀或寫的效率不是最優。若是有必要，能夠經過選擇文件系統，以及修改文件 系統的配置參數來達到對特定文件的讀或寫的效率最大化。好比說，若是文件系統中須要存儲大量的小文件，則可使用ReiserFS來替代Linux操做系統默認的ext3系統，由於 ReiserFS是基於平衡樹的文件系統結構，尤爲對於大量文件的巨型文件系統，搜索速度要比使用局部的二分查找法的ext3快。 ReiserFS裏的目錄是徹底動態分配的，所以不存在ext3中常見的沒法回收巨型目錄佔用的磁盤空間的狀況。ReiserFS裏小文件（< 4K）能夠直接存儲進樹，小文件讀取和寫入的速度更快，樹內節點是按字節對齊的，多個小文件可共享同一個硬盤塊，節約大量空間。ext3使用固定大小的塊 分配策略，也就是說，不到4K的小文件也要佔據4K的空間，致使的空間浪費比較嚴重。 但ReiserFS對不少Linux內核支持的不是很好，包括2.4.三、2.4.9 甚至相對較新的 2.4.16，若是網站想要使用它，就必需要安裝與它配合的較好的2.4.18內核——通常管理員都不是很樂意使用太新的內核，由於在它上面運行的軟件， 都尚未通過大量的實踐測試，也許有一些小的bug尚未被發現，但對於服務器來講，再小的bug也是不能接受的。ReiserFS仍是一個較爲年輕的， 發展迅速的文件系統，它相對於ext3來講有一個很大的缺陷就是，每次ReiserFS文件系統升級的時候，必須徹底從新格式化整個磁盤分區。因此在選擇 使用的時候，須要權衡取捨。