本文圍繞高并發(fā)高流量的網(wǎng)站架構(gòu)設(shè)計問題，主要研究討論了以下內(nèi)容：

    首先在整個網(wǎng)絡(luò)的高度討論了使用鏡像網(wǎng)站，CDN內(nèi)容分發(fā)網(wǎng)絡(luò)等技術(shù)對負載均衡帶來的便利及各自的優(yōu)缺點比較。然后在局域網(wǎng)層次對第四層交換技術(shù)，包括硬件解決方案F5和軟件解決方案LVS，進行了簡單的討論。接下來在單服務器層次，本文著重討論了單臺服務器的Socket優(yōu)化，硬盤級緩存技術(shù)，內(nèi)存級緩存技術(shù)，CPU與IO平衡技術(shù)（即以運算為主的程序與以數(shù)據(jù)讀寫為主的程序搭配部署），讀寫分離技術(shù)等。在應用層，本文介紹了一些大型網(wǎng)站常用的技術(shù)，以及選擇使用該技術(shù)的理由。最后，在架構(gòu)的高度討論了網(wǎng)站擴容，容錯等問題。

本文以理論與實踐相結(jié)合的形式，結(jié)合作者實際工作中得到的經(jīng)驗，具有較廣泛的適用性。

1 引言

1.1 互聯(lián)網(wǎng)的發(fā)展
最近十年間，互聯(lián)網(wǎng)已經(jīng)從一個單純的用于科研的，用來傳遞靜態(tài)文檔的美國內(nèi)部網(wǎng)絡(luò)，發(fā)展成了一個應用于各行各業(yè)的，傳送著海量多媒體及動態(tài)信息的全球網(wǎng)絡(luò)。從規(guī)模上看，互聯(lián)網(wǎng)在主機數(shù)、帶寬、上網(wǎng)人數(shù)等方面幾乎一直保持著指數(shù)增長的趨勢，2006年7月，互聯(lián)網(wǎng)上共有主機439，286，364臺，WWW 站點數(shù)量達到 96，854，877個 ［1］。全球上網(wǎng)人口在2004 年達到 7 億 2900萬 ［2］，中國的上網(wǎng)人數(shù)在 2006 年 12 月達到了約 1億3700 萬［3］。另一方面，互聯(lián)網(wǎng)所傳遞的內(nèi)容也發(fā)生了巨大的變化，早期互聯(lián)網(wǎng)以靜態(tài)、文本的公共信息為主要內(nèi)容，而目前的互聯(lián)網(wǎng)則傳遞著大量的動態(tài)、多媒體及人性化的信息，人們不僅可以通過 互聯(lián)網(wǎng)閱讀到動態(tài)生成的信息，而且可以通過它使用電子商務、即時通信、網(wǎng)上游戲等交互性很強的服務。因此，可以說互聯(lián)網(wǎng)已經(jīng)不再僅僅是一個信息共享網(wǎng)絡(luò)，而已經(jīng)成為了一個無所不在的交互式服務的平臺。

1.2 互聯(lián)網(wǎng)網(wǎng)站建設(shè)的新趨勢

互聯(lián)網(wǎng)不斷擴大的規(guī)模，日益增長的用戶群，以及web2.0［4］的興起，對互聯(lián)網(wǎng)網(wǎng)站建設(shè)提出了新的要求:

高性能和高可擴展性。2000 年 5 月，訪問量排名世界第一（統(tǒng)計數(shù)據(jù)來源［5］）的Yahoo ［6］聲稱其日頁瀏覽數(shù)達到 6 億 2500 萬，即每秒約 30，000 次HTTP 請求(按每個頁面瀏覽平均產(chǎn)生 4 次請求計算) 。這樣大規(guī)模的訪問量對服務的性能提出了非常高的要求。更為重要的是， 互聯(lián)網(wǎng)受眾的廣泛性，使得成功的互聯(lián)網(wǎng)服務的訪問量增長潛力和速度非常大，因此服務系統(tǒng)必須具有非常好的可擴展性，以應付將來可能的服務增長。

支持高度并發(fā)的訪問。高度并發(fā)的訪問對服務的存儲與并發(fā)能力提出了很高的要求，當前主流的超標量和超流水線處理器能處理的并發(fā)請求數(shù)是有限的，因為隨著并發(fā)數(shù)的上升，進程調(diào)度的開銷會很快上升?；ヂ?lián)網(wǎng)廣域網(wǎng)的本質(zhì)決定了其訪問的延遲時間較長，因此一個請求完成時間也較長，按從請求產(chǎn)生到頁面下載完成 3 秒計算， Yahoo 在 2000 年 5 月時平均有 90，000 個并發(fā)請求。而且對于較復雜的服務，服務器往往要維護用戶會話的信息，例如一個互聯(lián)網(wǎng)網(wǎng)站如果每天有 100 萬次用戶會話，每次 20分鐘的話，那平均同時就會有約 14000 個并發(fā)會話。

