處理用戶訪問網(wǎng)頁的請求的方法及系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了處理用戶訪問網(wǎng)頁的請求的方法及系統(tǒng)，其中，在同一臺代理服務(wù)器中預(yù)先啟動至少兩個進程，每個進程中創(chuàng)建至少兩個處理單元，所述方法包括：在接收到多個用戶訪問網(wǎng)頁的當(dāng)前請求時，根據(jù)各個用戶的屬性信息以及各個進程的狀態(tài)信息，為各個用戶的當(dāng)前請求分配進程；在所述分配的進程中為所述當(dāng)前請求分配處理單元；通過所述分配的處理單元，向所述當(dāng)前請求對應(yīng)的網(wǎng)頁服務(wù)器發(fā)送請求以獲取網(wǎng)頁內(nèi)容，以便返回給客戶端進行展現(xiàn)。能夠在大用戶量并發(fā)的情況下，提高代理服務(wù)器的響應(yīng)速度。
【專利說明】處理用戶訪問網(wǎng)頁的請求的方法及系統(tǒng)
[0001] 本發(fā)明專利申請是申請日為2012年05月02日、申請?zhí)枮?01210135416. 5、名稱 為"處理用戶訪問網(wǎng)頁的請求的方法及系統(tǒng)"的中國發(fā)明專利申請的分案申請。

【技術(shù)領(lǐng)域】
[0002] 本發(fā)明涉及計算機【技術(shù)領(lǐng)域】，特別是涉及處理用戶訪問網(wǎng)頁的請求的方法及系 統(tǒng)。

【背景技術(shù)】
[0003] 瀏覽器是用來從網(wǎng)站獲取網(wǎng)頁內(nèi)容的工具軟件。一般而言，它必須具備解析網(wǎng)頁 上的各種元素的能力，解析完成之后，要進行頁面各個元素的定位計算。然后，瀏覽器在調(diào) 用基于平臺的API來完成頁面的繪制，最終頁面上的各種元素才會顯示在用戶面前。這個 過程在PC上是一個很順暢的過程，但是在手機等移動終端上，由于移動通信技術(shù)的限制， 目前移動終端上網(wǎng)不可能達到以太網(wǎng)所能夠達到的傳輸速度，另外，由于一些移動終端的 硬件處理能力有限，而渲染、排版和繪制網(wǎng)頁頁面會耗費大量的資源進行計算，對于這些處 理能力有限的移動終端來說，需要消耗的時間和電量等開銷就好比較大，為了解決這些問 題，基于服務(wù)器渲染排版的技術(shù)便應(yīng)運而生了。
[0004] 該技術(shù)把耗時且費資源的操作封裝在服務(wù)端，使用這種技術(shù)的瀏覽器通常被設(shè)計 為c/s(客戶端/代理服務(wù)器）架構(gòu)。在這種架構(gòu)下，用戶訪問網(wǎng)頁的請求會被瀏覽器的 客戶端發(fā)送到代理服務(wù)器端，代理服務(wù)器向網(wǎng)頁服務(wù)器發(fā)送訪問網(wǎng)頁的請求，并獲取到網(wǎng) 頁資源之后，能夠?qū)Υ罅髁康馁Y源進行壓縮和處理，然后將壓縮和處理過的數(shù)據(jù)發(fā)送至客 戶端，客戶端只需對數(shù)據(jù)做簡單的操作就能顯示網(wǎng)頁內(nèi)容。這種輕客戶端的模式降低了對 移動終端的要求，但是又能夠在移動終端用戶使用的網(wǎng)絡(luò)低速，以及移動設(shè)備的處理能力 有限的情形下，也能獲得比較好的用戶體驗。所以目前這種基于服務(wù)端渲染排版的模式在 手機等移動終端使用的瀏覽器上大行其道，并且該技術(shù)向著客戶端更輕量化、服務(wù)端更重 量化的方向發(fā)展，例如，服務(wù)端負責(zé)大流量資源文件的壓縮、頁面的解析、頁面的定位計算 和頁面的排版，以及將排版后的結(jié)構(gòu)體轉(zhuǎn)換為能夠讓客戶端解析出來的二進制數(shù)據(jù)，這樣 客戶端直接根據(jù)對這些二進制數(shù)據(jù)進行解析，然后進行相應(yīng)的繪制及顯示即可。這種發(fā)展 方向有利于降低對移動終端硬件性能的要求，但是其缺點在于：由于服務(wù)端需要處理的工 作大幅增加了，而所有使用其客戶端的用戶請求都會發(fā)送到服務(wù)端，由服務(wù)端進行處理，因 此，在同一時間段內(nèi)多個用戶請求并發(fā)的情況下，可能會降低服務(wù)端的響應(yīng)速度，結(jié)果反而 降低了用戶的移動終端上瀏覽器的響應(yīng)速度。


【發(fā)明內(nèi)容】

