專利名稱：一種實現(xiàn)負(fù)載均衡持續(xù)性的方法和設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，特別涉及一種實現(xiàn)負(fù)載均衡持續(xù)性的方法和設(shè)備。
背景技術(shù)：
由于目前現(xiàn)有網(wǎng)絡(luò)的各個核心部分隨著業(yè)務(wù)量的提高，訪問量和數(shù)據(jù)流量的快速 增長，其處理能力和計算強度也相應(yīng)地增大，使得單一的服務(wù)器設(shè)備根本無法承擔(dān)。在此情 況下，如果扔掉現(xiàn)有設(shè)備去做大量的硬件升級，這樣將造成現(xiàn)有資源的浪費，而且如果再面 臨下一次業(yè)務(wù)量的提升時，這又將導(dǎo)致再一次硬件升級的高額成本投入，甚至性能再卓越 的設(shè)備也不能滿足當(dāng)前業(yè)務(wù)量增長的需求。為此，引入了負(fù)載均衡(Load Balance, LB)技 術(shù)解決這樣的問題。 在現(xiàn)有技術(shù)中，典型的負(fù)載均衡組網(wǎng)如圖1所示?？蛻舳藢⒄埱蟀l(fā)送給服務(wù)器群 前端的負(fù)載均衡設(shè)備，該請求的目的網(wǎng)絡(luò)互聯(lián)協(xié)議(Internet Protocol, IP)地址為虛服務(wù) 網(wǎng)絡(luò)互聯(lián)協(xié)議(Virtual Service IP， VSIP)地址，負(fù)載均衡設(shè)備上的虛服務(wù)接收客戶端請 求，通過調(diào)度算法，選擇一個真實服務(wù)器，將請求發(fā)送給選定的真實服務(wù)器，真實服務(wù)器的 響應(yīng)報文通過負(fù)載均衡設(shè)備再返回給客戶，完成整個負(fù)載均衡調(diào)度過程。 [OO(H] —次業(yè)務(wù)交互可能包括多個傳輸控制協(xié)議(Transmission Control Protocol, TCP)連接，如超文本傳輸協(xié)議(Hyper Text Transfer Protocol,HTTP)應(yīng)用。這些TCP連 接間有關(guān)聯(lián)關(guān)系，如HTTP網(wǎng)絡(luò)購物，多條連接組成一次業(yè)務(wù)應(yīng)用，但所有該業(yè)務(wù)的請求應(yīng) 發(fā)給同一服務(wù)器，否則可能造成無法完成所請求的功能。將多個連接持續(xù)重定向到同一個 真實服務(wù)器的策略，就是持續(xù)性功能。 HTTP協(xié)議是無狀態(tài)協(xié)議，無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力，但是很多 HTTP業(yè)務(wù)是需要事務(wù)處理的記憶性的，如電子商務(wù)等。HTTP Session (HTTP會話)機制就 是一種在客戶端與服務(wù)器之間保持狀態(tài)的解決方案，該機制是一種服務(wù)器端的機制，服務(wù) 器通常使用一種類似于散列表的結(jié)構(gòu)來保存信息。 當(dāng)服務(wù)器為某個客戶端的請求創(chuàng)建一個會話(Session)時，服務(wù)器首先檢查這個 客戶端的請求里是否已包含了會話標(biāo)識(Session ID)。 如果已包含一個Session ID，則說明以前已經(jīng)為此客戶端創(chuàng)建過Session,服務(wù) 器就按照Session ID把這個Session檢索出來使用；如果客戶端請求不包含Session ID， 則為此客戶端創(chuàng)建一個Session并且生成一個與此Session相關(guān)聯(lián)的Session ID，這個 Session ID將被在本次響應(yīng)中返回給客戶端保存。 保存這個Session ID的方式可以采用Cookie禾P URL (Uniform ResourceLocators，統(tǒng)一資源定位符)重寫方式，這樣后續(xù)交互過程中瀏覽器可以這個標(biāo) 識發(fā)回給服務(wù)器。 其中，URL重寫就是服務(wù)器把Session ID直接附加在URL路徑的后面，附加方式 有兩種，一種是作為URL路徑的附加信息，表現(xiàn)形式為
http://...../xxx ;sessio nid = abcd，

這兩種方式對于用戶來說是沒有區(qū)別的，只是服務(wù)器在解析時處理的方式不同。 其中，HTTP URL的基本格式如下 〃 http:" 〃 〃〃 host[" :〃 port] [abs—path[〃 ；〃 par塞][" 〃 query]] —條比較完整的HTTP URL例子如下 http://www. google, com :80/intl/index. htm ;aco皿t = torn sessionid = abed 其中，params稱為URL路徑的附加信息，query稱為查詢字符串。 在實現(xiàn)本發(fā)明的過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)中的Cookie和URL重寫方式分別存
在以下問題 1、Cookie功能可以被用戶禁用。這種情況下用戶瀏覽器不會把Cookie標(biāo)識發(fā)回 給服務(wù)器，從而負(fù)載均衡設(shè)備就無法通過Cookie持續(xù)性保證一次交互中的多次連接都能 發(fā)給同一個真實服務(wù)器。 2、實際中有大量使用URL重寫方法實現(xiàn)HTTP會話的處理的網(wǎng)絡(luò)服務(wù)器，這種情況 下負(fù)載均衡設(shè)備只能使用Cookie插入方式實現(xiàn)持續(xù)性，這種持續(xù)性方式需要在第一個響 應(yīng)報文插入Set-cookie信息，并且后續(xù)所有報文的TCP序列號等信息都需要修改，性能比 較差。這是因為Cookie方式通常在第一個響應(yīng)報文中插入Set-cookie信息，從而改變了 該響應(yīng)報文的內(nèi)容長度；從而影響后續(xù)所有報文的TCP序列號都是不正確的，負(fù)載均衡設(shè) 備需要對每個報文進(jìn)行修改。 本發(fā)明提供一種實現(xiàn)負(fù)載均衡持續(xù)性的方法和設(shè)備，使負(fù)載均衡設(shè)備通過對URL 鏈接進(jìn)行信息截取，結(jié)合持續(xù)性表項，實現(xiàn)負(fù)載均衡持續(xù)性的功能。 為達(dá)到上述目的，本發(fā)明一方面提供了一種實現(xiàn)負(fù)載均衡持續(xù)性的方法，應(yīng)用于 包括負(fù)載均衡設(shè)備、至少一個客戶端和至少一個服務(wù)器的系統(tǒng)中，所述負(fù)載均衡設(shè)備中維 護(hù)持續(xù)性表項，所述持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對應(yīng)關(guān)系，所述方法具體包括 以下步驟 當(dāng)所述負(fù)載均衡設(shè)備接收到客戶端發(fā)送的請求報文時，判斷所述請求報文中是否 攜帶與當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo)識； 如果判斷結(jié)果為是，所述負(fù)載均衡設(shè)備根據(jù)持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器 的對應(yīng)關(guān)系，將所述請求報文發(fā)送給與所述會話標(biāo)識相對應(yīng)的服務(wù)器。 優(yōu)選的，所述負(fù)載均衡設(shè)備中維護(hù)持續(xù)性表項，所述持續(xù)性表項中記錄會話標(biāo)識 與服務(wù)器的對應(yīng)關(guān)系，具體包括 所述負(fù)載均衡設(shè)備接收服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文，并判斷當(dāng)前是否 建立了與所述會話標(biāo)識相對應(yīng)的持續(xù)性表項； 如果有，則直接將所述響應(yīng)報文發(fā)送給相應(yīng)的客戶端，如果沒有，所述負(fù)載設(shè)備建
立所述會話標(biāo)識與發(fā)送所述響應(yīng)報文的服務(wù)器相對應(yīng)的持續(xù)性表項。 優(yōu)選的，所述請求報文或所述響應(yīng)報文中攜帶會話標(biāo)識的方式，具體包括
發(fā)明內(nèi)容
所述請求報文或所述響應(yīng)報文通過統(tǒng)一資源定位符URL鏈接的附加信息攜帶會 話標(biāo)識；或， 所述請求報文或所述響應(yīng)報文通過URL鏈接后所附加的查詢字符串?dāng)y帶會話標(biāo) 識。 優(yōu)選的，當(dāng)所述響應(yīng)報文中攜帶多個URL鏈接時，所述方法還包括 所述負(fù)載均衡設(shè)備解析所述響應(yīng)報文中所攜帶第一個URL鏈接，確定所述響應(yīng)報
文中所攜帶的會話標(biāo)識。 優(yōu)選的，當(dāng)所述負(fù)載均衡設(shè)備接收到客戶端發(fā)送的請求報文時，判斷所述請求報
文中是否攜帶與當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo)識之后，還包括 如果所述負(fù)載均衡設(shè)備判斷所述請求報文中沒有攜帶會話標(biāo)識，或所述負(fù)載均衡
設(shè)備判斷所述請求報文中所攜帶的會話標(biāo)識沒有對應(yīng)的持續(xù)性表項，所述負(fù)載均衡設(shè)備根
據(jù)預(yù)設(shè)的調(diào)度算法為所述請求報文選擇一個服務(wù)器； 所述負(fù)載均衡設(shè)備將所述請求報文發(fā)送給所述服務(wù)器。 另一方面，本發(fā)明還提供了一種負(fù)載均衡設(shè)備，應(yīng)用于包括負(fù)載均衡設(shè)備、至少一 個客戶端和至少一個服務(wù)器的系統(tǒng)中，具體包括 表項模塊，用于維護(hù)持續(xù)性表項，所述持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對 應(yīng)關(guān)系； 判斷模塊，與所述表項模塊相連接，用于當(dāng)接收到客戶端發(fā)送的請求報文時，判 斷所述請求報文中是否攜帶與所述表項模塊當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo) 識； 通信模塊，與所述判斷模塊和所述表項模塊相連接，用于接收客戶端發(fā)送的請求 報文，并在所述判斷模塊的判斷結(jié)果為是時，根據(jù)所述表項模塊所維護(hù)的持續(xù)性表項中記 錄會話標(biāo)識與服務(wù)器的對應(yīng)關(guān)系，將所述請求報文發(fā)送給與所述會話標(biāo)識相對應(yīng)的服務(wù) 器。
優(yōu)選的，所述通信模塊，還用于接收服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文；
當(dāng)所述通信模塊接收到服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文時，所述判斷模塊 判斷所述表項模塊中當(dāng)前是否建立了與所述通信模塊所接收到的會話標(biāo)識相對應(yīng)的持續(xù) 性表項，如果有，則所述通信模塊直接將所述響應(yīng)報文發(fā)送給相應(yīng)的客戶端，如果沒有，所 述表項模塊建立所述會話標(biāo)識與發(fā)送所述響應(yīng)報文的服務(wù)器相對應(yīng)的持續(xù)性表項。
優(yōu)選的，所述通信模塊，具體包括 解析子模塊，用于解析接收到的請求報文和/或響應(yīng)報文中所攜帶的會話標(biāo)識；
其中，所述請求報文或所述響應(yīng)報文中攜帶會話標(biāo)識的方式，具體包括
所述請求報文或所述響應(yīng)報文通過統(tǒng)一資源定位符URL鏈接的附加信息攜帶會 話標(biāo)識；或， 所述請求報文或所述響應(yīng)報文通過URL鏈接后所附加的查詢字符串?dāng)y帶會話標(biāo) 識。 優(yōu)選的，當(dāng)所述響應(yīng)報文中攜帶多個URL鏈接時， 所述解析子模塊，解析所述響應(yīng)報文中所攜帶第一個URL鏈接，確定所述響應(yīng)報 文中所攜帶的會話標(biāo)識。
優(yōu)選的，當(dāng)所述通信模塊接收到服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文時，所述 判斷模塊判斷所述表項模塊中當(dāng)前是否建立了與所述通信模塊所接收到的會話標(biāo)識相對 應(yīng)的持續(xù)性表項； 如果有，則所述通信模塊直接將所述響應(yīng)報文發(fā)送給相應(yīng)的客戶端，如果沒有，所
述表項模塊建立所述會話標(biāo)識與發(fā)送所述響應(yīng)報文的服務(wù)器相對應(yīng)的持續(xù)性表項。 優(yōu)選的，所述判斷模塊判斷所述請求報文中是否攜帶與當(dāng)前已經(jīng)建立的持續(xù)性表
項相對應(yīng)的會話標(biāo)識之后，如果所述判斷模塊判斷所述請求報文中沒有攜帶會話標(biāo)識，或
所述判斷模塊判斷所述請求報文中所攜帶的會話標(biāo)識沒有對應(yīng)的持續(xù)性表項，所述設(shè)備還
包括 選擇模塊，用于根據(jù)預(yù)設(shè)的調(diào)度算法為所述請求報文選擇一個服務(wù)器，由所述通 信模塊將所述請求報文發(fā)送給所述選擇模塊所選擇的服務(wù)器。
與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點 通過應(yīng)用本發(fā)明的技術(shù)方案，為負(fù)載均衡設(shè)備提出一種基于URL信息截取的持續(xù) 性方法，適用于真實服務(wù)器使用URL重寫實現(xiàn)HTTP會話保持的應(yīng)用場景，可以提高負(fù)載均 衡設(shè)備的處理性能，并且不受客戶端是否開啟Cookie功能的影響。