高可用性?；ヂ?lián)網(wǎng)服務的全球性決定了其每天 24 小時都會有用戶訪問，因此任何服務的停止都會對用戶造成影響。而對于電子商務等應用，暫時的服務中止則意味著客戶的永久失去及大量的經(jīng)濟損失，例如ebay.com［7］1999 年 6 月的一次 22小時的網(wǎng)站不可訪問，對此網(wǎng)站的 380萬用戶的忠誠度造成巨大影響，使得 Ebay 公司不得不支付了近500萬美元用于補償客戶的損失，而該公司的市值同期下降了 40 億美元［8］。因此，關(guān)鍵互聯(lián)網(wǎng)應用的可用性要求非常高。

1.3 新浪播客的簡介

以YouTube［9］為代表的微視頻分享網(wǎng)站近來方興未艾，僅2006年一年，國內(nèi)就出現(xiàn)近百家仿YouTube的微視頻分享網(wǎng)站［10］，試圖復制YouTube的成功模式。此類網(wǎng)站可以說是Web2.0概念下的代表網(wǎng)站，具有Web2.0網(wǎng)站所有典型特征：高并發(fā)，高流量，數(shù)據(jù)量大，邏輯復雜，用戶分散等等。新浪［11］作為國內(nèi)最大的門戶網(wǎng)站，在2005年成功運作新浪博客的基礎(chǔ)上，于2006年底推出了新浪播客服務。新浪播客作為國內(nèi)門戶網(wǎng)站中第一個微視頻分享服務的網(wǎng)站，依靠新浪網(wǎng)站及新浪博客的巨大人氣資源，在推出后不到半年的時間內(nèi)，取得了巨大的成功：同類網(wǎng)站中上傳視頻數(shù)量第一、流量增長最快、用戶數(shù)最多［12］，所有這些成績的取得的背后，是巨大的硬件投入，良好的架構(gòu)支撐和靈活的應用層軟件設(shè)計。

在互聯(lián)網(wǎng)發(fā)展的初期，互聯(lián)網(wǎng)上的網(wǎng)站內(nèi)容很少，而且大都是靜態(tài)內(nèi)容，更新頻率底。但因為服務器運算能力低，帶寬小，網(wǎng)速慢，熱門網(wǎng)站的訪問壓力還是很大。鏡像網(wǎng)站技術(shù)在這種情況下作為一種有效解決方案，被廣泛采用。隨著互聯(lián)網(wǎng)的發(fā)展，越來越多的網(wǎng)站使用服務器端腳本動態(tài)生成內(nèi)容，同步更新越來越困難，對可控性要求越來越高，鏡像技術(shù)因為不能滿足這類網(wǎng)站的需要，漸漸的淡出了人們的視線。但有一些大型的軟件下載站，因為符合鏡像網(wǎng)站的條件——下載的內(nèi)容是靜態(tài)的，更新頻率較低，對帶寬，速度要求又比較高，如國外的SourceForge （http://www.SourceForge.net，著名開源軟件托管網(wǎng)站），F(xiàn)edora（http://，RedHat贊助的Linux發(fā)行版），國內(nèi)的華軍軟件園（http://www.onlinedown.net），天空軟件站（http://www.）等，還在使用這項技術(shù)（圖1）。

圖1 上圖：天空軟件站首頁的鏡像選擇頁面

下圖：SourceForge下載時的鏡像選擇頁面

在網(wǎng)站建設(shè)的過程中，可以根據(jù)實際情況，將靜態(tài)內(nèi)容作一些鏡像，以加快訪問速度，提升用戶體驗。

2.2 CDN內(nèi)容分發(fā)網(wǎng)絡(luò)

    CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。其目的是通過在現(xiàn)有的互聯(lián)網(wǎng)中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)“邊緣”，使用戶可以就近取得所需的內(nèi)容，分散服務器的壓力，解決互聯(lián)網(wǎng)擁擠的狀況，提高用戶訪問網(wǎng)站的響應速度。從而解決由于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點分布不均等原因所造成的用戶訪問網(wǎng)站響應速度慢的問題［14］。

    CDN與鏡像網(wǎng)站技術(shù)的不同之處在于網(wǎng)站代替用戶去選擇最優(yōu)的內(nèi)容服務器，增強了可控制性。CDN其實是夾在網(wǎng)頁瀏覽者和被訪問的服務器中間的一層鏡像或者說緩存，瀏覽者訪問時點擊的還是服務器原來的URL地址，但是看到的內(nèi)容其實是對瀏覽者來說最優(yōu)的一臺鏡像服務器上的頁面緩存內(nèi)容。這是通過調(diào)整服務器的域名解析來實現(xiàn)的。使用CDN技術(shù)的域名解析服務器需要維護一個鏡像服務器列表和一份來訪IP到鏡像服務器的對應表。當一個用戶的請求到來的時候，根據(jù)用戶的IP，查詢對應表，得到最優(yōu)的鏡像服務器的IP地址，返回給用戶。這里的最優(yōu)，需要綜合考慮服務器的處理能力，帶寬，離訪問者的距離遠近等因素。當某個地方的鏡像網(wǎng)站流量過大，帶寬消耗過快，或者出現(xiàn)服務器，網(wǎng)絡(luò)等故障的時候，可以很方便的設(shè)置將用戶的訪問轉(zhuǎn)到另外一個地方（圖2）。這樣就增強了可控制性。

