關于頁面輸出緩存（頁面靜態(tài)化）的設計

隨著網站規(guī)模的變大，訪問量提升，網站服務器越來越不堪重負，瀏覽者也會對頁面打開的速度怨聲載道。這時候最簡單的解決方案就是增加緩存。網站服務 器的緩存有很多中，可以放在數據庫和Web應用程序之間，也可以放在Web應用程序和Web服務器之間，還可以放在Web服務器和用戶瀏覽器之間，甚至可 以直接放在瀏覽器端。

其中最簡單，需要配置最少的莫過于數據庫和Web應用程序之間了，并且見效也最快，因為對于現代計算機系統來說IO是大的瓶頸。常見的方法就是使用MemCache或者K-V型NoSQL數據庫做緩存。

這么安逸了一段時間之后，網站的響應速度還是會降下來，如果你不想增加服務器的話，這時需要做的就是頁面輸出緩存了。

因為數據庫和Web應用程序端的緩存只是將數據庫中的鍵和值緩存下來，訪問量大的話有一個命中率的問題，并且一個頁面往往包含有大量的需要從數據庫 查詢的值，就算數據庫緩存全部命中，這其中也需要一個查詢的過程，即時它很快。還有一個問題，就是對于Web應用程序來說，從獲取數據到輸出頁面，中間還 需要一些邏輯性運算和模板的渲染過程，這個過程也會消耗一段時間。

如果將一個頁面響應的結果，也就是HTML頁面，整體緩存下來，Web服務器直接輸出緩存結果，這樣的速度基本上相當于直接輸出靜態(tài)頁面，對于服務器端的負載將會大大減輕。 對于頁面輸出緩存，或者有人稱之為頁面靜態(tài)化，主要有以下幾個問題：

頁面?zhèn)€性化部分的處理。現在絕大部分網站都有登錄給功能，對于同一個頁面來說登錄前后、不同用戶登錄后都會有不同的顯示，比如說未登錄時顯示“登錄或注冊”，登錄之后顯示“歡迎用戶XXX”，這樣就會造成網站大部分頁面都不能直接緩存。

其實這個問題是在頁面?zhèn)€性化部分與非個性化部分合成的時間問題上。傳統網站這個個性化部分也非個性化部分是直接放在Web應用程序上的，這樣就導致不同用戶輸出頁面的不同，緩存不能進行。如果把這個過程放在頁面緩存程序之后，使緩存的結果相同就沒有問題了。

常見的方式就是使用SSI、ESI和CSI。

SSI（Server Side Include）這個現在大部分的Web服務器都支持，可以在頁面中使用<!–#include file=”/user_info.shtml”–>來替代原來個性化的部分，然后在Web服務器上就會去尋找這個.shtml文件，將它與頁面合 成。不過這有一個問題，ssi只能將靜態(tài)文件與頁面合成，這樣對于做頁面輸出緩存意義并不大。

ESI（Edge Side Include）正是為了應付這種場合而出現的，它可以使用類似<esi:include src=http://www.chinaz.com/Design/Pages/”http://example.com/1.html” alt=”http://bak.example.com/2.html” onerror=”continue”/>的XML語法，在頁面合成過程中調用一個動態(tài)頁面，將動態(tài)頁面的內容與現有網頁合成。這樣一來就可以將某 個用戶的個性化信息與緩存的頁面文件合成了。ESI大的問題就是現有Web服務器對此支持度不高。Nginx需要將第三方模塊編譯進來來支持ESI，代 理緩存服務器中Varnish原生支持ESI。

CSI（Client Side Include）或者叫做Browser Side Include，就是在用戶瀏覽器端將個性化信息與非個性化信息合成。說白了就是用ajax異步獲取個性化信息，或者直接使用iframe顯示個性化信 息。實際上這個合成的過程越靠近用戶瀏覽器端越好，這樣就可以一直從Web服務器到代理服務器的緩存到CDN都可以用到這些完全相同的頁面做緩存。但是使 用ajax等方式有一些問題，就是對于不支持或者不開啟的JavaScript的瀏覽器來說就不能正常訪問頁面了，現在很多網站都要考慮到手機客戶端，其 中不支持JavaScript的占大多數。并且大量使用ajax的話對用戶瀏覽器來說也是一種負擔，并且會造成頁面加載很“卡頓”的感覺。

具體的做法還是依賴實際環(huán)境來決定。

剩下需要解決的方式是如何來緩存頁面。

使用代理緩存服務器是一個比較不錯的主意，比如Squid還有比較新的Varnish，它們都可以架設在Web服務器前端作為代理緩存服務器，將頁 面緩存下來。當頁面需要更新的時候可以給它發(fā)送一個Purge請求加具體頁面URL，就可以使代理緩存服務器去訪問Web服務器，重新生成一個新的頁面， 然后將現有的頁面緩存失效。這個過程中當新的用戶訪問請求達到時，代理緩存服務器還是使用之前的緩存，新的緩存頁面生成結束后才使過期的頁面失效。這樣就 不用擔心更新緩存過程中所有用戶請求都去直接訪問Web服務器造成大量的壓力了。這其中有一個問題，就是觸發(fā)這個更新動作的用戶，比如說他發(fā)布了一條回復 造成頁面更新，如果頁面更新請求與頁面緩存更新兩個動作是異步的話，假如他的網速足夠快就會看到自己剛才發(fā)布的帖子沒有顯示出來，造成重復發(fā)帖等動作。這 個問題接下來再來想辦法處理。

如果不想另外搞一個代理服務器的話，Nginx的fastcgi cache是一個好東西，可以直接將fastcgi的頁面緩存下來。配合一個第三方的模塊cache purge，可以通過訪問/purge/url的方式來時緩存過期。另外Nginx+proxy cache+cache purge也可以達到上面Squid和Varnish的作用。

