專利名稱：一種靜態(tài)化頁面的處理系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及web頁面處理技術(shù)，尤其涉及一種靜態(tài)化頁面的處理系統(tǒng)和方法。
背景技術(shù)：
靜態(tài)化是解決減輕網(wǎng)站壓力，提高網(wǎng)站訪問速度的常用方案。目前主要的靜態(tài)化方法是在開發(fā)中通過編碼對需要靜態(tài)化的部分進(jìn)行處理，靜態(tài)化的過程發(fā)生在服務(wù)器端腳本程序中。在網(wǎng)站中，訪問者看到的頁面基本上是靜態(tài)頁面。頁面靜態(tài)化能夠使訪問速度較快，有利于搜索引擎收錄。目前主流的靜態(tài)化主要有兩種第一種是通過程序?qū)討B(tài)頁面抓取并保存為靜態(tài)頁面，這樣的頁面實際存在于服務(wù)器的硬盤中；第二種是通過WEB服務(wù)器的URL Rewrite的方式，他的原理是通過web服務(wù)器內(nèi)部模塊按一定規(guī)則將外部的URL請求轉(zhuǎn)化為內(nèi)部的文件地址，也就是把外部請求的靜態(tài)地址轉(zhuǎn)化為實際的動態(tài)頁面地址，而靜態(tài)頁面實際是不存在的。這兩種方法都達(dá)到了實現(xiàn)URL靜態(tài)化的效果，但是也各有各自的特點。將動態(tài)頁面轉(zhuǎn)化為實際存在的靜態(tài)頁面這種方法，由于靜態(tài)頁面的存在，少了動態(tài)解析過程，所以提高了頁面的訪問速度和穩(wěn)定性，使得優(yōu)化效果非常明顯。所以這種方法被廣泛采用。但是它的局限性同樣存在。對于大型網(wǎng)站而言，這種方法將帶來不可忽視的問題。首先，由于生成的文件數(shù)量較多，存儲需要考慮文件、文件夾的數(shù)量問題和磁盤空間容量的問題；其次，頁面維護(hù)的復(fù)雜性和大工作量，及帶來的頁面維護(hù)及時性問題，需要一整套站點更新制度。而URL Rewrite方式特點同樣鮮明，由于是服務(wù)器內(nèi)部解析的地址，所以內(nèi)容是實時更新的，也不存在文件管理和硬件問題。在服務(wù)器級URL Rewrite重寫技術(shù)并不影響頁面的執(zhí)行速度。但是URL Rewrite的門濫比較高，國內(nèi)虛擬主機(jī)大多不支持,而且虛擬主機(jī)是目錄級的URL Rewrite,通過遍歷目錄讀物URL轉(zhuǎn)發(fā)規(guī)則的方式將大大降低頁面的執(zhí)行速度?，F(xiàn)有的靜態(tài)化方法應(yīng)用比較復(fù)雜，需要進(jìn)行大量編碼還需要對靜態(tài)化后的內(nèi)容進(jìn)行存儲管理，并且由于靜態(tài)化的過程在服務(wù)器端腳本程序中處理，所以整體效率不高。