圖2 CDN原理示意圖

CDN網(wǎng)絡(luò)加速技術(shù)也有它的局限性。首先，因為內(nèi)容更新的時候，需要同步更新多臺鏡像服務器，所以它也只適用于內(nèi)容更新不太頻繁，或者對實時性要求不是很高的網(wǎng)站；其次，DNS解析有緩存，當某一個鏡像網(wǎng)站的訪問需要轉(zhuǎn)移時，主DNS服務器更改了IP解析結(jié)果，但各地的DNS服務器緩存更新會滯后一段時間，這段時間內(nèi)用戶的訪問仍然會指向該服務器，可控制性依然有不足。

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

圖3 新浪網(wǎng)使用ChinaCache CDN服務。

ChinaCache的服務節(jié)點全球超過130個，

其中中國節(jié)點超過80個，

覆蓋全國主要6大網(wǎng)絡(luò)的主要省份［15］。

2.3 應用層分布式設(shè)計
新浪播客為了獲得CDN網(wǎng)絡(luò)加速的優(yōu)點，又必須避免CDN的不足，在應用層軟件設(shè)計上，采取了一個替代的辦法。新浪播客提供了一個供播放器查詢視頻文件地址的接口。當用戶打開視頻播放頁面的時候，播放器首先連接查詢接口，通過接口獲得視頻文件所在的最優(yōu)的鏡像服務器地址，然后再到該服務器去下載視頻文件。這樣，用一次額外的查詢獲得了全部的控制性，而這次查詢的通訊流量非常小，幾乎可以忽略不計。CDN中由域名解析獲得的靈活性也保留了下來：由接口程序維護鏡像網(wǎng)站列表及來訪IP到鏡像網(wǎng)站的對應表即可。鏡像網(wǎng)站中不需要鏡像所有的內(nèi)容，而是只鏡像更新速度較慢的視頻文件。這是完全可以承受的。

2.4 網(wǎng)絡(luò)層架構(gòu)小結(jié)
從整個互聯(lián)網(wǎng)絡(luò)的高度來看網(wǎng)站架構(gòu)，努力的方向是明確的：讓用戶就近取得內(nèi)容，但又要在速度和可控制性之間作一個平衡。對于更新比較頻繁內(nèi)容，由于難以保持鏡像網(wǎng)站之間的同步，則需要使用其他的輔助技術(shù)。

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

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

當用戶請求頁面時，一個帶有目標服務器組的VIP連接請求發(fā)送給第四層交換機。第四層交換機使用某種選擇策略，在組中選取最優(yōu)的服務器，將數(shù)據(jù)包中的目標VIP地址用實際服務器的IP地址取代，并將連接請求傳給該服務器。第四層交換一般都實現(xiàn)了會話保持功能，即同一會話的所有的包由第四層交換機進行映射后，在用戶和同一服務器間進行傳輸［18］。

第四層交換按實現(xiàn)分類，分為硬件實現(xiàn)和軟件實現(xiàn)。

3.2 硬件實現(xiàn)
第四層交換的硬件實現(xiàn)一般都由專業(yè)的硬件廠商作為商業(yè)解決方案提供。常見的有Alteon［19］，F(xiàn)5［20］等。這些產(chǎn)品非常昂貴，但是能夠提供非常優(yōu)秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了［21］。鑒于條件關(guān)系，這里不展開討論。

3.3 軟件實現(xiàn)
第四層交換也可以通過軟件實現(xiàn)，不過性能比專業(yè)硬件稍差，但是滿足一定量的壓力還是可以達到的，而且軟件實現(xiàn)配置起來更靈活。 軟件四層交換常用的有Linux上的LVS（Linux Virtual Server），它提供了基于心跳（heart beat）的實時災難應對解決方案，提高了系統(tǒng)的魯棒性，同時提供了靈活的VIP配置和管理功能，可以同時滿足多種應用需求［22］。

4.2 Socket優(yōu)化
以標準的 GNU/Linux 為例。GNU/Linux 發(fā)行版試圖對各種部署情況都進行優(yōu)化，這意味著對具體服務器的執(zhí)行環(huán)境來說，標準的發(fā)行版可能并不是最優(yōu)化的［23］。GNU/Linux 提供了很多可調(diào)節(jié)的內(nèi)核參數(shù)，可以使用這些參數(shù)為服務器進行動態(tài)配置，包括影響 Socket 性能的一些重要的選項。這些選項包含在 /proc 虛擬文件系統(tǒng)中。這個文件系統(tǒng)中的每個文件都表示一個或多個參數(shù)，它們可以通過 cat 工具進行讀取，或使用 echo 命令進行修改。這里僅列出一些影響TCP/IP 棧性能的可調(diào)節(jié)內(nèi)核參數(shù)［24］：

/proc/sys/net/ipv4/tcp_window_scaling “1”（1表示啟用該選項，0表示關(guān)閉，下同） 啟用 RFC［25］ 1323［26］ 定義的 window scaling；要支持超過 64KB 的窗口，必須啟用該值。

