專利名稱:一種實現(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ù)有限公司