Web透明緩存爭得帶寬

文/陳麗仙 司占軍

校園網(wǎng)的帶寬問題

隨著Internet的高速發(fā)展，網(wǎng)絡(luò)應(yīng)用的不斷豐富，各種網(wǎng)絡(luò)業(yè)務(wù)不斷吞噬著互聯(lián)網(wǎng)帶寬。同時，Internet 的用戶也在迅速增長，導(dǎo)致了以下問題：一方面用戶的急速增多，使服務(wù)器的負載過重，不能及時響應(yīng)用戶的請求；另一方面網(wǎng)絡(luò)帶寬的不足以及數(shù)據(jù)傳輸鏈路的延遲，造成了嚴重的網(wǎng)絡(luò)阻塞。

根據(jù)網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)臅r間和地域相關(guān)性，一個用戶在某一時刻訪問某個數(shù)據(jù)后該用戶及其周圍的用戶一段時間內(nèi)很有可能再次訪問這個數(shù)據(jù)。如果在相同區(qū)域內(nèi)不同用戶每次需要相同的數(shù)據(jù)時都要到遠端服務(wù)器獲取，則會造成數(shù)據(jù)的重復(fù)傳輸。這樣不但浪費了網(wǎng)絡(luò)帶寬，使網(wǎng)絡(luò)響應(yīng)速度變慢，同時加重了服務(wù)器的負荷。 從而可以為企事業(yè)或者服務(wù)提供者節(jié)省大量的帶寬建設(shè)費用，更重要的是提高了用戶體驗和服務(wù)質(zhì)量。

Web緩存基本原理

Web 高速緩存服務(wù)器通常是網(wǎng)絡(luò)中的一個專用的計算機系統(tǒng)，它監(jiān)視Web 對象請求，獲得這些對象，然后存儲這些對象。其工作原理如下：

緩存服務(wù)器接受瀏覽器請求；緩存服務(wù)器從原始服務(wù)器獲得緩存中的未存儲或已過期的對象(Cache Miss)；緩存服務(wù)器存儲獲得的對象，并將其發(fā)送給客戶端瀏覽器。

此后，當(dāng)用戶對相同的對象(網(wǎng)站) 提出訪問請求時，就由緩存服務(wù)器來響應(yīng)其要求，將已存儲且未過期的對象的拷貝直接發(fā)送給客戶端瀏覽器(Cache Hit)。Web緩存系統(tǒng)使得用戶請求不必再通過Internet 路由到達原始服務(wù)器去取回所請求的對象，即省去了中間步驟，降低了多重路由可能引起的服務(wù)延遲，避免了重復(fù)傳輸造成的帶寬浪費，減小了網(wǎng)絡(luò)負荷，從而可以有效提高響應(yīng)時間，改善用戶體驗。

透明Web緩存的實現(xiàn)架構(gòu)

應(yīng)用環(huán)境

本應(yīng)用的校園網(wǎng)出口環(huán)境如圖1所示，通過在出口的流量控制設(shè)備AG3000E上配置策略路由，將內(nèi)網(wǎng)所有滿足策略的數(shù)據(jù)都重定向到Web緩存服務(wù)器上，再利用緩存機制，從而實現(xiàn)透明代理的效果。

高可用彈性擴展的實現(xiàn)架構(gòu)

由于校園網(wǎng)的最大并發(fā)為4000～5000人，網(wǎng)絡(luò)壓力相對較大，為確保Web緩存服務(wù)器的系統(tǒng)性能，使用一個Cache服務(wù)器顯然不能滿足需求，同時隨著校園網(wǎng)用戶數(shù)的不斷增加、網(wǎng)絡(luò)需求量也會隨之增加，需要考慮一定的擴展性。因此，整個系統(tǒng)中部署了兩臺服務(wù)器，分別規(guī)劃為Balancer層和Cache-Pools層，如圖2所示，Balancer層上面運行了一個Squid實例（簡稱SZone），主要用于請求調(diào)度，其本身并不緩存任何對象。而Cache-Pools層則運行了4個Squid實例，分別服務(wù)在3128，3228，3328，3428四個端口，主要用于接受并處理來自Balancer層轉(zhuǎn)發(fā)的請求，提供并發(fā)的緩存服務(wù)。

1. 前端調(diào)度器（Balancer）