/proc/sys/net/ipv4/tcp_sack “1”啟用有選擇的應答（Selective Acknowledgment），通過有選擇地應答亂序接收到的報文來提高性能（這樣可以讓發(fā)送者只發(fā)送丟失的報文段）；對于廣域網(wǎng)通信來說，這個選項應該啟用，但是這也會增加對 CPU 的占用。

/proc/sys/net/ipv4/tcp_timestamps “1” 以一種比重發(fā)超時更精確的方法（參閱 RFC 1323）來啟用對 RTT 的計算；為了實現(xiàn)更好的性能應該啟用這個選項。

/proc/sys/net/ipv4/tcp_mem “24576 32768 49152” 確定 TCP 棧應該如何反映內(nèi)存使用；每個值的單位都是內(nèi)存頁（通常是 4KB）。第一個值是內(nèi)存使用的下限。第二個值是內(nèi)存壓力模式開始對緩沖區(qū)使用應用壓力的上限。第三個值是內(nèi)存上限。超過這個上限時可以將報文丟棄，從而減少對內(nèi)存的使用。

/proc/sys/net/ipv4/tcp_wmem “4096 16384 131072” 為自動調(diào)優(yōu)定義每個 socket 使用的內(nèi)存。第一個值是為 socket 的發(fā)送緩沖區(qū)分配的最少字節(jié)數(shù)。第二個值是默認值（該值會被 wmem_default 覆蓋），緩沖區(qū)在系統(tǒng)負載不重的情況下可以增長到這個值。第三個值是發(fā)送緩沖區(qū)空間的最大字節(jié)數(shù)（該值會被 wmem_max 覆蓋）。

/proc/sys/net/ipv4/tcp_westwood “1” 啟用發(fā)送者端的擁塞控制算法，它可以維護對吞吐量的評估，并試圖對帶寬的整體利用情況進行優(yōu)化；對于 WAN 通信來說應該啟用這個選項。

與其他調(diào)優(yōu)努力一樣，最好的方法實際上就是不斷進行實驗。具體應用程序的行為、處理器的速度以及可用內(nèi)存的多少都會影響到這些參數(shù)對性能作用的效果。在某些情況中，一些認為有益的操作可能恰恰是有害的（反之亦然）。因此，需要逐一試驗各個選項，然后檢查每個選項的結(jié)果，最后得出最適合具體機器的一套參數(shù)。

如果重啟了 GNU/Linux 系統(tǒng)，設(shè)置的內(nèi)核參數(shù)都會恢復成默認值。為了將所設(shè)置的值作為這些參數(shù)的默認值，可以使用 /etc/rc.local 文件，在系統(tǒng)每次啟動時自動將這些參數(shù)配置成所需要的值。

在檢測每個選項的更改帶來的效果的時候，GNU/Linux上有一些非常強大的工具可以使用：

ping 這是用于檢查主機的可用性的最常用的工具，也可以用于計算網(wǎng)絡(luò)帶寬延時。

traceroute 打印連接到特定網(wǎng)絡(luò)主機所經(jīng)過的一系列路由器和網(wǎng)關(guān)的路徑（路由），從而確定每個 hop 之間的延時。

netstat 確定有關(guān)網(wǎng)絡(luò)子系統(tǒng)、協(xié)議和連接的各種統(tǒng)計信息。

tcpdump 顯示一個或多個連接的協(xié)議級的報文跟蹤信息，其中包括時間信息，可以使用這些信息來研究不同協(xié)議的報文時間。

Ethereal 以一個易于使用的圖形化界面提供 tcpump （報文跟蹤）的信息，支持報文過濾功能。

iperf 測量 TCP 和 UDP 的網(wǎng)絡(luò)性能；測量最大帶寬，并匯報延時和數(shù)據(jù)報的丟失情況。

4.3 硬盤級緩存
硬盤級別的緩存是指將需要動態(tài)生成的內(nèi)容暫時緩存在硬盤上，在一個可接受的延遲時間范圍內(nèi)，同樣的請求不再動態(tài)生成，以達到節(jié)約系統(tǒng)資源，提高網(wǎng)站承受能力的目的。Linux環(huán)境下硬盤級緩存一般使用Squid［27］。

Squid是一個高性能的代理緩存服務器。和一般的代理緩存軟件不同，Squid用一個單獨的、非模塊化的、I/O驅(qū)動的進程來處理所有的客戶端請求。它接受來自客戶端對目標對象的請求并適當?shù)靥幚磉@些請求。比如說，用戶通過瀏覽器想下載（即瀏覽）一個web頁面，瀏覽器請求Squid為它取得這個頁面。Squid隨之連接到頁面所在的原始服務器并向服務器發(fā)出取得該頁面的請求。取得頁面后，Squid再將頁面返回給用戶端瀏覽器，并且同時在Squid本地緩存目錄里保存一份副本。當下一次有用戶需要同一頁面時，Squid可以簡單地從緩存中讀取它的副本，直接返回給用戶，而不用再次請求原始服務器。當前的Squid可以處理HTTP， FTP， GOPHER， SSL和WAIS等協(xié)議。

