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

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


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

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