剩下還有一種方式，使用Nginx的rewrite，將緩存保存為一個靜態(tài)文件，先檢查靜態(tài)頁面是否存在，存在的話rewrite到此，不存在則訪 問Web應用程序。這樣還需要另外配合一個獨立的進程，來生成緩存頁面。當Web應用程序觸發(fā)更新時給此進程發(fā)送一個信號，緩存進程收到此信號后去Web 服務器端或者Web應用程序端請求頁面（為了做到松耦合和以后的服務器分離最好直接從Web服務器端），將請求生成的頁面文件直接覆蓋遠緩存的靜態(tài)文件， 這樣就可以更新緩存，并且在緩存更新過程中訪問者依然可以使用之前的緩存文件。

還有一個問題，當很多用戶在同一個時間點內同時觸發(fā)一個頁面的更新動作，這樣就會導致此頁面頻繁更新，并且這些更新是不必要的，這就是所謂的驚群問題。 防止此事件發(fā)生，一個解決方案是使用隊列。

一般頁面發(fā)生內容變化是在提交POST請求之后，在此時給緩存更新系統發(fā)送一條消息，記錄發(fā)生更新動作的類型、ID（比如說帖子更新，更新的 ID）。緩存更新系統在接受到此消息時將消息進行預處理，根據配置文件計算出影響更新的頁面（此帖子的頁面，帖子列表的頁面，等等）。

將此頁面的URL插入進隊列，更新程序在隊列另一端取URL，每取一次URL就過濾一遍整個隊列，將相同的URL隊列消息刪除出隊列。這樣就可以保 證更新依次頁面，就可以相應所有更新事件。取出后依據使用的緩存系統發(fā)送相應的Purge請求或者自主生成新的緩存頁面覆蓋老的野蠻來更新緩存。

這種去重復的隊列實現可以用現有的模塊，比如Python的一個Queue模塊，繼承此模塊中的類并重寫幾個方法即可實現這種去重的隊列。還可以使 用現有的隊列系統，甚至直接使用數據庫來實現隊列。使用數據庫有一個好處，就是當整個系統Down掉的時候，系統重啟后隊列中的消息還存在，可以繼續(xù)更新 這些頁面的緩存。如果直接使用內存中的隊列的話系統Down掉重啟就會導致一些未處理的隊列消息丟失，導致這些頁面的緩存都沒有更新。這種情況出現的幾率 還有出現后對系統的影響需要根據實際情況斟酌，論壇系統如果發(fā)帖不是十分頻繁，偶爾某個帖子或者回復沒有出現并不是非常嚴重的問題。

一個好的系統應該是針對發(fā)生故障的情況而設計的。假如緩存系統出現問題，導致沒有向緩存服務器發(fā)送更新請求，這時所有更新動作都不會得到相應，導致 用戶重復提交數據，可能會發(fā)生一些問題。這時如果能停掉緩存服務器，讓用戶直接訪問Web應用程序或許是一個好主意（或者如果沒有緩存的話服務器能被直接 大量直接訪問干掉），如果去做是一個問題。

Some Tips:

上面說的如果異步處理更新動作與緩存更新的話，可能會使更新觸發(fā)者看不到自己更新的數據。這時可以使用一些小花招，比如現在大部分的論壇系統在發(fā)帖后跳轉到一個“3秒后跳轉到帖子頁面”，就可以給緩存系統提供充分的更新緩存時間，對于用戶體驗來說也不會大打折扣。

有些頁面不能使用緩存，比如說帖子列表頁面。因為帖子列表頁面是會隨著最后回復時間來動態(tài)更新排列順序的，一個新帖或者回復可能會導致所有帖子列表 分頁內容發(fā)生變化，而帖子列表分頁可能有幾千甚至幾萬頁，全部都進行更新的話顯然是不可能也沒有必要的。因此這些頁面不適用頁面輸出緩存，但我們可以只緩 存帖子列表的第一頁或者前幾頁，因為絕大部分的訪問請求都是來自與這幾個頁面，每次更新動作都觸發(fā)這幾個頁面進行緩存更新也是沒有問題的。

假如網站每日發(fā)新帖的數量非常高，導致帖子列表更新十分頻繁，這時可以使用另外一種更新觸發(fā)機制，就是按時間來觸發(fā)更新。這樣定時更新的頻率比之前按動作進行更新會少一些，并且也不會過分加重隊列的負擔。

網站首頁的信息可能會比較復雜，觸發(fā)其更新的來源可能會很多，更新一次的成本也較高，而首頁對于事實性的要求也沒有那么高（比如說在某個板塊發(fā)布新 貼，這時在首頁的最新帖子列表中沒有看到此貼，對于絕大部分用戶來說并不是什么問題），因此也試用于按時間進行更新的機制，并且這個更新時間的間隔可以適 當的拉長一些。

類似的還有帖子回復頁，此頁面也是一個列表排序頁面，但是是順序時間排列的（帖子列表為倒序時間排列的），因此也十分適用與使用緩存。如果網站當初 設計的功能為顯示所有樓層，刪除某一樓層的話此位置消失，這樣的話如果刪除一個樓層將會導致此頁面和接下來所有頁面的內容發(fā)生變化。因此在網站設計時最好 設計成這樣：刪除一條回復，此回復還在，只不過內容改為了“評論已刪除”，這樣就不會觸發(fā)所有后來頁面進行緩存更新了。

文章題目：關于頁面輸出緩存（頁面靜態(tài)化）的設計
分享路徑：http://www.bm7419.com/news35/313285.html

成都網站建設公司_創(chuàng)新互聯，為您提供網站收錄、自適應網站、手機網站建設、定制網站、電子商務、移動網站建設

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