圖1為現(xiàn)有技術(shù)中的負(fù)載均衡組網(wǎng)的網(wǎng)絡(luò)結(jié)構(gòu)示意圖； 圖2為本發(fā)明所提出的一種實現(xiàn)負(fù)載均衡持續(xù)性的方法的流程示意圖； 圖3為本發(fā)明所提出的一種具體應(yīng)用場景下實現(xiàn)負(fù)載均衡持續(xù)性的方法的流程
示意圖； 圖4為本發(fā)明所提出的一種負(fù)載均衡設(shè)備的結(jié)構(gòu)示意圖。
具體實施例方式
針對現(xiàn)有技術(shù)中的缺陷，在服務(wù)器使用URL重寫方式實現(xiàn)HTTP會話的場景中，如 果負(fù)載均衡設(shè)備此時使用URL信息截取，并建立相應(yīng)的持續(xù)性表項記錄截取信息和服務(wù)器 的對應(yīng)關(guān)系，那么，便可以實現(xiàn)負(fù)載均衡的持續(xù)性功能。 這樣的處理思路并不依賴客戶端是否使能Cookie功能，無論客戶端是否使能 Cookie功能，都可以使客戶端一次交互中的多條鏈接發(fā)送到同一個真實服務(wù)器。
并且，在這種情況下，使用URL信息截取實現(xiàn)負(fù)載均衡持續(xù)性的思路不需要修改 任何報文，性能優(yōu)于Cookie持續(xù)性。 如圖2所示，為本發(fā)明所提出的一種實現(xiàn)負(fù)載均衡持續(xù)性的方法的流程示意圖， 該方法應(yīng)用于包括負(fù)載均衡設(shè)備、至少一個客戶端和至少一個服務(wù)器的系統(tǒng)中，該方法具 體包括以下步驟 步驟S201、負(fù)載均衡設(shè)備中維護(hù)持續(xù)性表項，持續(xù)性表項中記錄會話標(biāo)識與服務(wù) 器的對應(yīng)關(guān)系，具體包括 負(fù)載均衡設(shè)備接收服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文，并判斷當(dāng)前是否建立 了與會話標(biāo)識相對應(yīng)的持續(xù)性表項； 如果有，則直接將響應(yīng)報文發(fā)送給相應(yīng)的客戶端，如果沒有，負(fù)載設(shè)備建立會話標(biāo)識與發(fā)送響應(yīng)報文的服務(wù)器相對應(yīng)的持續(xù)性表項。 步驟S202、當(dāng)負(fù)載均衡設(shè)備接收到客戶端發(fā)送的請求報文時，判斷請求報文中是
否攜帶與當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo)識。
如果判斷結(jié)果為是，執(zhí)行步驟S203 ;
如果判斷結(jié)果為否，執(zhí)行步驟S204。 其中，請求報文或響應(yīng)報文中攜帶會話標(biāo)識的方式，具體包括 請求報文或響應(yīng)報文通過統(tǒng)一資源定位符URL鏈接的附加信息攜帶會話標(biāo)識；
或， 請求報文或響應(yīng)報文通過URL鏈接后所附加的查詢字符串?dāng)y帶會話標(biāo)識。 在具體的應(yīng)用場景中，上述的請求報文或響應(yīng)報文中攜帶會話標(biāo)識的具體方式需
要提前進(jìn)行設(shè)定，具體攜帶方式的變化并不會影響本發(fā)明的保護(hù)范圍。 進(jìn)一步的，當(dāng)響應(yīng)報文中攜帶多個URL鏈接時，方法還包括 負(fù)載均衡設(shè)備解析響應(yīng)報文中所攜帶第一個URL鏈接，確定響應(yīng)報文中所攜帶的 會話標(biāo)識。 步驟S203、負(fù)載均衡設(shè)備根據(jù)持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對應(yīng)關(guān)系， 將請求報文發(fā)送給與會話標(biāo)識相對應(yīng)的服務(wù)器。 步驟S204、負(fù)載均衡設(shè)備根據(jù)預(yù)設(shè)的調(diào)度算法為請求報文選擇一個服務(wù)器。
觸發(fā)執(zhí)行本步驟的場景具體包括以下兩種情況
負(fù)載均衡設(shè)備判斷請求報文中沒有攜帶會話標(biāo)識；或， 負(fù)載均衡設(shè)備判斷請求報文中所攜帶的會話標(biāo)識沒有對應(yīng)的持續(xù)性表項。
步驟S205、負(fù)載均衡設(shè)備將請求報文發(fā)送給選擇出的服務(wù)器。
與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點 通過應(yīng)用本發(fā)明的技術(shù)方案，為負(fù)載均衡設(shè)備提出一種基于URL信息截取的持續(xù) 性方法，適用于真實服務(wù)器使用URL重寫實現(xiàn)HTTP會話保持的應(yīng)用場景，可以提高負(fù)載均 衡設(shè)備的處理性能，并且不受客戶端是否開啟Cookie功能的影響。 為了進(jìn)一步闡述本發(fā)明的技術(shù)思想，現(xiàn)結(jié)合具體的應(yīng)用場景，對本發(fā)明的技術(shù)方 案進(jìn)行說明。 由前述說明可知，會話標(biāo)識可以以查詢字符串或URL鏈接的附加信息的方式攜帶 于請求報文或響應(yīng)報文中，下面以負(fù)載均衡設(shè)備截取查詢字符串的場景為例，來說明負(fù)載 均衡設(shè)備的處理過程。 這種方法要求用戶在負(fù)載均衡設(shè)備配置截取信息的標(biāo)識域名(例如Session
ID)。處理過程如圖3所示，包括以下步驟 步驟S301、客戶端和負(fù)載均衡設(shè)備建立TCP連接。 步驟S302 、客戶端發(fā)送HTTP請求報文，請求主頁。 步驟S303、負(fù)載均衡設(shè)備根據(jù)調(diào)度算法為客戶端選擇選擇真實服務(wù)器Serverl。
步驟S304、負(fù)載均衡設(shè)備和Serverl建立連接，并向Serverl轉(zhuǎn)發(fā)客戶端所發(fā)送的 HTTP請求報文。 步驟S305、 Serverl回應(yīng)HTTP響應(yīng)報文。 該報文內(nèi)容中攜帶主頁所有鏈接所對應(yīng)的URL鏈接信息，例如
8
/index, htm 7 sessionid = abed 其中，"sessionid = abed"表明本次會話所對應(yīng)的Session ID為abcd。
通過上述流程描述可以看出，本發(fā)明技術(shù)方案中需要服務(wù)器使用URL重寫方式實 現(xiàn)HTTP會話，因此，負(fù)載均衡設(shè)備從真實服務(wù)器(在本實施例中為Server 1)收到的HTTP 響應(yīng)報文中攜帶的所有URL鏈接的形式均如下所示
http://x. x. x. x/xxx * sessionid = abcd。 在實際的應(yīng)用場景中，可以根據(jù)實際的網(wǎng)絡(luò)地址和系統(tǒng)需要，按照上述格式，構(gòu)造 相應(yīng)的URL鏈接。 步驟S306、負(fù)載均衡設(shè)備解析HTTP響應(yīng)報文的內(nèi)容中所攜帶的URL鏈接信息，得
到Session ID對應(yīng)的值為abcd，并生成abed和Server 1對應(yīng)的持續(xù)性表項。 負(fù)載均衡設(shè)備解析一個業(yè)務(wù)會話中第一個響應(yīng)報文中的URL鏈接，得到其中的
sessionid字段對應(yīng)的值abcd，并生成持續(xù)性表項，持續(xù)性表項的格式可以為 abcd〈-一〉serverl，以此來表示會話標(biāo)識與相應(yīng)服務(wù)器的對應(yīng)關(guān)系。 在具體的應(yīng)用場景中，如果負(fù)載均衡設(shè)備接收到的響應(yīng)報文中攜帶了多個URL鏈
接，由于所有URL攜帶的會話標(biāo)識是相同的，因此，負(fù)載均衡設(shè)備只需要解析該響應(yīng)報文中
的第一個URL鏈接即可。 步驟S307、負(fù)載均衡設(shè)備向客戶端轉(zhuǎn)發(fā)HTTP響應(yīng)報文。 步驟S308、客戶端點擊主頁中的鏈接，以新的連接發(fā)起對新鏈接的HTTP請求，URL 為/index, htm 7 sessionid = abcd。 其中上述的/index, htm 是本發(fā)明中給出的具體實例，在實際應(yīng)用場景中，客戶 端后續(xù)點擊已經(jīng)建立了持續(xù)性表項的業(yè)務(wù)服務(wù)的其他頁面時，請求報文中的URL鏈接的格 式如下 htt。//x. x. x. x/xxx 7 sessionid = abcd， 其中的x. x. x. X/XXX ，可以根據(jù)實際的網(wǎng)絡(luò)地址和系統(tǒng)需要進(jìn)行替換。 步驟S309、負(fù)載均衡設(shè)備解析新請求中URL的查詢字符串信息，得到sessionid的
值abcd，通過查詢持續(xù)性表項，得到該請求所對應(yīng)的真實服務(wù)器為Serverl。 在本步驟的處理中，負(fù)載均衡設(shè)備只需要在URL鏈接中解析出sessionid對應(yīng)的
值為abcd，然后用abcd來匹配持續(xù)性表項，找到真實服務(wù)器為Serverl ，直接把該請求報文
發(fā)給Serverl，由其進(jìn)行后續(xù)業(yè)務(wù)的處理。 步驟S310、負(fù)載均衡設(shè)備向Serverl發(fā)送本次請求，由服務(wù)器執(zhí)行相應(yīng)的業(yè)務(wù)處理。 通過上面的處理過程，客戶端在本次業(yè)務(wù)交互過程中的多次連接都被發(fā)送給 Serverl ，保證了業(yè)務(wù)的順利進(jìn)行，和負(fù)載均衡的持續(xù)性實現(xiàn)。 需要進(jìn)一步指出的是，上述的流程說明是在以負(fù)載均衡設(shè)備截取查詢字符串的場 景為例進(jìn)行說明的，如果是負(fù)載均衡設(shè)備截取URL鏈接的附加信息，那么，相應(yīng)的處理過程 與前述場景類似，在此不再重復(fù)敘述。
與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點 通過應(yīng)用本發(fā)明的技術(shù)方案，為負(fù)載均衡設(shè)備提出一種基于URL信息截取的持續(xù) 性方法，適用于真實服務(wù)器使用URL重寫實現(xiàn)HTTP會話保持的應(yīng)用場景，可以提高負(fù)載均
9衡設(shè)備的處理性能，并且不受客戶端是否開啟Cookie功能的影響。 為了實現(xiàn)本發(fā)明的技術(shù)方案，本發(fā)明還提出了一種負(fù)載均衡設(shè)備，應(yīng)用于包括負(fù) 載均衡設(shè)備、至少一個客戶端和至少一個服務(wù)器的系統(tǒng)中。 如圖4所示，為本發(fā)明提出的一種負(fù)載均衡設(shè)備的結(jié)構(gòu)示意圖，該負(fù)載均衡設(shè)備 具體包括 表項模塊41，用于維護(hù)持續(xù)性表項，持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對應(yīng) 關(guān)系。 判斷模塊42，與表項模塊41相連接，用于當(dāng)接收到客戶端發(fā)送的請求報文時，判
斷請求報文中是否攜帶與表項模塊41當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo)識。 通信模塊43，與判斷模塊42和表項模塊41相連接，用于接收客戶端發(fā)送的請求報
文，并在判斷模塊42的判斷結(jié)果為是時，根據(jù)表項模塊41所維護(hù)的持續(xù)性表項中記錄會話
標(biāo)識與服務(wù)器的對應(yīng)關(guān)系，將請求報文發(fā)送給與會話標(biāo)識相對應(yīng)的服務(wù)器。 在具體的應(yīng)用場景中，通信模塊43還用于接收服務(wù)器發(fā)送的攜帶會話標(biāo)識的響
應(yīng)報文； 當(dāng)通信模塊43接收到服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文時，判斷模塊42判 斷表項模塊41中當(dāng)前是否建立了與通信模塊43所接收到的會話標(biāo)識相對應(yīng)的持續(xù)性表 項； 如果有，則通信模塊43直接將響應(yīng)報文發(fā)送給相應(yīng)的客戶端，如果沒有，表項模 塊41建立會話標(biāo)識與發(fā)送響應(yīng)報文的服務(wù)器相對應(yīng)的持續(xù)性表項。
為了實現(xiàn)上述的技術(shù)方案，相應(yīng)的通信模塊43具體包括 解析子模塊431，用于解析接收到的請求報文和/或響應(yīng)報文中所攜帶的會話標(biāo) 識； 其中，請求報文或響應(yīng)報文中攜帶會話標(biāo)識的方式，具體包括 請求報文或響應(yīng)報文通過統(tǒng)一資源定位符URL鏈接的附加信息攜帶會話標(biāo)識；
或， 請求報文或響應(yīng)報文通過URL鏈接后所附加的查詢字符串?dāng)y帶會話標(biāo)識。
另一方面，當(dāng)響應(yīng)報文中攜帶多個URL鏈接時， 解析子模塊431，解析響應(yīng)報文中所攜帶第一個URL鏈接，確定響應(yīng)報文中所攜帶 的會話標(biāo)識。 需要進(jìn)一步指出的是，判斷模塊42判斷請求報文中是否攜帶與當(dāng)前已經(jīng)建立的 持續(xù)性表項相對應(yīng)的會話標(biāo)識之后，如果判斷模塊42判斷請求報文中沒有攜帶會話標(biāo)識， 或判斷模塊42判斷請求報文中所攜帶的會話標(biāo)識沒有對應(yīng)的持續(xù)性表項，該負(fù)載均衡設(shè) 備還包括 選擇模塊44，用于根據(jù)預(yù)設(shè)的調(diào)度算法為請求報文選擇一個服務(wù)器，由通信模塊 43將請求報文發(fā)送給選擇模塊所選擇的服務(wù)器。
與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點 通過應(yīng)用本發(fā)明的技術(shù)方案，為負(fù)載均衡設(shè)備提出一種基于URL信息截取的持續(xù) 性方法，適用于真實服務(wù)器使用URL重寫實現(xiàn)HTTP會話保持的應(yīng)用場景，可以提高負(fù)載均 衡設(shè)備的處理性能，并且不受客戶端是否開啟Cookie功能的影響。
通過以上的實施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到本發(fā)明可以通
過硬件實現(xiàn)，也可以借助軟件加必要的通用硬件平臺的方式來實現(xiàn)。基于這樣的理解，本發(fā)
明的技術(shù)方案可以以軟件產(chǎn)品的形式體現(xiàn)出來，該軟件產(chǎn)品可以存儲在一個非易失性存儲
介質(zhì)(可以是CD-R0M， U盤，移動硬盤等)中，包括若干指令用以使得一臺計算機設(shè)備(可
以是個人計算機，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施場景所述的方法。 本領(lǐng)域技術(shù)人員可以理解附圖只是一個優(yōu)選實施場景的示意圖，附圖中的模塊或
流程并不一定是實施本發(fā)明所必須的。 本領(lǐng)域技術(shù)人員可以理解實施場景中的裝置中的模塊可以按照實施場景描述進(jìn) 行分布于實施場景的裝置中，也可以進(jìn)行相應(yīng)變化位于不同于本實施場景的一個或多個裝 置中。上述實施場景的模塊可以合并為一個模塊，也可以進(jìn)一步拆分成多個子模塊。
上述本發(fā)明序號僅僅為了描述，不代表實施場景的優(yōu)劣。 以上公開的僅為本發(fā)明的幾個具體實施場景，但是，本發(fā)明并非局限于此，任何本 領(lǐng)域的技術(shù)人員能思之的變化都應(yīng)落入本發(fā)明的保護(hù)范圍。
權(quán)利要求
一種實現(xiàn)負(fù)載均衡持續(xù)性的方法，應(yīng)用于包括負(fù)載均衡設(shè)備、至少一個客戶端和至少一個服務(wù)器的系統(tǒng)中，其特征在于，所述負(fù)載均衡設(shè)備中維護(hù)持續(xù)性表項，所述持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對應(yīng)關(guān)系，所述方法具體包括以下步驟當(dāng)所述負(fù)載均衡設(shè)備接收到客戶端發(fā)送的請求報文時，判斷所述請求報文中是否攜帶與當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo)識；如果判斷結(jié)果為是，所述負(fù)載均衡設(shè)備根據(jù)持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對應(yīng)關(guān)系，將所述請求報文發(fā)送給與所述會話標(biāo)識相對應(yīng)的服務(wù)器。
2. 如權(quán)利要求1所述的方法，其特征在于，所述負(fù)載均衡設(shè)備中維護(hù)持續(xù)性表項，所述持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對應(yīng)關(guān)系，具體包括所述負(fù)載均衡設(shè)備接收服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文，并判斷當(dāng)前是否建立了與所述會話標(biāo)識相對應(yīng)的持續(xù)性表項；如果有，則直接將所述響應(yīng)報文發(fā)送給相應(yīng)的客戶端，如果沒有，所述負(fù)載設(shè)備建立所述會話標(biāo)識與發(fā)送所述響應(yīng)報文的服務(wù)器相對應(yīng)的持續(xù)性表項。
3. 如權(quán)利要求1或2所述的方法，其特征在于，所述請求報文或所述響應(yīng)報文中攜帶會話標(biāo)識的方式，具體包括所述請求報文或所述響應(yīng)報文通過統(tǒng)一資源定位符URL鏈接的附加信息攜帶會話標(biāo)識；或，所述請求報文或所述響應(yīng)報文通過URL鏈接后所附加的查詢字符串?dāng)y帶會話標(biāo)識。
4. 如權(quán)利要求3所述的方法，其特征在于，當(dāng)所述響應(yīng)報文中攜帶多個URL鏈接時，所述方法還包括所述負(fù)載均衡設(shè)備解析所述響應(yīng)報文中所攜帶第一個URL鏈接，確定所述響應(yīng)報文中所攜帶的會話標(biāo)識。
5. 如權(quán)利要求1所述的方法，其特征在于，當(dāng)所述負(fù)載均衡設(shè)備接收到客戶端發(fā)送的請求報文時，判斷所述請求報文中是否攜帶與當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo)識之后，還包括如果所述負(fù)載均衡設(shè)備判斷所述請求報文中沒有攜帶會話標(biāo)識，或所述負(fù)載均衡設(shè)備判斷所述請求報文中所攜帶的會話標(biāo)識沒有對應(yīng)的持續(xù)性表項，所述負(fù)載均衡設(shè)備根據(jù)預(yù)設(shè)的調(diào)度算法為所述請求報文選擇一個服務(wù)器；所述負(fù)載均衡設(shè)備將所述請求報文發(fā)送給所述服務(wù)器。
6. —種負(fù)載均衡設(shè)備，應(yīng)用于包括負(fù)載均衡設(shè)備、至少一個客戶端和至少一個服務(wù)器的系統(tǒng)中，其特征在于，具體包括表項模塊，用于維護(hù)持續(xù)性表項，所述持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對應(yīng)關(guān)系；判斷模塊，與所述表項模塊相連接，用于當(dāng)接收到客戶端發(fā)送的請求報文時，判斷所述請求報文中是否攜帶與所述表項模塊當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo)識；通信模塊，與所述判斷模塊和所述表項模塊相連接，用于接收客戶端發(fā)送的請求報文，并在所述判斷模塊的判斷結(jié)果為是時，根據(jù)所述表項模塊所維護(hù)的持續(xù)性表項中記錄會話標(biāo)識與服務(wù)器的對應(yīng)關(guān)系，將所述請求報文發(fā)送給與所述會話標(biāo)識相對應(yīng)的服務(wù)器。
7. 如權(quán)利要求6所述的設(shè)備，其特征在于，所述通信模塊，還用于接收服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文； 當(dāng)所述通信模塊接收到服務(wù)器發(fā)送的攜帶會話標(biāo)識的響應(yīng)報文時，所述判斷模塊判斷 所述表項模塊中當(dāng)前是否建立了與所述通信模塊所接收到的會話標(biāo)識相對應(yīng)的持續(xù)性表 項，如果有，則所述通信模塊直接將所述響應(yīng)報文發(fā)送給相應(yīng)的客戶端，如果沒有，所述表 項模塊建立所述會話標(biāo)識與發(fā)送所述響應(yīng)報文的服務(wù)器相對應(yīng)的持續(xù)性表項。
8. 如權(quán)利要求6或7所述的設(shè)備，其特征在于，所述通信模塊，具體包括 解析子模塊，用于解析接收到的請求報文和/或響應(yīng)報文中所攜帶的會話標(biāo)識； 其中，所述請求報文或所述響應(yīng)報文中攜帶會話標(biāo)識的方式，具體包括 所述請求報文或所述響應(yīng)報文通過統(tǒng)一資源定位符URL鏈接的附加信息攜帶會話標(biāo)識；或，所述請求報文或所述響應(yīng)報文通過URL鏈接后所附加的查詢字符串?dāng)y帶會話標(biāo)識。
9. 如權(quán)利要求8所述的設(shè)備，其特征在于，當(dāng)所述響應(yīng)報文中攜帶多個URL鏈接時， 所述解析子模塊，解析所述響應(yīng)報文中所攜帶第一個URL鏈接，確定所述響應(yīng)報文中所攜帶的會話標(biāo)識。
10. 如權(quán)利要求6所述的設(shè)備，其特征在于，所述判斷模塊判斷所述請求報文中是否攜 帶與當(dāng)前已經(jīng)建立的持續(xù)性表項相對應(yīng)的會話標(biāo)識之后，如果所述判斷模塊判斷所述請求 報文中沒有攜帶會話標(biāo)識，或所述判斷模塊判斷所述請求報文中所攜帶的會話標(biāo)識沒有對 應(yīng)的持續(xù)性表項，所述設(shè)備還包括選擇模塊，用于根據(jù)預(yù)設(shè)的調(diào)度算法為所述請求報文選擇一個服務(wù)器，由所述通信模 塊將所述請求報文發(fā)送給所述選擇模塊所選擇的服務(wù)器。
全文摘要
本發(fā)明公開了一種實現(xiàn)負(fù)載均衡持續(xù)性的方法和設(shè)備，負(fù)載均衡設(shè)備解析報文內(nèi)容中的URL鏈接信息生成持續(xù)性表項，通過該持續(xù)性表項實現(xiàn)負(fù)載均衡的持續(xù)性，通過應(yīng)用本發(fā)明的技術(shù)方案，為負(fù)載均衡設(shè)備提出一種基于URL信息截取的持續(xù)性方法，適用于真實服務(wù)器使用URL重寫實現(xiàn)HTTP會話保持的應(yīng)用場景，可以提高負(fù)載均衡設(shè)備的處理性能，并且不受客戶端是否開啟Cookie功能的影響。
文檔編號H04L29/06GK101783771SQ201010131388
公開日2010年7月21日 申請日期2010年3月24日 優(yōu)先權(quán)日2010年3月24日
發(fā)明者于洪強, 張峻, 蔡志峰 申請人:杭州華三通信技術(shù)有限公司