關(guān)于頁面輸出緩存(頁面靜態(tài)化)的設(shè)計(jì)

2024-01-12    分類: 網(wǎng)站建設(shè)

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

其中最簡單,需要配置最少的莫過于數(shù)據(jù)庫和Web應(yīng)用程序之間了,并且見效也最快,因?yàn)閷τ诂F(xiàn)代計(jì)算機(jī)系統(tǒng)來說IO是大的瓶頸。常見的方法就是使用MemCache或者K-V型NoSQL數(shù)據(jù)庫做緩存。

這么安逸了一段時(shí)間之后,網(wǎng)站的響應(yīng)速度還是會降下來,如果你不想增加服務(wù)器的話,這時(shí)需要做的就是頁面輸出緩存了。

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

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

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

其實(shí)這個(gè)問題是在頁面?zhèn)€性化部分與非個(gè)性化部分合成的時(shí)間問題上。傳統(tǒng)網(wǎng)站這個(gè)個(gè)性化部分也非個(gè)性化部分是直接放在Web應(yīng)用程序上的,這樣就導(dǎo)致不同用戶輸出頁面的不同,緩存不能進(jìn)行。如果把這個(gè)過程放在頁面緩存程序之后,使緩存的結(jié)果相同就沒有問題了。

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

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

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

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

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

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

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

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

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

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

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

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

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

一個(gè)好的系統(tǒng)應(yīng)該是針對發(fā)生故障的情況而設(shè)計(jì)的。假如緩存系統(tǒng)出現(xiàn)問題,導(dǎo)致沒有向緩存服務(wù)器發(fā)送更新請求,這時(shí)所有更新動作都不會得到相應(yīng),導(dǎo)致 用戶重復(fù)提交數(shù)據(jù),可能會發(fā)生一些問題。這時(shí)如果能停掉緩存服務(wù)器,讓用戶直接訪問Web應(yīng)用程序或許是一個(gè)好主意(或者如果沒有緩存的話服務(wù)器能被直接 大量直接訪問干掉),如果去做是一個(gè)問題。

Some Tips:

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

有些頁面不能使用緩存,比如說帖子列表頁面。因?yàn)樘恿斜眄撁媸菚S著最后回復(fù)時(shí)間來動態(tài)更新排列順序的,一個(gè)新帖或者回復(fù)可能會導(dǎo)致所有帖子列表 分頁內(nèi)容發(fā)生變化,而帖子列表分頁可能有幾千甚至幾萬頁,全部都進(jìn)行更新的話顯然是不可能也沒有必要的。因此這些頁面不適用頁面輸出緩存,但我們可以只緩 存帖子列表的第一頁或者前幾頁,因?yàn)榻^大部分的訪問請求都是來自與這幾個(gè)頁面,每次更新動作都觸發(fā)這幾個(gè)頁面進(jìn)行緩存更新也是沒有問題的。

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

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

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

文章題目:關(guān)于頁面輸出緩存(頁面靜態(tài)化)的設(shè)計(jì)
分享路徑:http://www.muchs.cn/news35/313285.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站收錄、自適應(yīng)網(wǎng)站、手機(jī)網(wǎng)站建設(shè)、定制網(wǎng)站、電子商務(wù)移動網(wǎng)站建設(shè)

廣告

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

手機(jī)網(wǎng)站建設(shè)