發(fā)明內(nèi)容
針對上述缺陷，本發(fā)明的目的在于設(shè)計一種方便搭建的web系統(tǒng)靜態(tài)化解決方案，充分利用web服務(wù)器處理純靜態(tài)化內(nèi)容高效的特點，提高靜態(tài)化后網(wǎng)站的效率。為此，本發(fā)明首先提供一種靜態(tài)化頁面處理系統(tǒng)，包括web緩存服務(wù)器、web服務(wù)器、用戶終端，其特征在于所述web緩存服務(wù)器是Nginx服務(wù)器；所述web緩存服務(wù)器用于接收用戶終端發(fā)來的url請求，并檢查所述url請求是否已被緩存；如果已被緩存，則直接將緩存結(jié)果返回給用戶，如果未被緩存，則保持用戶的url請求的目標(biāo)地址不變，而生成新的url請求傳到所述web服務(wù)器。
進(jìn)一步，該系統(tǒng)還包括一服務(wù)器端腳本處理；web服務(wù)器接收web緩存服務(wù)器發(fā)送的url請求后,通過處理偽靜態(tài)請求的方式,將所述url請求轉(zhuǎn)換為實際動態(tài)請求；并web服務(wù)器將所述動態(tài)請求發(fā)送至所述服務(wù)器端腳本處理單元。所述偽靜態(tài)請求的方式為通過web服務(wù)器自帶的rewrite規(guī)則將靜態(tài)地址轉(zhuǎn)化為動態(tài)地址。更進(jìn)一步，所述web服務(wù)器接收服務(wù)器端腳本處理處理單元發(fā)送的經(jīng)處理后得到的結(jié)果，將所述經(jīng)處理后得到的結(jié)果返回到所述web緩存服務(wù)器；所述web緩存服務(wù)器對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存，并將緩存的結(jié)果發(fā)送至用戶終端。更為優(yōu)選地，對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存是將url請求及配置的相關(guān)信息組合當(dāng)作Key，用md5編碼哈希后保存在硬盤上的指定位置；所述web緩存服務(wù)器對緩存過期后的文件進(jìn)行自動刪除。此外，本發(fā)明還提供一種靜態(tài)化頁面處理方法，包括以下步驟
步驟100、web緩存服務(wù)器接收用戶終端發(fā)來的url請求。步驟200、web緩存服務(wù)器檢查用戶發(fā)出的url請求是否已被緩存；如果已被緩存，則直接將緩存結(jié)果返回給用戶，如果未被緩存，則執(zhí)行步驟300 ；
步驟300、web緩存服務(wù)器保持用戶的url請求的目標(biāo)地址不變,而生成新的url請求傳到web服務(wù)器，
其中，所述web緩存服務(wù)器是Nginx服務(wù)器。進(jìn)一步，該方法還包括
步驟400、web服務(wù)器接收web緩存服務(wù)器發(fā)送的url請求，并通過處理偽靜態(tài)請求的方式，將所述url請求轉(zhuǎn)換為實際動態(tài)請求；所述偽靜態(tài)請求的方式為通過web服務(wù)器自帶的rewrite規(guī)則將靜態(tài)地址轉(zhuǎn)化為動態(tài)地址。步驟500、web服務(wù)器將所述動態(tài)請求發(fā)送至服務(wù)器端腳本處理處理單元。以及，步驟600、web服務(wù)器接收服務(wù)器端腳本處理處理單元發(fā)送的經(jīng)處理后得到的結(jié)果；所述經(jīng)處理后得到的結(jié)果，是對所述動態(tài)請求的響應(yīng)結(jié)果。步驟700、web服務(wù)器將所述經(jīng)處理后得到的結(jié)果返回到所述web緩存服務(wù)器。非限制性地，該方法還包括步驟800、web緩存服務(wù)器對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存，并將緩存的結(jié)果發(fā)送至用戶終端。優(yōu)選地，所述對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存，是將url請求及配置的相關(guān)信息組合當(dāng)作Key，用md5編碼哈希后保存在硬盤上的指定位置。本發(fā)明提供的技術(shù)方案可以利用web緩存服務(wù)器的緩存功能進(jìn)行緩存的管理，不需要開發(fā)人員自行處理緩存的存儲工作，所以具有配置簡單，易于管理的特點。并且由于緩存是在web緩存服務(wù)器中實現(xiàn)，當(dāng)用戶請求命中緩存后可大大減少服務(wù)器處理的時間，降低真實web服務(wù)器的壓力，提高服務(wù)器運行效率，提高負(fù)載能力。