圖2中的Balancer稱為前端調(diào)度器，有兩種部署方式，一是串聯(lián)部署，通常是處于內(nèi)網(wǎng)數(shù)據(jù)包到達出口路由器/網(wǎng)關(guān)前的位置；二是旁路部署，通常是處于出口路由/網(wǎng)關(guān)處。部署方式雖然不同但是對應(yīng)的調(diào)度方式是相同的，區(qū)別在于數(shù)據(jù)包進入Balancer層的方式不同，前者是主動流入；后者為被動流入。而且后者具有更靈活的伸縮性，但是需要在路由器/網(wǎng)關(guān)上配置路由轉(zhuǎn)發(fā)策略，使來自內(nèi)網(wǎng)的http請求都轉(zhuǎn)向Web緩存服務(wù)器的Balancer層(可以通過WCCP協(xié)議來進行轉(zhuǎn)發(fā)，Cisco公司的IOS系統(tǒng)已經(jīng)支持該協(xié)議了)。考慮到需要根據(jù)實際負載情況隨時調(diào)整經(jīng)過緩存服務(wù)器的用戶數(shù)，本應(yīng)用是采取旁路部署的方式，以實現(xiàn)彈性擴展的效果。

請求調(diào)度層的作用是通過截獲進入本機的HTTP請求并轉(zhuǎn)發(fā)到本地Squid所監(jiān)聽的80端口，然后由Squid程序負責(zé)解析請求。Balancer將后臺Cache-Pools中所有的SZone定義為父服務(wù)器（parent），并使用CARP調(diào)度算法進行請求調(diào)度。CARP算法是一種URI策略算法，一種確定性的算法,它以每個服務(wù)器的狀態(tài)作為請求分發(fā)的前提條件，然后進行均衡的請求轉(zhuǎn)發(fā)，并在轉(zhuǎn)發(fā)后記錄本次分發(fā)策略，下次如有同樣的請求時會按照這個策略直接分發(fā)，而不再進行均衡評估從而節(jié)省了分發(fā)決策時間，經(jīng)過實踐證明這種分發(fā)策略較為適合這個應(yīng)用環(huán)境，它可以帶來最大化的命中目標和最小化的目標重復(fù)。Balancer層的配置除了CARP算法和服務(wù)端口外，其他的使用Squid的通用配置即可。以下是實現(xiàn)CARP算法調(diào)度的配置語句：

圖2 高可用彈性擴展的We b緩存服務(wù)器群架構(gòu)

cache_peer zone1 parent 3128 0 carp proxy-only no-query

cache_peer zone2 parent 3228 0 carp proxy-only no-query

cache_peer zone3 parent 3328 0 carp proxy-only no-query

cache_peer zone4 parent 3428 0 carp proxy-only no-query

Balancer會定期去檢查父服務(wù)器的狀態(tài)：存活或者死亡，當(dāng)Balancer檢測到某個父服務(wù)器為死亡狀態(tài)，那么將不再向其轉(zhuǎn)發(fā)請求，直到再次檢測其為存活狀態(tài)后才對其轉(zhuǎn)發(fā)請求。這種調(diào)度策略體現(xiàn)了均衡性的同時，也有效地避免了單點故障，從而提高了系統(tǒng)的可用性。

2. 高可用和彈性擴展的后端緩存池（Cache-Pools）

圖2中，Cache-Pools中配置有4個SZone，即四個Squid實例，他們分別進行請求響應(yīng)、原始內(nèi)容請求、內(nèi)容緩存等工作。其中SZone-1，SZone-2，SZone-3，SZone-4是相互獨立的，即它們分別運行于互相獨立的系統(tǒng)用戶。之所以設(shè)計成多個實例是因為：一是可以解決系統(tǒng)對用戶和進程的資源占用限制，從而充分利用硬件資源；二是提高大并發(fā)用戶情況下的并行處理能力和整體性能；三是增加可擴展性，一旦發(fā)現(xiàn)現(xiàn)有的Cache-Pools不能滿足實際需求后，可以迅速的配置更多的SZone來緩解負載壓力；四是提高可用性，即在某個SZone因為處理異常導(dǎo)致服務(wù)崩潰后，其它SZone可以不受影響繼續(xù)提供服務(wù)。也就是說任何一個SZone出現(xiàn)故障，都不會影響其他的SZone進行緩存服務(wù)。本文僅用一臺服務(wù)器承擔(dān)所有Cache-Pools服務(wù)，即將多個實例運行在一個物理服務(wù)器和操作系統(tǒng)之上。實際使用環(huán)境中，如果需要提高用戶容納量或降低用戶等待響應(yīng)時間，可以適當(dāng)?shù)卦黾覥ache-Pools的數(shù)量，即增加父服務(wù)器數(shù)量（由于Balancer層資源開銷不是很大，無需同比增加）。擴展時可以遷移一部分現(xiàn)有實例到新的物理服務(wù)器上，讓每個實例擁有更大的內(nèi)存來響應(yīng)請求以及更大的磁盤存儲空間來緩存更多的對象數(shù)據(jù)，并且擁有足夠的CPU計算時間進行事務(wù)處理；假如單臺服務(wù)器硬件資源充足也可以直接在新的服務(wù)器上新建更多的實例，以減輕現(xiàn)有實例的負載，提高服務(wù)的穩(wěn)定性和響應(yīng)速度。不同的網(wǎng)絡(luò)和用戶環(huán)境，SZone的調(diào)配基準會有所不同。