Squid默認通過檢測HTTP協(xié)議頭的Expires和 Cache-Control字段來決定緩存的時間。在實際應用中，可以顯式的在服務器端腳本中輸出HTTP頭，也可以通過配置apache的mod_expires模塊，讓apache自動的給每一個網(wǎng)頁加上過期時間。對于靜態(tài)內(nèi)容，如圖片，視頻文件，供下載的軟件等，還可以針對文件類型（擴展名），用 Squid 的 refresh_pattern 來指定緩存時間。

Squid 運行的時候，默認會在硬盤上建兩層hash目錄，用來存儲緩存的Object。它還會在內(nèi)存中建立一個Hash Table，用來記錄硬盤中Object分布的情況。如果Squid配置成為一個Squid集群中的一個的話，它還會建立一個 Digest Table(摘要表)，用來存儲其它 Squid 上的Object摘要。當用戶端想要的資料本地硬盤上沒有時，可以很快的知道應該去集群中的哪一臺機器獲得。在硬盤空間快要達到配置限額的時候，可以配置使用某種策略（默認使用LRU：Least Recently Used-最近最少用）刪除一些Object，從而騰出空間［28］［29］。

集群中的Squid Server 之間可以有兩種關(guān)系：第一種關(guān)系是：Child 和 Parent。當 Child Squid Server 沒有資料時，會直接向 Parent Squid Server 要資料，然后一直等，直到 Parent 給它資料為止。 第二種關(guān)系是：Sibling 和 Sibling。當 Squid Server 沒有資料時，會先向 Sibling 的 Squid Server 要資料，如果 Sibling 沒資料，就跳過它向 Parent 要或直接上原始網(wǎng)站去拿。

默認配置的Squid，沒有經(jīng)過任何優(yōu)化的時候，一般可以達到 50% 的命中率［30］（圖4）。如果需要，還可以通過參數(shù)優(yōu)化，拆分業(yè)務，優(yōu)化文件系統(tǒng)等辦法，使得Squid達到 90% 以上的緩存命中率。 Squid處理TCP連接消耗的服務器資源比真正的HTTP服務器要小的多，當Squid分擔了大部分連接，網(wǎng)站的承壓能力就大大增強了。

4 某網(wǎng)站使用MRTG工具檢測到的Squid命中率

藍線表示Squid的流量，綠色部分表示Apache流量

4.4 內(nèi)存級緩存
內(nèi)存級別的緩存是指將需要動態(tài)生成的內(nèi)容暫時緩存在內(nèi)存里，在一個可接受的延遲時間范圍內(nèi)，同樣的請求不再動態(tài)生成，而是直接從內(nèi)存中讀取。Linux環(huán)境下內(nèi)存級緩存Memcached［31］是一個不錯的選擇。

Memcached是danga.com（運營Live Journal［32］的技術(shù)團隊）開發(fā)的一套非常優(yōu)秀的分布式內(nèi)存對象緩存系統(tǒng)，用于在動態(tài)系統(tǒng)中減少數(shù)據(jù)庫負載，提升性能。和 Squid 的前端緩存加速不同，它是通過基于內(nèi)存的對象緩存來減少數(shù)據(jù)庫查詢的方式改善網(wǎng)站的性能，而其中最吸引人的一個特性就是支持分布式部署；也就是說可以在一群機器上建立一堆 Memcached 服務，每個服務可以根據(jù)具體服務器的硬件配置使用不同大小的內(nèi)存塊，這樣，理論上可以建立一個無限大的基于內(nèi)存的緩存系統(tǒng)。

Memcached 是以守護程序方式運行于一個或多個服務器中，隨時接受客戶端的連接操作，客戶端可以由各種語言編寫，目前已知的客戶端 API 包括 Perl/PHP/Python/Ruby/Java/C#/C 等等[附錄1]?？蛻舳耸紫扰c Memcached 服務建立連接，然后存取對象。每個被存取的對象都有一個唯一的標識符 key，存取操作均通過這個 key 進行，保存的時候還可以設(shè)置有效期。保存在 Memcached 中的對象實際上是放置在內(nèi)存中的，而不是在硬盤上。Memcached 進程運行之后，會預申請一塊較大的內(nèi)存空間，自己進行管理，用完之后再申請一塊，而不是每次需要的時候去向操作系統(tǒng)申請。Memcached將對象保存在一個巨大的Hash表中，它還使用NewHash算法來管理Hash表，從而獲得進一步的性能提升。所以當分配給Memcached的內(nèi)存足夠大的時候，Memcached的時間消耗基本上只是網(wǎng)絡(luò)Socket連接了［33］。

Memcached也有它的不足。首先它的數(shù)據(jù)是保存在內(nèi)存當中的，一旦服務進程重啟（進程意外被關(guān)掉，機器重啟等），數(shù)據(jù)會全部丟失。其次Memcached以root權(quán)限運行，而且Memcached本身沒有任何權(quán)限管理和認證功能，安全性不足。第一條是Memcached作為內(nèi)存緩存服務使用無法避免的，當然，如果內(nèi)存中的數(shù)據(jù)需要保存，可以采取更改Memcached的源代碼，增加定期寫入硬盤的功能。對于第二條，我們可以將Memcached服務綁定在內(nèi)網(wǎng)IP上，通過Linux防火墻進行防護。

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