圖1為本發(fā)明靜態(tài)化頁面處理系統(tǒng)的示意 圖2為本發(fā)明靜態(tài)化頁面處理方法流程 圖3為本發(fā)明靜態(tài)化頁面處理方法的數(shù)據(jù)流向圖。
具體實施例方式為了使發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白，以下結(jié)合附圖及實施方式，對本發(fā)明進(jìn)一步詳細(xì)說明。應(yīng)當(dāng)理解所描述的具體實施方式
僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。如圖1所示，本發(fā)明的第一實施方式中，非限制性地展示了一種靜態(tài)化頁面處理系統(tǒng)，包括用戶終端l、web緩存服務(wù)器2、web服務(wù)器3，所述web緩存服務(wù)器用于接收用戶終端發(fā)來的url請求，并檢查所述url請求是否已被緩存；如果已被緩存，則直接將緩存結(jié)果返回給用戶，如果未被緩存，則保持用戶的url請求的目標(biāo)地址不變，而生成新的url請求傳到所述web服務(wù)器。更為優(yōu)選得實施方式中，所述web緩存服務(wù)器是Nginx服務(wù)器；利用Nginx服務(wù)器本身帶有的緩存功能對通過web服務(wù)器返回的偽靜態(tài)化內(nèi)容進(jìn)行緩存。Nginx服務(wù)器是一個高性能的HTTP和反向代理服務(wù)器，具備IMAP/P0P3和SMTP服務(wù)器功能。Nginx最大的特點是對高并發(fā)的支持和高效的負(fù)載均衡，在高并發(fā)的需求場景下，是Apache服務(wù)器不錯的替代品。Nginx與其他web服務(wù)器相比較有內(nèi)存占用少，穩(wěn)定性高的優(yōu)勢，并發(fā)能力強(qiáng)，并且有豐富的模塊庫，易于配置。進(jìn)一步，該系統(tǒng)還包括一服務(wù)器端腳本處理；web服務(wù)器接收web緩存服務(wù)器發(fā)送的url請求后,通過處理偽靜態(tài)請求的方式,將所述url請求轉(zhuǎn)換為實際動態(tài)請求；并web服務(wù)器將所述動態(tài)請求發(fā)送至所述服務(wù)器端腳本處理單元。所述偽靜態(tài)請求的方式為通過web服務(wù)器自帶的rewrite規(guī)則將靜態(tài)地址轉(zhuǎn)化為動態(tài)地址。更進(jìn)一步，所述web服務(wù)器接收服務(wù)器端腳本處理處理單元發(fā)送的經(jīng)處理后得到的結(jié)果，將所述經(jīng)處理后得到的結(jié)果返回到所述web緩存服務(wù)器；所述web緩存服務(wù)器對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存，并將緩存的結(jié)果發(fā)送至用戶終端。更為優(yōu)選地，對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存是將url請求及配置的相關(guān)信息組合當(dāng)作Key，用md5編碼哈希后保存在硬盤上的指定位置；所述web緩存服務(wù)器對緩存過期后的文件進(jìn)行自動刪除。本發(fā)明的第二實施方式中，展示了一種靜態(tài)化頁面處理方法，如圖2所示，包括以下步驟
步驟100、web緩存服務(wù)器接收用戶終端發(fā)來的url請求；
步驟200、web緩存服務(wù)器檢查用戶發(fā)出的url請求是否已被緩存；如果已被緩存，則直接將緩存結(jié)果返回給用戶，如果未被緩存，則執(zhí)行步驟300。步驟300、web緩存服務(wù)器保持用戶的url請求的目標(biāo)地址不變，而生成新的url請求傳到web服務(wù)器。步驟400、web服務(wù)器接收web緩存服務(wù)器發(fā)送的url請求,并通過處理偽靜態(tài)請求的方式，將所述url請求轉(zhuǎn)換為實際動態(tài)請求。步驟500、web服務(wù)器將所述動態(tài)請求發(fā)送至服務(wù)器端腳本處理處理單元。所述偽靜態(tài)請求的方式為通過web服務(wù)器自帶的rewrite規(guī)則將靜態(tài)地址轉(zhuǎn)化為動態(tài)地址。步驟600、web服務(wù)器接收服務(wù)器端腳本處理處理單元發(fā)送的經(jīng)處理后得到的結(jié)果。所述經(jīng)處理后得到的結(jié)果，是對所述動態(tài)請求的響應(yīng)結(jié)果。步驟700、web服務(wù)器將所述經(jīng)處理后得到的結(jié)果返回到所述web緩存服務(wù)器。步驟800、web緩存服務(wù)器對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存，并將緩存的結(jié)果發(fā)送至用戶終端。對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存是將url請求及配置的相關(guān)信息組合當(dāng)作Key，用md5編碼哈希后保存在硬盤上的指定位置。配置中有對過期時間的設(shè)置，緩存過期后會自動刪除。本發(fā)明的實施方式中，所提到的系統(tǒng)和方法優(yōu)選使用Nginx服務(wù)器作為前端web緩存服務(wù)器，利用Nginx的proxy_cache相關(guān)指令集進(jìn)行配置緩存服務(wù)功能,連接真實web服務(wù)器并進(jìn)行偽靜態(tài)化配置，web服務(wù)器包含服務(wù)器端腳本程序。為了更進(jìn)一步說明本發(fā)明的第二實施方式，參見圖3，其描繪了本發(fā)明提供的網(wǎng)站頁面靜態(tài)化的具體實現(xiàn)，主要包括以下步驟
步驟I 01、 用戶(終端)向系統(tǒng)發(fā)出u r I請求
U 到前端web緩存服務(wù)器，Nginx服務(wù)器檢查當(dāng)前請求是否已被緩存。步驟102、如果緩存存在則直接將緩存結(jié)果html 返回給用戶，如果沒有有效緩存，則在保持url請求的目標(biāo)地址不變的條件下生成url請求L々傳到真實web服務(wù)器上。