如上所述，這種以前端調(diào)度器和后端緩存池相結(jié)合的部署結(jié)構(gòu)充分體現(xiàn)了高可用和彈性擴展的特點：前端調(diào)度器以旁路部署的方式接入，可以靈活的控制進入Web緩存服務(wù)器的用戶量，體現(xiàn)了彈性擴展的特點；而后端緩存池，多個SZone并行且又獨立地提供服務(wù)，體現(xiàn)了高可用的特點，不僅如此，一旦服務(wù)器本身的性能或資源出現(xiàn)瓶頸后，可以簡單地通過拆分一部分原有的SZone到其他物理服務(wù)器上，或者直接在新的物理服務(wù)器上部署新的SZone，同樣體現(xiàn)了彈性擴展的特點。

服務(wù)運行監(jiān)控與管理

服務(wù)運行過程中，對Squid進行實時監(jiān)控很重要，監(jiān)控結(jié)果可以讓我們實時了解整個Web緩存系統(tǒng)的運行狀況，而且對我們調(diào)整資源和配置參數(shù)具有重要的參考意義，比如是否需要進行配置優(yōu)化或硬件擴容等，從而不斷優(yōu)化和完善透明Web緩存服務(wù)。

Squid的監(jiān)控方法基本分為兩大類，一是基于日志進行統(tǒng)計和分析；二是利用SNMP協(xié)議登錄設(shè)備控制臺進行實時監(jiān)控。前者可以做到更詳細一些，但是記錄詳細的access日志會帶來一些額外的存儲和CPU計算時間上的開銷，對整體服務(wù)性能會造成一定的負面影響；而后者則可以節(jié)省記錄日志的資源損耗，并且提供更細的統(tǒng)計時間軸精度。

因此，我們采用方式二對Balancer層和Cache-Pools層的各個Squid實例進行監(jiān)控。Balancer層主要監(jiān)控CARP調(diào)度表、對各SZone實例轉(zhuǎn)發(fā)請求的比重及各SZone實例的工作狀態(tài)。Cache-Pools層的監(jiān)控主要針對總請求數(shù)、命中請求數(shù)、命中率、磁盤緩存量、內(nèi)存緩存量、磁盤緩存命中率、內(nèi)存緩存命中率、發(fā)送數(shù)據(jù)量、接收數(shù)據(jù)量、文件描述符使用率及CPU占用率等。

經(jīng)過一段時間的正式運行，Cache-Pools層中的各個SZone實例的Hit率都達到50%左右，并趨于穩(wěn)定。

同時，為了更直觀地顯現(xiàn)Web緩存的效果，通過使用Firefox結(jié)合Yslow插件在同一時間同一客戶端上對同一個網(wǎng)站進行加載時間的對比，經(jīng)過Web緩存的客戶端加載時間約為：2.378 s，而不經(jīng)過Web緩存的客戶端加載時間約為：12.534 s，反復(fù)測試結(jié)果表明，加入Web緩存之后，可使Web的訪問速度提高至少5倍，從而有效地縮短了網(wǎng)絡(luò)延遲，大大地提升了用戶體驗。

本文針對當(dāng)前校園網(wǎng)網(wǎng)絡(luò)出口帶寬緊張與信息化應(yīng)用精彩紛呈以及校園網(wǎng)用戶規(guī)模不斷壯大的矛盾日益激化的問題，引入了Web緩存系統(tǒng)，該Web緩存系統(tǒng)基于Squid服務(wù)構(gòu)建了由前端調(diào)度器和后端緩存池相結(jié)合的一個高可用和彈性擴展的服務(wù)架構(gòu)。