4.6 讀寫分離
如果網(wǎng)站的硬盤讀寫性能是整個網(wǎng)站性能提升的一個瓶頸的話，可以考慮將硬盤的讀，寫功能分開，分別進行優(yōu)化。在專門用來寫的硬盤上，我們可以在Linux下使用軟件RAID-0（磁盤冗余陣列0級）［35］。RAID-0在獲得硬盤IO提升的同時，也會增加整個文件系統(tǒng)的故障率——它等于RAID中所有驅(qū)動器的故障率之和。如果需要保持或提高硬盤的容錯能力，就需要實現(xiàn)軟件RAID-1，4或5，它們能在某一個（甚至幾個）磁盤驅(qū)動器故障之后仍然保持整個文件系統(tǒng)的正常運行［36］，但文件讀寫效率不如RAID-0。而專門用來讀的硬盤，則不用如此麻煩，可以使用普通的服務器硬盤，以降低開銷。

一般的文件系統(tǒng)，會綜合考慮各種大小和格式的文件的讀，寫效率，因而對特定的文件讀或?qū)懙男什皇亲顑?yōu)。如果有必要，可以通過選擇文件系統(tǒng)，以及修改文件系統(tǒng)的配置參數(shù)來達到對特定文件的讀或?qū)懙男首畲蠡?。比如說，如果文件系統(tǒng)中需要存儲大量的小文件，則可以使用ReiserFS［37］來替代Linux操作系統(tǒng)默認的ext3系統(tǒng)，因為ReiserFS是基于平衡樹的文件系統(tǒng)結(jié)構(gòu)，尤其對于大量文件的巨型文件系統(tǒng)，搜索速度要比使用局部的二分查找法的ext3快。 ReiserFS里的目錄是完全動態(tài)分配的，因此不存在ext3中常見的無法回收巨型目錄占用的磁盤空間的情況。ReiserFS里小文件（< 4K）可以直接存儲進樹，小文件讀取和寫入的速度更快，樹內(nèi)節(jié)點是按字節(jié)對齊的，多個小文件可共享同一個硬盤塊，節(jié)約大量空間。ext3使用固定大小的塊分配策略，也就是說，不到4K的小文件也要占據(jù)4K的空間，導致的空間浪費比較嚴重［38］。 但ReiserFS對很多Linux內(nèi)核支持的不是很好，包括2.4.3、2.4.9 甚至相對較新的 2.4.16，如果網(wǎng)站想要使用它，就必須要安裝與它配合的較好的2.4.18內(nèi)核——一般管理員都不是很樂意使用太新的內(nèi)核，因為在它上面運行的軟件，都還沒有經(jīng)過大量的實踐測試，也許有一些小的bug還沒有被發(fā)現(xiàn)，但對于服務器來說，再小的bug也是不能接受的。ReiserFS還是一個較為年輕的，發(fā)展迅速的文件系統(tǒng)，它相對于ext3來說有一個很大的缺陷就是，每次ReiserFS文件系統(tǒng)升級的時候，必須完全重新格式化整個磁盤分區(qū)。所以在選擇使用的時候，需要權(quán)衡取舍［39］。

在這種架構(gòu)下，每一級都是可以進行單獨優(yōu)化的，比如Lighttpd可以采用異步IO方式，Squid可以啟用內(nèi)存來緩存，Apache可以啟用MPM（Multi -Processing Modules，多道處理模塊）等，并且每一級都可以使用多臺機器來均衡負載，伸縮性好。

著名視頻分享網(wǎng)站YouTube就是選擇使用Lighttpd作為網(wǎng)站的前臺服務器程序。

5.2 數(shù)據(jù)庫選擇
MySQL［43］是一個快速的、多線程、多用戶和健壯的SQL數(shù)據(jù)庫服務器，支持關(guān)鍵任務、重負載系統(tǒng)的使用，是最受歡迎的開源數(shù)據(jù)庫管理系統(tǒng)，是Linux下網(wǎng)站開發(fā)的首選。它由MySQL AB開發(fā)、發(fā)布和提供支持。

MySQL數(shù)據(jù)庫能為網(wǎng)站提供：

高性能。MySQL支持海量，快速的數(shù)據(jù)庫存儲和讀取。還可以通過使用64位處理器來獲取額外的一些性能，因為MySQL在內(nèi)部里很多時候都使用64位的整數(shù)處理。

易用性。MySQL的核心是一個小而快速的數(shù)據(jù)庫。它的快速連接，快速存取和安全可靠的特性使MySQL非常適合在互聯(lián)網(wǎng)站上使用。

開放性。MySQL提供多種后臺存儲引擎的選擇，如MyISAM， Heap， InnoDB，Berkeley Db等。缺省格式為MyISAM。 MyISAM 存儲引擎與磁盤兼容的非常好［44］。

支持企業(yè)級應用。MySQL有一個用于記錄數(shù)據(jù)改變的二進制日志。因為它是二進制的，這一日志能夠快速地將數(shù)據(jù)的更改從一臺機器復制（replication）到另一臺機器上。即使服務器崩潰，這一二進制日志也能夠保持完整。這一特性通常被用來搭建數(shù)據(jù)庫集群，以支持更大的流量訪問要求［30］（圖5）。

