頁面片段緩存(二)

 在上一篇文章中,我介紹了我們用土法煉鋼的方法,使用Velocity提供的自定義標籤實現片段緩存。這樣的方式雖然也解決了我們的問題,但還是引出了一些bug。而且還有點hack的味道(雖然我喜歡hack)。實際上對於片段緩存,業界有成熟的解決方案,還有一個所謂的W3C標準:ESI(Edge Side Include) 。

  ESI本身沒有什麼,只是一個XML的標籤集合。ESI和SSI(Server Side Include)很相似,做過ASP開發的都熟悉這麼一個標籤:

<!--#include src="header.inc" -->

  IIS碰到這麼一個標籤後,會把header.inc裏面的東西合併到當前的頁面,這樣做的好處是header.inc本身可以複用了,你可以在多個頁面include它。

  ESI的功能也是類似的,只不過解析和合並它的任務一般落到緩存服務器或代理上:

<esi:include src="/welcome" />
<ul>
#foreach($book in $books)
<li>$book.name</li>
#end
</ul>

  比如對於上面這個片段,esi:include標籤那裏本來是應該顯示特定於每個用戶的歡迎信息的,就因爲這一點整個頁面不能緩存太可惜了。這個時候ESI粉墨登場。緩存服務器會將整個頁面cache,然後它發現這兒有個ESI標籤,它會根據src指定的地址去源服務器請求內容,然後將其合併到緩存的頁面中,然後將完整的內容發送到客戶端。整個過程類似下圖所示:

image

  這樣我們就不需要每次都去數據庫查詢那個圖書列表了,因爲圖書列表可能更新的很緩慢。這樣大大的降低了Web服務器的壓力。

  既然ESI是一個規範,那麼肯定有遵循這個規範的實現。比如大名鼎鼎的Squid就有支持ESI的模塊。不過本文要介紹的是Varnish。Varnish是一個反向代理,使用緩存對HTTP加速,可以把它放到你的Web服務器的前面,對內容緩存,跟Squid的目的相似。不過因爲Squid想幹的事兒實在是太多,它已經不再是一個純粹的用戶緩存加速的方向代理了,所以顯得太過於臃腫,而比較起來Varnish更專注,更輕便。根據網站上的數據顯示,Varnish表現出來的性能比Squid更好,而且佔用的資源更少。

  下面我就簡單的描述一下如何安裝Varnish以及配置使用ESI。

  安裝

  我是在Mac上安裝Varnish的,從源代碼編譯過去的。基本上是一路命令下去,在configure的時候碰到缺少libpcre,用port裝上pcre就可以了:

$wget http://repo.varnish-cache.org/source/varnish-2.1.5.tar.gz
$tar zxvf varnish-
2.1.5.tar.gz
$cd varnish-
2.1.5
$sh autogen.sh
$sh configure
$make
$make install

  根據環境不同,可能缺少一些依賴,我在安裝的過程中就缺少libpcre。

  Varnish默認是安裝在/usr/local/sbin目錄下:varnishd。是daemo。

  配置

  根據上面那幅圖可以看出,Varnish並不自己提供服務,它只是作爲一個緩存服務器。那麼就必須有一個後端的服務器提供應用程序的服務。那我們就需要讓Varnish知道到哪兒去請求後端服務器。這個是通過配置文件設置的,Varnish的默認配置文件在/usr/local/etc/varish/default.vcl。

  打開後我們會發現一段被註釋的代碼,取消註釋將其指向你的後端服務器(比如IIS):

backend default {
.host
= "127.0.0.1";
.port = "8080";
}

  配置好後,啓動Varnish,然後去看看效果,啓動的命令是:

sbin yuyi$sudo ./varnishd -a 0.0.0.0:80 -f /usr/local/etc/varnish/default.vcl -s malloc,500M

  我簡單的介紹下這幾個選項,更詳細的可以看man。

  -a指定Varnish鑑定的地址。如果你的配置是上圖所示,那麼端口應該是80。如果你沒有指定-a,那麼默認配置使用/etc/services中的配置,一般情況下就是80。而-f指定配置文件的地址,默認情況下就是default.vcl,除非你想使用別的配置文件。

  最有趣的是-s選項,它用來指定存儲方式,以及緩存的大小。比如這裏是malloc,那就是使用內存作爲緩存,你還可以使用file,使用磁盤作爲緩存。後面是緩存大小,500兆。還可以指定K,G,T等,大小寫都可以。

  運行後我們去瀏覽器打開http://127.0.0.1看看。爲了測試你可以在頁面輸出一個DateTime.Now,然後刷新頁面看看是不是每次都變化。

  Varnish還有個不錯的工具:varnishlog,打開後可以看到用戶訪問的一些情況。

  好了,安裝和簡單配置就介紹這麼多,那如何使用ESI呢?其實很簡單,分爲兩個步驟,首先將你的頁面上需要施加不同緩存策略的片段切分,放到不同的連接中。

  比如原來你的首頁混沌一片:有熱點新聞板塊、通知板塊、還有廣告以及顯示用戶登錄的板塊。而它們原來很可能都是由index.aspx處理的。如果你想有針對性的對這些板塊施加緩存策略,那麼就應該將其獨立開,使用不同的連接(控制器)來處理:

<html>
<head>
<title>index</title>
</head>
<body>
<p>Welcome yuyijq</p>
<div>
<h3>Hot News</h3>
<ul>
<li>慶祝奧特曼45歲生日</li>
<li>拉登掛了</li>
</ul>
</div>
<div>
<h3>通知</3>
<ul>
<li>機房維護通知</li>
</ul>
</div>
</body>
<html>

  現在我們要拆分: 
  hotnews->hotnews.aspx 
  welcome->welcome.aspx

  然後使用ESI標籤分離:

<html>
<head>
<title>index</title>
</head>
<body>
<esi:include src="/welcome.aspx" />
<esi:include src="hotnews.aspx" />
<div>
<h3>通知</3>
<ul>
<li>機房維護通知</li>
</ul>
</div>
</body>
<html>

  注意的是welcome.aspx和hotnews.aspx現在輸出的是兩個片段,不是完整的頁面。

  這些都準備好後,就是啓用Varnish對ESI的處理了。

  配置

  還是編輯default.vcl文件。Varnish的配置能力非常強大,這個vcl是Varnish Configuration Language。剛纔我們僅僅是配置一個後端服務器,現在讓我們打開default.vcl仔細欣賞一下:

sub vcl_recv {
}
sub vcl_pipe {
}
sub vcl_pass {
}
sub vcl_hash {
}
sub vcl_hit {
}
sub vcl_miss {
}
sub vcl_fetch {
}
sub vcl_deliver {
}
sub vcl_error {
}

  你會看到有vcl_recv,vcl_pipe,vcl_pass,vcl_hash,vcl_hit等函數。這些函數就代表一個請求進入Varnish所通過的階段(參見這裏)。就像一個管道一樣,你可以在這些管道上做些自定義的處理。所以配置性非常強大。現在我們只對vcl_fetch函數做一下簡單修改:

sub vcl_fetch {
if(req.url
== "/welcome.aspx"){
return (pass)
;
}
if (req.url
== "/index.aspx") {
esi
;
}
}

  如果請求的url是/welcome.aspx就直接pass,也就是不做任何處理,請求直接遞交給後端應用服務器(IIS)。如果請求是/index.aspx,也就是我們上面列出的那個包含esi標籤的頁面,就對其進行ESI處理,這樣Varnish就會解析這個頁面,看看緩存中有沒有,如果有的話則從緩存中取出頁面,並將其與從後端服務器獲取的welcome.aspx片段合併,然後直接發送回請求。

  用Varnish處理ESI就這麼簡單,不過使用Varnish之前我們還得對其某些參數進行配置,比如緩存多長時間啊等等。默認情況下Varnish會緩存120秒,你可以通過管理功能對其進行配置,還可以通過在vcl裏對某些模塊進行精細的控制。

  管理

  還記得我們是怎樣啓動Varnish的麼,如果在啓動參數里加上-T 127.0.0.1:5000,那麼我們就可以使用telnet對Varnish進行管理了。我們只需要telnet上這個端口,然後可以使用很多豐富的命令了,更多細節留給你嘗試吧。

  兩種方式的比較

  前一篇文章介紹的使用Velocity自定義標籤來實現片段緩存和這一篇介紹的使用ESI都有自己的優缺點。

  使用Velocity自定義標籤的方案工作在應用程序這一層,這樣開發人員有最大的控制權力,而且實現起來也比較簡單,所使用的也都是大家都熟悉的技術,但問題是它還是由應用程序服務器來處理得,可以說它減輕了一部分應用程序服務器和數據庫服務器的壓力,但還有一部分壓力還是需要它來承擔,而且在應用程序中解決所使用的緩存必定是和應用程序所採用的緩存機制一樣(當然你也可以爲此獨立使用一個緩存),對緩存服務器也有部分壓力。

  而使用ESI的方案,它需要運維團隊的配置,甚至需要修改服務器配置的架構(添加了前端服務器),如果在多部門協調比較困難的項目中,這種方案還會遇到一些阻力。

  但是它帶來的好處確實顯而易見的。首先ESI是一個W3C標準,我更傾向於採用標準的做法。而且Varnish這樣的方向代理,它本來就擅長這個,它可以完全把這部分壓力從應用程序服務器和緩存服務器上接管過來,而且會處理的更出色。

  由此可見什麼方案都是需要權衡各方利弊,得到一個平衡的效果啊。

發佈了21 篇原創文章 · 獲贊 3 · 訪問量 6萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章