步驟103、真實web服務(wù)器接收url請求;.2」，并通過處理偽靜態(tài)請求的方式,例如
通過web服務(wù)器自帶的rewrite規(guī)則將靜態(tài)地址轉(zhuǎn)化為動態(tài)地址,轉(zhuǎn)換為實際動態(tài)請求*3)交由服務(wù)器端腳本程序處理。步驟104、將處理后得到的結(jié)果4返回給web服務(wù)器，結(jié)果4是動態(tài)請求4的響應(yīng)結(jié)果，web服務(wù)器再將結(jié)果；的內(nèi)容通過處理結(jié)果3返回到作為前端web緩存服務(wù)器的Nginx服務(wù)，結(jié)果是請求3的響應(yīng)結(jié)果。步驟105、利用Nginx的web緩存功能對結(jié)果進(jìn)行緩存并將html (■-返回給用戶，
html .C:是請求的響應(yīng)結(jié)果。緩存是將url請求及配置的相關(guān)信息組合當(dāng)作Key,用md5
編碼哈希后保存在硬盤上的指定位置。配置中有對過期時間的設(shè)置，緩存過期后會自動刪除。本發(fā)明提供的技術(shù)方案可以利用web緩存服務(wù)器的緩存功能進(jìn)行緩存的管理，不需要開發(fā)人員自行處理緩存的存儲工作，所以具有配置簡單，易于管理的特點。并且由于緩存存在于web緩存服務(wù)器中，當(dāng)用戶請求命中緩存后可大大減少服務(wù)器處理的時間，降低真實web服務(wù)器的壓力，提高服務(wù)器運行效率，提高負(fù)載能力?？梢哉J(rèn)為，本發(fā)明和許多其呈現(xiàn)出的優(yōu)勢能夠通過上述的說明書得以理解，在不偏離公開的主題或沒有失去其所有物質(zhì)優(yōu)勢的前提下，實現(xiàn)組件在形式上、結(jié)構(gòu)上和排列上的各種變化是顯而易見的。本發(fā)明的說明形式僅僅是示例性的，所附權(quán)利要求的目的包括保護(hù)這些變化。
權(quán)利要求
1.一種靜態(tài)化頁面處理系統(tǒng)，包括web緩存服務(wù)器、web服務(wù)器、用戶終端，其特征在于 所述web緩存服務(wù)器是Nginx服務(wù)器； 所述web緩存服務(wù)器用于接收用戶終端發(fā)來的url請求，并檢查所述url請求是否已被緩存；如果已被緩存，則直接將緩存結(jié)果返回給用戶，如果未被緩存，則保持用戶的url請求的目標(biāo)地址不變，而生成新的url請求傳到所述web服務(wù)器。
2.如權(quán)利要求1所述的靜態(tài)化頁面處理系統(tǒng)，其特征在于 還包括一服務(wù)器端腳本處理； web服務(wù)器接收web緩存服務(wù)器發(fā)送的url請求后，通過處理偽靜態(tài)請求的方式，將所述url請求轉(zhuǎn)換為實際動態(tài)請求；并將所述動態(tài)請求發(fā)送至所述服務(wù)器端腳本處理單元進(jìn)行處理。
3.如權(quán)利要求2所述的靜態(tài)化頁面處理系統(tǒng)，其特征在于處理偽靜態(tài)請求的方式為web服務(wù)器根據(jù)設(shè)定的rewrite規(guī)則將靜態(tài)地址轉(zhuǎn)化為動態(tài)地址。
4.如權(quán)利要求3所述的靜態(tài)化頁面處理系統(tǒng)，其特征在于 所述web服務(wù)器將所述動態(tài)請求發(fā)送至所述服務(wù)器端腳本處理單元進(jìn)行處理后，接收服務(wù)器端腳本處理單元發(fā)送的經(jīng)處理后得到的結(jié)果，并將所述經(jīng)處理后得到的結(jié)果轉(zhuǎn)發(fā)到所述web緩存服務(wù)器； 所述web緩存服務(wù)器接收并緩存所述經(jīng)處理后得到的結(jié)果，并將緩存的結(jié)果發(fā)送至用戶終端。
5.如權(quán)利要求4所述的靜態(tài)化頁面處理系統(tǒng)，其特征在于 對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存是將url請求及配置的相關(guān)信息組合當(dāng)作Key，用md5編碼哈希后保存在硬盤上的指定位置； 所述web緩存服務(wù)器對緩存過期后的文件進(jìn)行自動刪除。
6.一種靜態(tài)化頁面處理方法，包括以下步驟 步驟100、web緩存服務(wù)器接收用戶終端發(fā)來的url請求； 步驟200、web緩存服務(wù)器檢查用戶發(fā)出的url請求是否已被緩存；如果已被緩存，則直接將緩存結(jié)果返回給用戶，如果未被緩存，則執(zhí)行步驟300 ； 步驟300、web緩存服務(wù)器保持用戶的url請求的目標(biāo)地址不變,而生成新的url請求傳到web服務(wù)器， 其中，所述web緩存服務(wù)器是Nginx服務(wù)器。
7.如權(quán)利要求6所述的靜態(tài)化頁面處理方法，其特征在于，還包括 步驟400、web服務(wù)器接收web緩存服務(wù)器發(fā)送的url請求，并通過處理偽靜態(tài)請求的方式，將所述url請求轉(zhuǎn)換為實際動態(tài)請求；所述偽靜態(tài)請求的方式為通過web服務(wù)器自帶的rewrite規(guī)則將靜態(tài)地址轉(zhuǎn)化為動態(tài)地址； 步驟500、web服務(wù)器將所述動態(tài)請求發(fā)送至服務(wù)器端腳本處理處理單元。
8.如權(quán)利要求7所述的靜態(tài)化頁面處理方法，其特征在于 步驟600、web服務(wù)器接收服務(wù)器端腳本處理處理單元發(fā)送的經(jīng)處理后得到的結(jié)果；所述經(jīng)處理后得到的結(jié)果，是對所述動態(tài)請求的響應(yīng)結(jié)果； 步驟700、web服務(wù)器將所述經(jīng)處理后得到的結(jié)果返回到所述web緩存服務(wù)器。
9.如權(quán)利要求8所述的靜態(tài)化頁面處理方法，其特征在于，還包括 步驟800、web緩存服務(wù)器對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存，并將緩存的結(jié)果發(fā)送至用戶終端。
10.如權(quán)利要求9所述的靜態(tài)化頁面處理方法，其特征在于，還包括 所述對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存，是將url請求及配置的相關(guān)信息組合當(dāng)作Key，用md5編碼哈希后保存在硬盤上的指定位置。
全文摘要
本發(fā)明提供一種靜態(tài)化頁面處理系統(tǒng)和方法，通過web緩存服務(wù)器接收用戶終端發(fā)來的url請求，并檢查用戶發(fā)出的url請求是否已被緩存；如果已被緩存，直接將緩存結(jié)果返回給用戶，如果未被緩存，保持用戶的url請求的目標(biāo)地址不變并生成新的url請求傳到web服務(wù)器，web服務(wù)器將該url請求轉(zhuǎn)換為實際動態(tài)請求；服務(wù)器端腳本處理處理單元經(jīng)處理后返回web服務(wù)器，web服務(wù)器將結(jié)果返回到所述web緩存服務(wù)器，web緩存服務(wù)器對所述經(jīng)處理后得到的結(jié)果進(jìn)行緩存，并將緩存的結(jié)果發(fā)送至用戶終端。本發(fā)明的技術(shù)方案利用web緩存服務(wù)器的緩存功能進(jìn)行緩存的管理，配置簡單，易于管理，并可減少服務(wù)器處理的時間，降低真實web服務(wù)器的壓力，提高服務(wù)器運行效率。
文檔編號G06F17/30GK103064932SQ20121056494
公開日2013年4月24日 申請日期2012年12月24日 優(yōu)先權(quán)日2012年12月24日
發(fā)明者張喆浩, 金宗銳 申請人:樂視網(wǎng)信息技術(shù)(北京)股份有限公司