圖


5 MySQL主輔庫模式集群示意

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

國外的Yahoo!，國內(nèi)的新浪，搜狐等很多大型商業(yè)網(wǎng)站都使用MySQL 作為后臺數(shù)據(jù)庫。對于一般的網(wǎng)站系統(tǒng)，無論從成本還是性能上考慮，MySQL應該是最佳的選擇。

5.3 服務器端腳本解析器的選擇
目前最常見的服務器端腳本有三種：ASP(Active Server Pages)，JSP(Java Server Pages)，PHP (Hypertext Preprocessor)［45］［46］。

ASP全名Active Server Pages，以及它的升級ASP.NET，是微軟公司出品的一個WEB服務器端的開發(fā)環(huán)境，利用它可以產(chǎn)生和運行動態(tài)的、交互的、高性能的WEB服務應用程序。ASP采用腳本語言VBScript（C#）作為自己的開發(fā)語言。 但因為只能運行在Windows環(huán)境下，這里我們不討論它。

PHP是一種跨平臺的服務器端的嵌入式腳本語言。它大量地借用C，Java和Perl語言的語法， 并耦合PHP自己的特性，使WEB開發(fā)者能夠快速地寫出動態(tài)生成頁面。它支持目前絕大多數(shù)數(shù)據(jù)庫。PHP也是開源的，它的發(fā)行遵從GPL開源協(xié)議，你可以從 PHP官方站點(http://www.)自由下載到它的二進制安裝文件及全部的源代碼。如果在Linux平臺上與MySQL搭配使用，PHP是最佳的選擇。

JSP是Sun公司推出的新一代站點開發(fā)語言，是Java語言除Java應用程序和Java Applet之外的第三個應用。Jsp可以在Serverlet和JavaBean的支持下，完成功能強大的站點程序。 作為采用Java技術(shù)家族的一部分，以及Java 2（企業(yè)版體系結(jié)構(gòu)）的一個組成部分，JSP技術(shù)擁有Java技術(shù)帶來的所有優(yōu)點，包括優(yōu)秀的跨平臺性，高度可重用的組件設(shè)計，健壯性和安全性等，能夠支持高度復雜的基于Web的應用。

除了這三種常見的腳本之外，在Linux下我們其實還有很多其他的選擇：Python（Google使用），Perl等，如果作為CGI調(diào)用，那么可選擇范圍就更廣了。使用這些不太常見的腳本語言的好處是，它們對于某些特殊的應用有別的腳本所不具有的優(yōu)勢；不好的地方是，這些腳本語言在國內(nèi)使用的人比較少，當碰到技術(shù)上的問題的時候，能找到的資料也較少。

5.4 可配置性
在大型網(wǎng)站開發(fā)過程中，不管使用什么技術(shù)，網(wǎng)站的可配置性是必須的。在網(wǎng)站的后期運營過程中，肯定會有很多的需求變更。如果每一次的需求變更都會導致修改源代碼，那么，這個網(wǎng)站的開發(fā)可以說是失敗的。

首先，也是最重要的一點，功能和展示必須分開。PHP和JSP都支持模板技術(shù)，如PHP的Smarty，Phplib，JSP的JSTL（JSP Standard Tag Library）等。核心功能使用腳本語言編寫，前臺展示使用帶特殊標簽的HTML，不僅加快了開發(fā)速度，而且方便以后的維護和升級［47］。

其次，對于前臺模板，一般還需要將頁面的頭，尾單獨提取出來，頁面的主體部分也按模塊或者功能拆分。對CSS，JS等輔助性的代碼，也建議以單獨的文件形式存放。這樣不僅方便管理，修改，而且還可以在用戶訪問的時候進行緩存，減少網(wǎng)絡(luò)流量，減輕服務器壓力。

再次，對于核心功能腳本，必須將與服務器相關(guān)的配置內(nèi)容，如數(shù)據(jù)庫連接配置，腳本頭文件路徑等，與代碼分離開。尤其當網(wǎng)站使用集群技術(shù)，CDN加速等技術(shù)的時候，每一臺服務器上的配置可能都會不一樣。如果不使用配置文件，則需要同時維護幾份不同的代碼，很容易出錯。

最后，應該盡量做到修改配置文件后能實時生效，避免修改配置文件之后需要重啟服務程序的情況。

5.5 封裝和中間層思想
在功能塊層次，如果使用JSP，基于純面向?qū)ο笳Z言Java的面向?qū)ο笏枷?，類似?shù)據(jù)庫連接，會話管理等基本功能都已經(jīng)封裝成類了。如果使用PHP，則需要在腳本代碼中顯式的封裝，將每一個功能塊封裝成一個函數(shù)，一個文件或者一個類。