[0005] 本發(fā)明提供了處理用戶訪問網(wǎng)頁的請求的方法及系統(tǒng)，能夠在大用戶量并發(fā)的情 況下，提高代理服務(wù)器的響應(yīng)速度。
[0006] 本發(fā)明提供了如下方案：
[0007] -種處理用戶訪問網(wǎng)頁的請求方法，在同一臺代理服務(wù)器中預(yù)先啟動至少兩個進 程，每個進程中創(chuàng)建至少兩個處理單元，所述方法包括：
[0008] 在接收到多個用戶訪問網(wǎng)頁的當(dāng)前請求時，根據(jù)各個用戶的屬性信息以及各個進 程的狀態(tài)信息，為各個用戶的當(dāng)前請求分配進程；
[0009] 在所述分配的進程中為所述當(dāng)前請求分配處理單元；
[0010] 通過所述分配的處理單元，向所述當(dāng)前請求對應(yīng)的網(wǎng)頁服務(wù)器發(fā)送請求以獲取網(wǎng) 頁內(nèi)容，以便返回給客戶端進行展現(xiàn)。
[0011] 其中，將同一用戶的不同請求分配給同一進程。
[0012] 其中，所述在接收到多個用戶訪問網(wǎng)頁的當(dāng)前請求時，根據(jù)各個用戶的屬性信息 以及各個進程的狀態(tài)信息，為各個用戶的當(dāng)前請求分配進程，包括：
[0013] 根據(jù)各個用戶的屬性信息判斷當(dāng)前請求是否為新用戶的請求；
[0014] 如果當(dāng)前請求不是新用戶的請求，則根據(jù)該用戶的分配歷史以及各個進程的狀態(tài) 信息為所述當(dāng)前請求分配進程。
[0015] 其中，所述根據(jù)各個用戶的屬性信息判斷當(dāng)前請求是否為新用戶的請求包括：
[0016] 獲取所述當(dāng)前請求對應(yīng)的用戶的屬性信息；
[0017] 如果當(dāng)前請求對應(yīng)的用戶的屬性信息未出現(xiàn)在所述歷史分配記錄中，則所述當(dāng)前 請求為新用戶的請求；其中，所述歷史分配記錄用于記錄在歷史處理過程中，用戶請求對應(yīng) 的用戶的屬性信息與分配給該用戶請求的進程之間的對應(yīng)關(guān)系。
[0018] 其中，所述如果當(dāng)前請求不是新用戶的請求，則根據(jù)該用戶的分配歷史以及各個 進程的狀態(tài)信息為所述當(dāng)前請求分配進程，包括：
[0019] 如果所述當(dāng)前請求不是新用戶的請求，并且歷史分配記錄中該用戶的屬性信息對 應(yīng)的進程包含空閑的處理單元，則將該進程分配給當(dāng)前請求。
[0020] 其中，所述歷史分配記錄中還記錄有用戶請求對應(yīng)的用戶的屬性信息與分配給請 求的處理單元之間的對應(yīng)關(guān)系；
[0021] 所述在分配的進程中為所述請求分配處理單元，包括：
[0022] 將歷史分配記錄中該用戶的屬性信息對應(yīng)的處理單元分配給當(dāng)前請求。
[0023] 其中，還包括：
[0024] 如果當(dāng)前請求是新用戶的請求，則將當(dāng)前具有最多空閑處理單元的進程分配給當(dāng) 前請求。
[0025] 其中，還包括：
[0026] 如果全部進程中都不存在空閑處理單元，則判斷是否存在處理時間超時的處理單 元，如果是，則將該處理單元所在的進程分配給當(dāng)前請求；
[0027] 所述在所述分配的進程中為所述當(dāng)前請求分配處理單元包括：
[0028] 將所述處理時間超時的處理單元的當(dāng)前任務(wù)結(jié)束，并將其分配給當(dāng)前請求。
[0029] 其中，所述代理服務(wù)器為至少兩個，所述方法還包括：
[0030] 為各個用戶的當(dāng)前請求分配代理服務(wù)器。
[0031] 其中，所述為各個用戶的當(dāng)前請求分配代理服務(wù)器包括：
[0032] 對各代理服務(wù)器進行實時的心跳監(jiān)控，將能夠正常監(jiān)測到心跳信息的代理服務(wù)器 加入到可用代理服務(wù)器列表中；
[0033] 從所述可用代理服務(wù)器列表中為當(dāng)前請求分配代理服務(wù)器。
[0034] 其中，還包括：
[0035] 將未能監(jiān)測到心跳信息的代理服務(wù)器從所述可用代理服務(wù)器列表中刪除；當(dāng)重新 監(jiān)測到代理服務(wù)器的心跳信息時，將其加入到所述可用代理服務(wù)器列表中。
[0036] -種處理用戶訪問網(wǎng)頁的請求系統(tǒng)，在同一臺代理服務(wù)器中預(yù)先啟動至少兩個進 程，每個進程中創(chuàng)建至少兩個處理單元，所述系統(tǒng)包括：
[0037] 進程分配模塊，用于在接收到多個用戶訪問網(wǎng)頁的當(dāng)前請求時，根據(jù)各個用戶的 屬性信息以及各個進程的狀態(tài)信息，為所述各個用戶的當(dāng)前請求分配進程；
[0038] 處理單元分配模塊，用于在所述分配的進程中為所述當(dāng)前請求分配處理單元；
[0039] 網(wǎng)頁內(nèi)容處理模塊，用于通過所述分配的處理單元，向所述當(dāng)前請求對應(yīng)的網(wǎng)頁 服務(wù)器發(fā)送請求以獲取網(wǎng)頁內(nèi)容，以便返回給客戶端進行展現(xiàn)。
[0040] 其中，將同一用戶的不同請求分配給同一進程。
[0041] 其中，所述進程分配模塊包括：
[0042] 判斷子模塊，用于根據(jù)各個用戶的屬性信息判斷當(dāng)前請求是否為新用戶的請求；
[0043] 進程分配子模塊，用于如果當(dāng)前請求不是新用戶的請求，則根據(jù)該用戶的分配歷 史以及各個進程的狀態(tài)信息為所述當(dāng)前請求分配進程。
[0044] 其中，所述判斷子模塊包括：
[0045] 用戶標識獲取子模塊，用于獲取所述當(dāng)前請求對應(yīng)的用戶的屬性信息；
[0046] 比對子模塊，用于如果當(dāng)前請求對應(yīng)的用戶的屬性信息未出現(xiàn)在所述歷史分配記 錄中，則所述當(dāng)前請求為新用戶的請求；其中，所述歷史分配記錄用于記錄在歷史處理過程 中，用戶請求對應(yīng)的用戶的屬性信息與分配給該用戶請求的進程之間的對應(yīng)關(guān)系。
[0047] 其中，所述進程分配子模塊具體用于：
[0048] 如果所述當(dāng)前請求不是新用戶的請求，并且歷史分配記錄中該用戶的屬性信息對 應(yīng)的進程包含空閑的處理單元，則將該進程分配給當(dāng)前請求。
[0049] 其中，所述歷史分配記錄中還記錄有用戶請求對應(yīng)的用戶的屬性信息與分配給請 求的處理單元之間的對應(yīng)關(guān)系；
[0050] 所述處理單元分配模塊具體用于：
[0051] 將歷史分配記錄中該用戶的屬性信息對應(yīng)的處理單元分配給當(dāng)前請求。
[0052] 其中，還包括：
[0053] 新用戶請求分配模塊，用于如果當(dāng)前請求是新用戶的請求，則將當(dāng)前具有最多空 閑處理單元的進程分配給當(dāng)前請求。
[0054] 其中，還包括：
[0055] 超時處理模塊，用于如果全部進程中都不存在空閑處理單元，則判斷是否存在處 理時間超時的處理單元，如果是，則將該處理單元所在的進程分配給當(dāng)前請求；
[0056] 所述處理單元分配模塊具體用于：
[0057] 將所述處理時間超時的處理單元的當(dāng)前任務(wù)結(jié)束，并將其分配給當(dāng)前請求。
[0058] 其中，所述代理服務(wù)器為至少兩個，所述系統(tǒng)還包括：
[0059] 代理服務(wù)器分配模塊，用于為各個用戶的當(dāng)前請求分配代理服務(wù)器。
[0060] 其中，所述代理服務(wù)器分配模塊包括：
[0061] 心跳監(jiān)控子模塊，用于對各代理服務(wù)器進行實時的心跳監(jiān)控，將能夠正常監(jiān)測到 心跳信息的代理服務(wù)器加入到可用代理服務(wù)器列表中；
[0062] 代理服務(wù)器分配子模塊，用于從所述可用代理服務(wù)器列表中為當(dāng)前請求分配代理 服務(wù)器。
[0063] 其中，還包括：
[0064] 列表更新模塊，用于將未能監(jiān)測到心跳信息的代理服務(wù)器從所述可用代理服務(wù)器 列表中刪除；當(dāng)重新監(jiān)測到代理服務(wù)器的心跳信息時，將其加入到所述可用代理服務(wù)器列 表中。
[0065] 根據(jù)本發(fā)明提供的具體實施例，本發(fā)明公開了以下技術(shù)效果：
[0066] 通過本發(fā)明，可以預(yù)先在同一臺代理服務(wù)器中啟動多個進程并在每個進程中創(chuàng)建 多個處理單元，這樣，就不必在用戶請求到達時再重新進行進程及處理單元的創(chuàng)建，因此， 可以縮短用戶實際感知到的處理時間，而且能夠滿足大用戶量并發(fā)時的處理需求；同時，多 進程的方式可以充分代理服務(wù)器中多核的資源，提高處理效率，這也能提高服務(wù)器的響應(yīng) 速度。

【專利附圖】

【附圖說明】
[0067] 為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例中所 需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施 例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲 得其他的附圖。
[0068] 圖1是本發(fā)明實施例提供的方法的流程圖；
[0069] 圖2是本發(fā)明實施例提供的另一方法的流程圖；
[0070] 圖3是本發(fā)明實施例提供的第一系統(tǒng)的示意圖；
[0071] 圖4是本發(fā)明實施例提供的第二系統(tǒng)的示意圖；
[0072] 圖5是本發(fā)明實施例提供的第三系統(tǒng)的示意圖。

【具體實施方式】
[0073] 下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完 整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；?本發(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員所獲得的所有其他實施例，都屬于本發(fā)明保護的 范圍。
[0074] 首先需要說明的是，本發(fā)明實施例是在基于服務(wù)器的網(wǎng)頁渲染排版技術(shù)基礎(chǔ)上進 行的改進，前提仍然是將耗時且費資源的操作封裝在服務(wù)端，由服務(wù)端進行需要大量計算 作業(yè)的網(wǎng)頁資源壓縮、頁面的解析、定位以及渲染排版等工作，通過這一系列的操作，將網(wǎng) 頁轉(zhuǎn)化為更加適合移動終端設(shè)備顯示的頁面，并將頁面以二進制數(shù)據(jù)的形式發(fā)送至移動終 端設(shè)備，由移動終端設(shè)備進行解析，由此，降低了使用移動終端設(shè)備訪問網(wǎng)頁時對網(wǎng)絡(luò)的需 求，以及移動終端處理網(wǎng)頁資源時的計算量。然而，隨著移動終端設(shè)備的多元化和普及程度 的提高，使用移動終端訪問網(wǎng)頁服務(wù)器的用戶數(shù)量高速增長，這就對傳統(tǒng)的基于服務(wù)器渲 染排版的技術(shù)提出了新的要求，比如在同一時間段內(nèi)，如果大量的用戶請求并發(fā)，可能會降 低服務(wù)端的響應(yīng)速度，服務(wù)端的作業(yè)出現(xiàn)延時甚至是服務(wù)器的部分資源停止響應(yīng)，結(jié)果反 而降低了瀏覽器的響應(yīng)速度。
[0075] 為了避免上述情況的發(fā)生，本發(fā)明實施例提供了相應(yīng)的解決方案，在此方案中，可 以在代理服務(wù)器中預(yù)先啟動多個進程，并在每個進程中啟動多個處理單元；這些處理單元 的作用相當(dāng)于普通瀏覽器（相對于C/S架構(gòu)瀏覽器）中的窗口（例如用戶在點擊某鏈接時， 普通的網(wǎng)頁瀏覽器會創(chuàng)建一個窗口，最終將頁面顯示在該窗口中），但也不完全等同。具體 而言，這種處理單元可以對用戶訪問網(wǎng)頁的請求進行處理，例如，包括將請求發(fā)送到網(wǎng)頁服 務(wù)器，然后對接收到的網(wǎng)頁數(shù)據(jù)進行解析、渲染、排版等一系列操作，但不同之處在于，由于 這種處理單元位于代理服務(wù)器端，因此并不需要具有顯示界面；而真正的顯示界面是由用 戶計算機上安裝的客戶端來創(chuàng)建的，因此，這種處理單元需要將網(wǎng)頁數(shù)據(jù)的處理結(jié)果通過 一些私有的協(xié)議發(fā)送給客戶端，由客戶端進行繪制并顯示在用戶界面上。
[0076] 換言之，本發(fā)明實施例中啟動的處理單元，與傳統(tǒng)的C/S架構(gòu)下用于處理用戶請 求的處理單元的作用相同，但創(chuàng)建的時機不同；在傳統(tǒng)的C/S架構(gòu)下，一般是在接收到用戶 請求之后，再進行處理單元的創(chuàng)建，這樣相當(dāng)于創(chuàng)建窗口的耗時也成為用戶可感知的網(wǎng)頁 處理時間的一部分；雖然一般而言創(chuàng)建窗口是很快的，但是在大用戶量并發(fā)的情況下，仍然 可能會導(dǎo)致整體處理時間的延長。而在本發(fā)明實施例中，處理單元是預(yù)先創(chuàng)建好的，當(dāng)接收 到用戶請求之后，只需要將用戶請求按照一定的策略分配到指定的處理單元即可，而不需 要每接收到一個用戶請求時再分別創(chuàng)建處理單元，因此可以從整體上提高響應(yīng)速度，從一 定程度上縮短用戶可感知的處理時間。
[0077] 另外，由于具體的處理單元是需要在一定的進程中創(chuàng)建的，而一個進程中允許創(chuàng) 建多個處理單元，這樣可以使得在一個進程中處理多個用戶請求，因此，在本發(fā)明實施例 中，采用了這種在進程中創(chuàng)建多個處理單元的方式。同時，一個進程中允許創(chuàng)建的處理單 元數(shù)目畢竟也是有限的，如果一臺代理服務(wù)器上僅啟動一個進程，則能夠容納的用戶請求 數(shù)量仍然會比較有限；另一方面，代理服務(wù)器一般會采用多核技術(shù)，也就是說一臺代理服務(wù) 器具有多個內(nèi)核，不同的進程在不同的內(nèi)核上可以同時運行，這樣可以大大提高處理速度。 因此，在本發(fā)明實施例中，還采用了在同一臺代理服務(wù)器上創(chuàng)建多個進程的方式，這樣，可 以提高單臺代理服務(wù)器可容納的用戶請求數(shù)量，同時充分利用代理服務(wù)器的多核的資源。 當(dāng)然，代理服務(wù)器上的進程也是先于用戶請求啟動的。
[0078] 在以上所述的前提下，參見圖1，本發(fā)明實施例提供的處理用戶訪問網(wǎng)頁的請求的 方法包括以下步驟：
[0079] S101 :在接收到多個用戶訪問網(wǎng)頁的當(dāng)前請求時，根據(jù)各個用戶的屬性信息以及 各個進程的狀態(tài)信息，為所述各個用戶的當(dāng)前請求分配進程；
[0080] S102 :在所述分配的進程中為所述當(dāng)前請求分配處理單元；
[0081] 用戶計算機上安裝的瀏覽器客戶端會首先接收到用戶訪問某網(wǎng)頁的當(dāng)前請求 (例如用戶當(dāng)前點擊了某鏈接，或者當(dāng)前在地址欄中輸入了某網(wǎng)址并執(zhí)行了確認操作等）， 然后客戶端將該當(dāng)前請求發(fā)送到服務(wù)器端。代理服務(wù)器端由于已經(jīng)預(yù)先啟動了多個進程， 因此，在接收到用戶請求之后，就可以將用戶的當(dāng)前請求分配到其中一個進程中。當(dāng)然，具 體能夠?qū)τ脩粽埱筮M行處理的是處理單元，而一個進程中還創(chuàng)建了多個處理單元，因此，還 需要將當(dāng)前請求分配到一個具體的處理單元中進行處理。
[0082] 具體在根據(jù)各個用戶的屬性信息以及各個進程的狀態(tài)信息，為各個用戶的當(dāng)前請 求分配進程及處理單元時，可以有多種方式，例如，直接將當(dāng)前請求分配到空閑處理單元最 多的進程中，然后在該進程中任選一個空閑的處理窗口等等?；蛘撸诒景l(fā)明實施例中，為 了保證資源的重復(fù)利用，可以盡量將同一用戶的不同請求分配到同一進程中，這樣可以進 一步節(jié)省處理時間。例如，有些網(wǎng)站（如某些購物網(wǎng)站等）需要用戶的賬戶及密碼等登錄 信息，一般情況下，用戶在訪問同一網(wǎng)站下的不同網(wǎng)頁時，只登錄一次即可，例如，用戶在某 網(wǎng)站的首頁上登錄之后，在訪問該網(wǎng)站的所有網(wǎng)頁時，登錄信息都是有效的。但在本發(fā)明實 施例中，由于同一臺代理服務(wù)器上會處理多個用戶的請求，要實現(xiàn)這種效果，其前提是這些 網(wǎng)頁對應(yīng)的處理單元在同一進程中。這是因為，當(dāng)在某進程中處理用戶的首次登陸請求后， 可以在瀏覽器的Cookie中進行保存一些信息，例如，在網(wǎng)站中的登錄信息，后續(xù)當(dāng)同一用 戶訪問同一網(wǎng)站中的其他網(wǎng)頁時，就可以從Cookie中取出保存的這些信息，從而保證登錄 狀態(tài)的連續(xù)性?；蛘?，Cookie中還可以保存用戶訪問過的網(wǎng)頁的數(shù)據(jù)信息等，針對用戶訪 問過的一個網(wǎng)頁，當(dāng)再次發(fā)起訪問時，可以直接根據(jù)保存的信息返回給用戶，而不必再重新 向網(wǎng)頁服務(wù)器發(fā)起請求，等等。這種Cookie會進行持久化存儲，但是如果是同一進程的不 同處理單元或者不同的進程處理"已經(jīng)有歷史記錄"的請求時，需要從持久化存儲獲取一次 信息，這樣不如直接由歷史處理單元處理時高效。因此，在本發(fā)明實施例中，為了實現(xiàn)前述 目的，在為用戶請求分配進程時，可以進來將同一用戶的請求分配到同一進程，甚至還可以 盡量分配到同一處理單元。為了該目的，具體實現(xiàn)時，可以首先判斷當(dāng)請請求是否為新用戶 的請求，然后根據(jù)判斷的結(jié)果向當(dāng)前請求進行進程的分配。具體實現(xiàn)時，參見圖2,還可以采 用如下方式來處理：
[0083] S201 :判斷當(dāng)前請求是否為新用戶的請求；如果是，則進入步驟S202,否則進入步 驟 S206 ;
[0084] 為了能夠判斷當(dāng)前請求是否為新用戶的請求，可以在歷史處理的過程中，在為用 戶請求分配進程的同時，還可以記錄下用戶請求對應(yīng)的用戶屬性信息與為該請求分配的進 程之間的對應(yīng)關(guān)系，這樣，在代理服務(wù)器端就可以維護一個歷史分配列表，在該列表中記錄 了為各個用戶分配的進程分別是哪個。當(dāng)接收到一個當(dāng)前請求時，同樣可以先獲取到該請 求對應(yīng)的用戶屬性信息，然后判斷該用戶屬性信息是否出現(xiàn)在歷史分配列表中，如果是，則 證明該用戶之前訪問過其他的網(wǎng)頁，也就是說，該當(dāng)前請求不是一個新用戶的請求；否則， 如果未出現(xiàn)在歷史分配列表中，則證明當(dāng)前請求是一個新用戶的請求。
[0085] 需要說明的是，歷史分配記錄中記錄的數(shù)據(jù)并不是永久性的，而是要在一定時間 后刪除，例如，對于某一條記錄，自生成之時起經(jīng)過一段預(yù)置的時間之后，就可以將其從歷 史分配記錄中刪除。也就是說，同一個用戶的請求對應(yīng)著一個大的會話（session)，該會話 建立之后，即使中間插入了其他用戶的請求，也不會中斷，但是該會話的存續(xù)仍然存在超時 時間，當(dāng)接收了一個用戶的某請求之后，如果很長一段時間之后都沒有再收到該用戶的請 求，則證明用戶目前可能不再需要訪問其他的網(wǎng)頁，相應(yīng)的，該會話也就可以結(jié)束。可見，這 里所謂的"新用戶"并不是新入網(wǎng)的用戶，或者新安裝了該C/S架構(gòu)的瀏覽器的用戶等等， 而是指在一定時間段內(nèi)是否有過訪問請求的用戶。
[0086] 在具體實現(xiàn)時，用戶屬性信息可以由瀏覽器客戶端的ID來表示。在實際應(yīng)用中， 在安裝瀏覽器客戶端時，會帶有唯一標識該瀏覽器客戶端的ID，客戶端在向服務(wù)器發(fā)送用 戶的訪問請求時，會攜帶該ID，因此，就可以通過該ID來區(qū)分不同的用戶。當(dāng)然，如果用戶 注冊過瀏覽器賬戶，并且當(dāng)前處于登錄狀態(tài)，則也可以根據(jù)用戶的登錄信息來獲取用戶屬 性信息，或者，還可以將用戶的IP地址作為用戶屬性信息，等等。關(guān)于各個進程的狀態(tài)信息 可以包括進程包括的空閑處理單元的數(shù)目等等。
[0087] S202 :判斷各個進程中是否存在空閑處理單元；如果是，則進入步驟S203,如果每 個進程中都不存在空閑的處理單元，進入步驟S204 ;
[0088] S203 :選出空閑窗口最多的進程分配給當(dāng)前請求，并從中選擇一個空閑窗口分配 給當(dāng)前請求；
[0089] S204 :判斷進程中是否存在處理時間超時的處理單元；如果是，則進入步驟S205， 否則，可以等待，直到有處理單元空閑，或者有處理單元的處理時間超時；
[0090] 如果某處理單元的處理時間超時，則證明該處理單元可能發(fā)生了故障，客戶端測 的窗口可能早已被用戶關(guān)閉，因此，可以將其結(jié)束，分配給其他請求使用。
[0091] S205 :將超時時間最長的處理單元及其對應(yīng)的進程分配給當(dāng)前請求；
[0092] S206 :獲取該用戶的歷史請求所在的進程，將該進程分配給當(dāng)前請求；
[0093] 當(dāng)然，在將該用戶的歷史請求所在的進程分配給該當(dāng)前請求之前，還可以首先判 斷下該進程是否存在空閑的處理單元，如果存在，則將其分配給當(dāng)前請求，否則，可以等待， 直到有處理單元完成當(dāng)前的處理，或者將其他進程分配給該當(dāng)前請求。
[0094] S207 :判斷該用戶的歷史請求對應(yīng)的歷史處理單元是否空閑，如果空閑，則進入步 驟S208 ;否則進入S209 ;
[0095] S208 :將該歷史處理單元分配給當(dāng)前請求；
[0096] S209:在該用戶的歷史請求所在的進程選擇一個空閑處理單元分配給當(dāng)前請求。
[0097] 步驟S207及S208為可選的步驟，也就是說，在實際應(yīng)用中，在步驟S206之后可以 直接進入步驟S209,將該用戶的歷史請求所在的進程中任意一個空閑處理單元分配給當(dāng)前 請求；但如果經(jīng)過該步驟S207,則可以將同一用戶的請求盡量分配到同一進程的同一處理 單元中，這樣，可以進一步保證資源的重復(fù)利用，提高處理效率。
[0098] 可見，通過上述處理，不僅能夠增加代理服務(wù)器的吞吐量，還可以盡可能保證同一 用戶在訪問中的連續(xù)性，從而進一步提高處理及響應(yīng)速度。當(dāng)然，在實際應(yīng)用中，有些窗口 可能在運行中會出現(xiàn)故障，此時，如果將用戶請求分配給該窗口，則會導(dǎo)致該請求無法得到 及時處理。因此，在本發(fā)明實施例中，可以對各個處理單元的狀態(tài)進行監(jiān)控，當(dāng)發(fā)現(xiàn)某處理 單元出現(xiàn)故障時，為了避免同一進程中其他處理單元的正常運行，可以首先將故障處理單 元所在的進程打上標記，避免有新的請求被分配到該進程，然后，等到該進程中所有的處理 單元正在處理的任務(wù)都完成之后，再將該進程關(guān)閉，然后再重新啟動該進程，并重新創(chuàng)建處 理單元。
[0099] 除此之外，為了進一步提高吞吐量及響應(yīng)速度，在代理服務(wù)器端還可以采用服務(wù) 器集群的方式，也就是說，可以在服務(wù)器端部署多個代理服務(wù)器，每個代理服務(wù)器中都具有 前述所有功能，例如，都可以預(yù)先啟動多個進程，每個進程中初始化多個處理單元，并且還 可以進行同一用戶的連續(xù)性訪問等處理。當(dāng)然，每臺代理服務(wù)器的硬件配置可以是不同的 [0100] 在采用服務(wù)器集群的情況下，還涉及到將用戶的當(dāng)前請求在不同的代理服務(wù)器之 間進行分配的問題，此時，還可以在服務(wù)器端部署一個專門用于分發(fā)的服務(wù)器，當(dāng)然也可以 在某一臺代理服務(wù)器上增加分發(fā)模塊。當(dāng)客戶端發(fā)送的用戶當(dāng)前請求到達服務(wù)器端時，可 以首先到達該分發(fā)服務(wù)器或分發(fā)模塊，然后由分發(fā)服務(wù)器或分發(fā)模塊為當(dāng)前請求分配代理 服務(wù)器。在分配代理服務(wù)器時，可以采用多種策略來實現(xiàn)，例如，可以預(yù)先獲取到各個代理 服務(wù)器的性能參數(shù)，根據(jù)代理服務(wù)器的性能參數(shù)確定出各自的處理能力，然后基于各自的 處理能力，為各個代理服務(wù)器進行請求的分配?；蛘撸€可以對各個代理服務(wù)器處理的請求 總數(shù)進行監(jiān)控，或者由各個代理服務(wù)器上報各自正在處理的請求總數(shù)，然后結(jié)合各自的處 理能力，進行更有效的分配。
[0101] 分發(fā)服務(wù)器或分發(fā)模塊在各個代理服務(wù)器之間進行分配時，可以采用類似DNS的 方式來實現(xiàn)，但是，在實際應(yīng)用中，代理服務(wù)器也可能出現(xiàn)故障，此時，為了避免對用戶請求 的處理速度產(chǎn)生影響，應(yīng)該能夠及時停止向該發(fā)生故障的代理服務(wù)器分配用戶請求。然而， 如果使用DNS的方式進行分發(fā)，則無法達到該要求，這是因為，傳統(tǒng)的DNS服務(wù)在單臺服務(wù) 器出現(xiàn)故障之后，并不會停止轉(zhuǎn)發(fā)新請求到故障的服務(wù)器上，而必須首先修改DNS配置，而 DNS服務(wù)器存在緩存，緩存的更新需要時間，所以修改DNS配置之后，轉(zhuǎn)發(fā)不會立即停止，需 要等到各級DNS緩存更新完畢之后，才能停止轉(zhuǎn)發(fā)新請求到故障的服務(wù)器上。為此，在本發(fā) 明實施例中，可以不使用DNS的方式進行分發(fā)，而是直接在分發(fā)服務(wù)器或者分發(fā)模塊中，對 各個代理服務(wù)器進行實時或準實時心跳監(jiān)測（可以配置監(jiān)控的時間間隔，單位在秒級別）， 所謂的心跳監(jiān)測也就是對代理服務(wù)器進行故障監(jiān)測，如果某代理服務(wù)器發(fā)生故障，則當(dāng)分 發(fā)服務(wù)器或分發(fā)模塊向其發(fā)送心跳測試信號時，將無法返回響應(yīng)，這樣，代理服務(wù)器上線下 線都能監(jiān)控到并處理。同時，還可以將能夠正常監(jiān)測到心跳信息的代理服務(wù)器加入到可用 代理服務(wù)器列表中，在向當(dāng)前請求分配代理服務(wù)器時，從該列表中選擇代理服務(wù)器，這樣就 可以保證有故障的代理服務(wù)器不會被選擇到。對于已經(jīng)處于可用代理服務(wù)器列表中的代理 服務(wù)器，當(dāng)又發(fā)現(xiàn)未能監(jiān)測到其心跳信息時，還可以將其從可用代理服務(wù)器列表中刪除，一 旦故障服務(wù)器恢復(fù)之后，分發(fā)服務(wù)器或分發(fā)模塊監(jiān)測到故障服務(wù)器的心跳信息了，則故障 服務(wù)器就會重新加入到可用代理服務(wù)器列表中，當(dāng)有用戶請求時，又可以重新分配到該代 理服務(wù)器中。
[0102] 在將某當(dāng)前請求分配到某代理服務(wù)器上之后，對于進程以及處理單元的分配可以 按照前文所述的來處理，這里不再贅述。可見，在這種服務(wù)器集群的方式下，可以實現(xiàn)兩個 層次的調(diào)度，一個是代理服務(wù)器之間的物理層，另一個是進程層，通過這種多級調(diào)度機制， 可以提高整體的處理能力以及響應(yīng)速度。
[0103] S103 :通過所述分配的處理單元，向所述當(dāng)前請求對應(yīng)的網(wǎng)頁服務(wù)器發(fā)送請求以 獲取網(wǎng)頁內(nèi)容，以便返回給客戶端進行展現(xiàn)。
[0104] 在給一個請求分配了處理單元之后，該處理單元就可以對請求進行解析，然后構(gòu) 造網(wǎng)頁訪問請求到網(wǎng)頁服務(wù)器，以獲取網(wǎng)頁資源，在獲取到網(wǎng)頁資源之后就可以進行解析、 渲染、排版等處理，之后轉(zhuǎn)換成二進制數(shù)據(jù)返回給客戶端，供客戶端進行繪制及網(wǎng)頁的顯 示。當(dāng)然，本發(fā)明不僅僅適用于上述處理單元執(zhí)行了解析、渲染、排版等處理的情況，在處理 單元所需執(zhí)行的操作發(fā)生變化時（例如代理服務(wù)器變得更重或者更輕），也可以使用本發(fā) 明實施例提供的方案來實現(xiàn)。
[0105] 需要說明的是，在一個處理單元完成了對一個請求的處理之后，該處理單元并不 會關(guān)閉，而是將處理該請求時申請的資源（包括與網(wǎng)頁服務(wù)器建立連接時的鏈接資源、用 于對各種資源進行緩存的存儲資源、計算資源等等）釋放掉，然后等待其他請求的到來，以 此周而復(fù)始。當(dāng)然，為了達到前述同一用戶的不同請求能夠復(fù)用一些資源的目的，處理單元 可以不必釋放頁面請求的結(jié)果。
[0106] 與本發(fā)明實施例提供的處理用戶訪問網(wǎng)頁的請求的方法相對應(yīng)，本發(fā)明實施例還 提供了一種處理用戶訪問網(wǎng)頁的請求系統(tǒng)，在該系統(tǒng)中，需要在代理服務(wù)器中預(yù)先啟動至 少兩個進程，每個進程中創(chuàng)建至少兩個處理單元，參見圖3,該系統(tǒng)包括：
[0107] 進程分配模塊301，用于在接收到多個用戶訪問網(wǎng)頁的當(dāng)前請求時，根據(jù)各個用戶 的屬性信息以及各個進程的狀態(tài)信息，為所述各個用戶的當(dāng)前請求分配進程；
[0108] 處理單元分配模塊302,用于在所述分配的進程中為所述當(dāng)前請求分配處理單 元；
[0109] 網(wǎng)頁內(nèi)容處理模塊303,用于通過所述分配的處理單元，向所述當(dāng)前請求對應(yīng)的網(wǎng) 頁服務(wù)器發(fā)送請求以獲取網(wǎng)頁內(nèi)容，以便返回給客戶端進行展現(xiàn)。
[0110] 為了保證用戶訪問的連續(xù)性，進一步提高響應(yīng)速度，可以將同一用戶的不同請求 分配給同一進程。
[0111] 具體實現(xiàn)時，為了實現(xiàn)上述將同一用戶的不同請求分配給同一進程，參見圖4,進 程分配模塊301可以包括：
[0112] 判斷子模塊3011，用于根據(jù)各個用戶的屬性信息判斷當(dāng)前請求是否為新用戶的請 求；
[0113] 進程分配子模塊3012,用于如果當(dāng)前請求不是新用戶的請求，則根據(jù)該用戶的分 配歷史以及各個進程的狀態(tài)信息為所述當(dāng)前請求分配進程。
[0114] 其中，判斷子模塊3011可以包括：
[0115] 用戶標識獲取子模塊，用于獲取所述當(dāng)前請求對應(yīng)的用戶的屬性信息；
[0116] 比對子模塊，用于如果當(dāng)前請求對應(yīng)的用戶的屬性信息標識未出現(xiàn)在所述歷史分 配記錄中，則所述當(dāng)前請求為新用戶的請求；其中，所述歷史分配記錄用于記錄在歷史處理 過程中，用戶請求對應(yīng)的用戶的屬性信息與分配給該用戶請求的進程之間的對應(yīng)關(guān)系。
[0117] 進程分配子模塊3012具體可以用于：
[0118] 所述當(dāng)前請求不是新用戶的請求，并且歷史分配記錄中該用戶的屬性信息對應(yīng)的 進程包含空閑的處理單元，則將該進程分配給當(dāng)前請求。
[0119] 為了能夠應(yīng)對一些網(wǎng)站中的特殊設(shè)計，歷史分配記錄中還可以記錄有用戶請求對 應(yīng)的用戶的屬性信息與分配給請求的處理單元之間的對應(yīng)關(guān)系；
[0120] 此時，處理單元分配模塊302具體可以用于：
[0121] 將歷史分配記錄中該用戶的屬性信息對應(yīng)的處理單元分配給當(dāng)前請求。
[0122] 另外，該系統(tǒng)還可以包括：
[0123] 新用戶請求分配模塊，用于如果當(dāng)前請求是新用戶的請求，則將當(dāng)前具有最多空 閑處理單元的進程分配給當(dāng)前請求。
[0124] 超時處理模塊，用于如果全部進程中都不存在空閑處理單元，則判斷是否存在處 理時間超時的處理單元，如果是，則將該處理單元所在的進程分配給當(dāng)前請求；
[0125] 相應(yīng)的，處理單元分配模塊302具體可以用于：
[0126] 將所述處理時間超時的處理單元的當(dāng)前任務(wù)結(jié)束，并將其分配給當(dāng)前請求。
[0127] 為了進一步提高服務(wù)器的吞吐量以及響應(yīng)速度，可以采用服務(wù)器集群的方式來實 現(xiàn)，也即，代理服務(wù)器為至少兩個，此時，參見圖5,該系統(tǒng)還可以包括：
[0128] 代理服務(wù)器分配模塊304,用于為當(dāng)前請求分配代理服務(wù)器。
[0129] 需要說明的是，圖5中示出的僅為各個模塊之間的邏輯關(guān)系，在物理結(jié)構(gòu)中，如前 文所述，該代理服務(wù)器分配模塊304可以部署于一個單獨的分發(fā)服務(wù)器中，也可以部署于 集群的任意一臺代理服務(wù)器中。
[0130] 為了能夠及時停止向發(fā)生故障的代理服務(wù)器分發(fā)新的請求，代理服務(wù)器分配模塊 304可以包括：
[0131] 心跳監(jiān)控子模塊，用于對各代理服務(wù)器進行實時的心跳監(jiān)控，將能夠正常監(jiān)測到 心跳信息的代理服務(wù)器加入到可用代理服務(wù)器列表中；
[0132] 代理服務(wù)器分配子模塊，用于從所述可用代理服務(wù)器列表中為當(dāng)前請求分配代理 服務(wù)器。
[0133] 另外，還可以包括：
[0134] 列表更新模塊，用于將未能監(jiān)測到心跳信息的代理服務(wù)器從所述可用代理服務(wù)器 列表中刪除；當(dāng)重新監(jiān)測到代理服務(wù)器的心跳信息時，將其加入到所述可用代理服務(wù)器列 表中。
[0135] 綜上所述，通過本發(fā)明實施例提供的上述系統(tǒng)，可以預(yù)先在同一臺代理服務(wù)器中 啟動多個進程并在每個進程中創(chuàng)建多個處理單元，這樣，就不必在用戶請求到達時再重新 進行進程及處理單元的創(chuàng)建，因此，可以縮短用戶實際感知到的處理時間，而且能夠滿足大 用戶量并發(fā)時的處理需求；同時，多進程的方式可以充分代理服務(wù)器中多核的資源，提高處 理效率，這也能提高服務(wù)器的響應(yīng)速度。
[0136] 通過以上的實施方式的描述可知，本領(lǐng)域的技術(shù)人員可以清楚地了解到本發(fā)明可 借助軟件加必需的通用硬件平臺的方式來實現(xiàn)?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì) 上或者說對現(xiàn)有技術(shù)做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品 可以存儲在存儲介質(zhì)中，如R0M/RAM、磁碟、光盤等，包括若干指令用以使得一臺計算機設(shè)備 (可以是個人計算機，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等）執(zhí)行本發(fā)明各個實施例或者實施例的某些 部分所述的方法。
[0137] 本說明書中的各個實施例均采用遞進的方式描述，各個實施例之間相同相似的部 分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于裝置或 系統(tǒng)實施例而言，由于其基本相似于方法實施例，所以描述得比較簡單，相關(guān)之處參見方法 實施例的部分說明即可。以上所描述的裝置及系統(tǒng)實施例僅僅是示意性的，其中所述作為 分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或 者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)單元上。可以根 據(jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。本領(lǐng)域普通技術(shù) 人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。
[0138] 以上對本發(fā)明所提供的處理用戶訪問網(wǎng)頁的請求的方法及系統(tǒng)，進行了詳細介 紹，本文中應(yīng)用了具體個例對本發(fā)明的原理及實施方式進行了闡述，以上實施例的說明只 是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā) 明的思想，在【具體實施方式】及應(yīng)用范圍上均會有改變之處。綜上所述，本說明書內(nèi)容不應(yīng)理 解為對本發(fā)明的限制。
【權(quán)利要求】
1. 一種處理用戶訪問網(wǎng)頁的請求方法，其特征在于，在同一臺代理服務(wù)器中預(yù)先啟動 至少兩個進程，每個進程中創(chuàng)建至少兩個處理單元，所述方法包括： 在接收到多個用戶訪問網(wǎng)頁的當(dāng)前請求時，根據(jù)各個用戶的屬性信息以及各個進程的 狀態(tài)信息，為各個用戶的當(dāng)前請求分配進程； 在所述分配的進程中為所述當(dāng)前請求分配處理單元； 通過所述分配的處理單元，向所述當(dāng)前請求對應(yīng)的網(wǎng)頁服務(wù)器發(fā)送請求以獲取網(wǎng)頁內(nèi) 容，以便返回給客戶端進行展現(xiàn)。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，將同一用戶的不同請求分配給同一進程。
3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述在接收到多個用戶訪問網(wǎng)頁的當(dāng)前 請求時，根據(jù)各個用戶的屬性信息以及各個進程的狀態(tài)信息，為各個用戶的當(dāng)前請求分配 進程，包括： 根據(jù)各個用戶的屬性信息判斷當(dāng)前請求是否為新用戶的請求； 如果當(dāng)前請求不是新用戶的請求，則根據(jù)該用戶的分配歷史以及各個進程的狀態(tài)信息 為所述當(dāng)前請求分配進程。
4. 根據(jù)權(quán)利要求3所述的方法，其特征在于，所述根據(jù)各個用戶的屬性信息判斷當(dāng)前 請求是否為新用戶的請求包括： 獲取所述當(dāng)前請求對應(yīng)的用戶的屬性信息； 如果當(dāng)前請求對應(yīng)的用戶的屬性信息未出現(xiàn)在所述歷史分配記錄中，則所述當(dāng)前請求 為新用戶的請求；其中，所述歷史分配記錄用于記錄在歷史處理過程中，用戶請求對應(yīng)的用 戶的屬性信息與分配給該用戶請求的進程之間的對應(yīng)關(guān)系。
5. 根據(jù)權(quán)利要求4所述的方法，其特征在于，所述如果當(dāng)前請求不是新用戶的請求，則 根據(jù)該用戶的分配歷史以及各個進程的狀態(tài)信息為所述當(dāng)前請求分配進程，包括： 如果所述當(dāng)前請求不是新用戶的請求，并且歷史分配記錄中該用戶的屬性信息對應(yīng)的 進程包含空閑的處理單元，則將該進程分配給當(dāng)前請求。
6. 根據(jù)權(quán)利要求4所述的方法，其特征在于，所述歷史分配記錄中還記錄有用戶請求 對應(yīng)的用戶的屬性信息與分配給請求的處理單元之間的對應(yīng)關(guān)系； 所述在分配的進程中為所述請求分配處理單元，包括： 將歷史分配記錄中該用戶的屬性信息對應(yīng)的處理單元分配給當(dāng)前請求。
7. 根據(jù)權(quán)利要求3所述的方法，其特征在于，還包括： 如果當(dāng)前請求是新用戶的請求，則將當(dāng)前具有最多空閑處理單元的進程分配給當(dāng)前請 求。
8. 根據(jù)權(quán)利要求7所述的方法，其特征在于，還包括： 如果全部進程中都不存在空閑處理單元，則判斷是否存在處理時間超時的處理單元， 如果是，則將該處理單元所在的進程分配給當(dāng)前請求； 所述在所述分配的進程中為所述當(dāng)前請求分配處理單元包括： 將所述處理時間超時的處理單元的當(dāng)前任務(wù)結(jié)束，并將其分配給當(dāng)前請求。
9. 根據(jù)權(quán)利要求1至8任一項所述的方法，其特征在于，所述代理服務(wù)器為至少兩個， 所述方法還包括： 為各個用戶的當(dāng)前請求分配代理服務(wù)器。
10. 根據(jù)權(quán)利要求9所述的方法，其特征在于，所述為各個用戶的當(dāng)前請求分配代理服 務(wù)器包括： 對各代理服務(wù)器進行實時的心跳監(jiān)控，將能夠正常監(jiān)測到心跳信息的代理服務(wù)器加入 到可用代理服務(wù)器列表中； 從所述可用代理服務(wù)器列表中為當(dāng)前請求分配代理服務(wù)器。
11. 根據(jù)權(quán)利要求10所述的方法，其特征在于，還包括： 將未能監(jiān)測到心跳信息的代理服務(wù)器從所述可用代理服務(wù)器列表中刪除；當(dāng)重新監(jiān)測 到代理服務(wù)器的心跳信息時，將其加入到所述可用代理服務(wù)器列表中。
12. -種處理用戶訪問網(wǎng)頁的請求系統(tǒng)，其特征在于，在同一臺代理服務(wù)器中預(yù)先啟動 至少兩個進程，每個進程中創(chuàng)建至少兩個處理單元，所述系統(tǒng)包括： 進程分配模塊，用于在接收到多個用戶訪問網(wǎng)頁的當(dāng)前請求時，根據(jù)各個用戶的屬性 信息以及各個進程的狀態(tài)信息，為所述各個用戶的當(dāng)前請求分配進程； 處理單元分配模塊，用于在所述分配的進程中為所述當(dāng)前請求分配處理單元； 網(wǎng)頁內(nèi)容處理模塊，用于通過所述分配的處理單元，向所述當(dāng)前請求對應(yīng)的網(wǎng)頁服務(wù) 器發(fā)送請求以獲取網(wǎng)頁內(nèi)容，以便返回給客戶端進行展現(xiàn)。
13. 根據(jù)權(quán)利要求12所述的系統(tǒng)，其特征在于，將同一用戶的不同請求分配給同一進 程。
14. 根據(jù)權(quán)利要求12所述的系統(tǒng)，其特征在于，所述進程分配模塊包括： 判斷子模塊，用于根據(jù)各個用戶的屬性信息判斷當(dāng)前請求是否為新用戶的請求； 進程分配子模塊，用于如果當(dāng)前請求不是新用戶的請求，則根據(jù)該用戶的分配歷史以 及各個進程的狀態(tài)信息為所述當(dāng)前請求分配進程。
15. 根據(jù)權(quán)利要求14所述的系統(tǒng)，其特征在于，所述判斷子模塊包括： 用戶標識獲取子模塊，用于獲取所述當(dāng)前請求對應(yīng)的用戶的屬性信息； 比對子模塊，用于如果當(dāng)前請求對應(yīng)的用戶的屬性信息未出現(xiàn)在所述歷史分配記錄 中，則所述當(dāng)前請求為新用戶的請求；其中，所述歷史分配記錄用于記錄在歷史處理過程 中，用戶請求對應(yīng)的用戶的屬性信息與分配給該用戶請求的進程之間的對應(yīng)關(guān)系。
16. 根據(jù)權(quán)利要求15所述的系統(tǒng)，其特征在于，所述進程分配子模塊具體用于： 如果所述當(dāng)前請求不是新用戶的請求，并且歷史分配記錄中該用戶的屬性信息對應(yīng)的 進程包含空閑的處理單元，則將該進程分配給當(dāng)前請求。
17. 根據(jù)權(quán)利要求15所述的系統(tǒng)，其特征在于，所述歷史分配記錄中還記錄有用戶請 求對應(yīng)的用戶的屬性信息與分配給請求的處理單元之間的對應(yīng)關(guān)系； 所述處理單元分配模塊具體用于： 將歷史分配記錄中該用戶的屬性信息對應(yīng)的處理單元分配給當(dāng)前請求。
18. 根據(jù)權(quán)利要求14所述的系統(tǒng)，其特征在于，還包括： 新用戶請求分配模塊，用于如果當(dāng)前請求是新用戶的請求，則將當(dāng)前具有最多空閑處 理單元的進程分配給當(dāng)前請求。
19. 根據(jù)權(quán)利要求18所述的系統(tǒng)，其特征在于，還包括： 超時處理模塊，用于如果全部進程中都不存在空閑處理單元，則判斷是否存在處理時 間超時的處理單元，如果是，則將該處理單元所在的進程分配給當(dāng)前請求； 所述處理單元分配模塊具體用于： 將所述處理時間超時的處理單元的當(dāng)前任務(wù)結(jié)束，并將其分配給當(dāng)前請求。
20. 根據(jù)權(quán)利要求12至19任一項所述的系統(tǒng)，其特征在于，所述代理服務(wù)器為至少兩 個，所述系統(tǒng)還包括： 代理服務(wù)器分配模塊，用于為各個用戶的當(dāng)前請求分配代理服務(wù)器。
21. 根據(jù)權(quán)利要求20所述的系統(tǒng)，其特征在于，所述代理服務(wù)器分配模塊包括： 心跳監(jiān)控子模塊，用于對各代理服務(wù)器進行實時的心跳監(jiān)控，將能夠正常監(jiān)測到心跳 信息的代理服務(wù)器加入到可用代理服務(wù)器列表中； 代理服務(wù)器分配子模塊，用于從所述可用代理服務(wù)器列表中為當(dāng)前請求分配代理服務(wù) 器。
22. 根據(jù)權(quán)利要求21所述的系統(tǒng)，其特征在于，還包括： 列表更新模塊，用于將未能監(jiān)測到心跳信息的代理服務(wù)器從所述可用代理服務(wù)器列表 中刪除；當(dāng)重新監(jiān)測到代理服務(wù)器的心跳信息時，將其加入到所述可用代理服務(wù)器列表中。
【文檔編號】G06F9/50GK104063461SQ201410294404
【公開日】2014年9月24日 申請日期:2012年5月2日 優(yōu)先權(quán)日:2012年5月2日
【發(fā)明者】劉華 申請人:北京奇虎科技有限公司, 奇智軟件（北京）有限公司