在更高的層次，可以將網(wǎng)站分為表示層，邏輯層，持久層，分別進行封裝，做到當某一層架構(gòu)發(fā)生變化時，不會影響到其他層。比如新浪播客在一次升級的時候，將持久層的數(shù)據(jù)庫由原來的集中式改為分布式架構(gòu)，因為封裝了數(shù)據(jù)庫連接及所有操作[附錄2]，做到了不修改任何上層代碼，平穩(wěn)的實現(xiàn)了過渡。近來流行的MVC架構(gòu)，將整個網(wǎng)站拆分成Model（模型/邏輯）、View（視圖/界面）、Controller（控制/流程）三個部分，而且有很多優(yōu)秀的代碼框架可供選擇使用， 像JSP的Structs，Spring，PHP的php.MVC， Studs 等。使用現(xiàn)成的代碼框架，可以使網(wǎng)站開發(fā)事半功倍。

新浪播客采用MySQL數(shù)據(jù)庫集群，在邏輯層封裝了所有的數(shù)據(jù)庫連接及操作。當數(shù)據(jù)庫存儲架構(gòu)發(fā)生改變的時候，如增加一臺主庫，將某些數(shù)據(jù)表獨立成庫，增加讀取數(shù)據(jù)用的從庫等，都只需要修改封裝了的數(shù)據(jù)庫操作類，上層代碼不用修改。

新浪播客的前臺頁面服務器使用F5公司的硬件第四層交換機，網(wǎng)通，電信分別導向不同的虛擬IP，每一個虛擬IP后面又有多個服務器提供服務。當訪問流量增大的時候，可以很方便往虛擬IP后面增加服務器，分擔壓力。

6.2 容錯
對于商業(yè)性網(wǎng)站來說，可用性是非常重要的。7*24的訪問要求網(wǎng)站具有很強的容錯能力。錯誤包括網(wǎng)絡(luò)錯誤，服務器錯誤以及應用程序錯誤。

2006年12月27日臺灣東部外海發(fā)生里氏7.6級地震，造成途徑臺灣海峽的多條海底電纜中斷，導致許多國外網(wǎng)站，像MSN， NBA， Yahoo?。ㄓ⑽闹髡荆┑葒鴥?nèi)無法訪問，但也有例外，以Google為代表的在國內(nèi)建設(shè)有分布式數(shù)據(jù)節(jié)點的很多網(wǎng)站卻仍然可以訪問。雖然說地震造成斷網(wǎng)是不可抗原因，但如果在這種情況下網(wǎng)站仍然可以訪問，無疑能給網(wǎng)站用戶留下深刻的印象。這件事情給大型商業(yè)網(wǎng)站留下的教訓是：網(wǎng)站需要在用戶主要分布區(qū)域保持數(shù)據(jù)存在，以防止可能的網(wǎng)絡(luò)故障。

對于服務器錯誤，一般采取冗余設(shè)計的方法來避免。對于存儲服務器（主要是負責寫入的服務器），可以使用RAID（冗余磁盤陣列）；對于數(shù)據(jù)庫（主要是負責寫入的主庫），可以采用雙主庫設(shè)計［30］；對于提供服務的前臺，則可以使用第四層交換的集群，由多臺服務器同時提供服務，不僅分擔了流量壓力，同時還可以互相作為備份。

在應用層程序中，也要考慮“用戶友好”的出錯設(shè)計。典型例子如HTTP 404 出錯頁面，程序內(nèi)部錯誤處理，錯誤返回提示等，盡可能的做到人性化。

7.2展望
當前Linux環(huán)境下有著名的LAMP（Linux＋Apache＋MySQL＋PHP/PERL/PYTHON）網(wǎng)站建設(shè)方案，但只是針對一般的中小網(wǎng)站而言。對于高并發(fā)高流量的大型商業(yè)網(wǎng)站，還沒有一個完整的，性價比高的解決方案。除去服務器，硬盤，帶寬等硬件投資外，還需要花費大量的預算和時間精力在軟件解決方案上。

隨著互聯(lián)網(wǎng)的持續(xù)發(fā)展，Web2.0的興起，在可以預見的未來里，互聯(lián)網(wǎng)的用戶持續(xù)增多，提供用戶參與的網(wǎng)站不斷增加，用戶參與的內(nèi)容日益增長，越來越多的網(wǎng)站的并發(fā)量，訪問量會達到一個新的高度，這就會促使越來越多的個人，公司以及研究機構(gòu)來關(guān)注高并發(fā)高流量的網(wǎng)站架構(gòu)問題。就像Web1.0成就了無數(shù)中小網(wǎng)站，成就了LAMP一樣，Web2.0注定也會成就一個新的，高效的，成本較低的解決方案。這個方案應該包括透明的第三方CDN網(wǎng)絡(luò)加速服務，價格低廉的第四層甚至更高層網(wǎng)絡(luò)交換設(shè)備，優(yōu)化了網(wǎng)絡(luò)性能的操作系統(tǒng)，優(yōu)化了讀寫性能，分布式，高可靠的文件系統(tǒng)，揉合了內(nèi)存，硬盤等各個級別緩存的HTTP服務器，更為高效的服務器端腳本解析器，以及封裝了大部分細節(jié)的應用層設(shè)計框架。

技術(shù)的進步永無止境。我們期待互聯(lián)網(wǎng)更為美好的明天