專利名稱：用于會話復制和故障切換的方法和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明通常涉及數(shù)據(jù)復制，特別涉及為客戶端網(wǎng)絡會話提供備援(redundancy)。
背景技術(shù)：
當客戶端連接到網(wǎng)絡上的服務器并且開始會話時，可能存在針對于這個客戶端會話的存儲在服務器上的信息。例如，客戶端的用戶可以將項目放置在虛擬的購物車中。那些項目的選擇可以被至少臨時地保存在服務器上。在這個示例中，對于其它用戶和服務器沒有必要訪問這一信息。然而，可以期望該數(shù)據(jù)通過網(wǎng)絡和服務器集群高度可用，從而如果存儲會話數(shù)據(jù)的服務器故障，則可以在其它的服務器上恢復該數(shù)據(jù)。
在上述情況下實現(xiàn)數(shù)據(jù)恢復的一種方法是在會話期間將信息保存在數(shù)據(jù)庫中，盡管所述信息也可以通過其它方法來存儲，例如存儲在數(shù)據(jù)文件中。每次會話數(shù)據(jù)變化時，將更新寫入數(shù)據(jù)庫，從而該數(shù)據(jù)對于每個具有訪問數(shù)據(jù)庫的服務器是可達到的。數(shù)據(jù)被保存在持久的空間，并且可以被其它服務器容易地恢復。
然而，使用上述方法存在一個問題，即對于每個請求將會話信息從數(shù)據(jù)庫中取出是非常昂貴的。對數(shù)據(jù)庫的多次請求可能產(chǎn)生瓶頸并且使系統(tǒng)陷入基本上不能操作的地步，因為系統(tǒng)的運算能力取決于來自服務器的連接數(shù)據(jù)庫的數(shù)量。而且，這些會話可以包括用戶想要快速訪問的信息類型。通過一些應用，成千上萬的用戶可能會同時工作，產(chǎn)生成千上萬的并行會話。一些服務器被要求提供許多不同的應用程序，這就進一步增加了需要提供的會話的數(shù)量。
期望提高這種系統(tǒng)的速度和效率，從而成千上萬的用戶能夠有效地使用該系統(tǒng)。避免這種瓶頸的一種方法就是假設服務器使用99.9％的時間工作和運行并且完全忽略備份任何信息。這可以是提供最快用戶經(jīng)驗的解決方法，但是即使是0.1％的停工時間也會導致數(shù)據(jù)損失，這對于許多用戶來說是不能接受的。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的系統(tǒng)可以利用主服務器來服務來自諸如網(wǎng)頁瀏覽器的網(wǎng)絡客戶端的請求。該主服務器可以從服務器或服務器集群庫中來選擇。一旦選擇了主服務器，則可以在該主服務器上服務客戶端的請求。一旦主服務器響應所述請求，則有關(guān)會話的信息從主服務器發(fā)送到副會話服務器。這可以是第一次請求會話的全套信息，也可以僅僅是響應后來的請求的，對在會話中的已有信息的更新。識別主和副服務器的信息可以被保存在客戶端，例如以類似事務處理或安全上下文的方式將一個“標記”保存為cookie或傳遞到標準RMI的頂部。該標識信息或“標記”可以伴隨每個請求。
系統(tǒng)可以充分利用使用硬件或軟件的負載均衡的優(yōu)點。在軟件負載均衡可用的處理中，可以在已經(jīng)選擇了主和副會話的會話中接收請求。做出一種在主服務器上服務該請求的嘗試。如果主服務器不能接收或響應請求，則可以在副應用服務器上服務該請求。如果副服務器接收該請求，則副服務器變成新的主服務器?？梢赃x擇一個新的副服務器，并且為了維持備援而從新的主服務器發(fā)送會話信息。
在硬件負載均衡器可用的處理中，在已經(jīng)選擇的主和副會話服務器的會話中接收一個請求。隨后試圖在主服務器上服務該請求。如果主服務器不能接收或響應該請求，則硬件負載均衡器可以選擇一個新的主服務器，并且試圖在新的主服務器上服務該請求，而不是使用副會話服務器。會話信息可以從副會話服務器發(fā)送到新的主服務器，例如響應于來自新的主服務器的一個請求。隨后新的主服務器可以響應該請求，并且將更新的會話信息發(fā)送到副服務器，從而服務器與那個會話同步。


圖1是根據(jù)本發(fā)明一個實施例的應用服務器系統(tǒng)的圖；圖2是根據(jù)本發(fā)明一個實施例的多級結(jié)構(gòu)的圖；圖3是根據(jù)本發(fā)明一個實施例的小服務程序引擎系統(tǒng)的圖；圖4是根據(jù)本發(fā)明一個實施例的負載均衡器系統(tǒng)的圖；圖5是根據(jù)本發(fā)明一個實施例的Java系統(tǒng)的圖；圖6是根據(jù)本發(fā)明一個實施例的處理流程圖；圖7是根據(jù)本發(fā)明一個實施例的軟件負載均衡器處理的流程圖；圖8是根據(jù)本發(fā)明一個實施例的硬件負載均衡器處理的流程圖。
具體實施例方式
本發(fā)明克服了現(xiàn)有復制系統(tǒng)的許多缺陷。在根據(jù)本發(fā)明一個實施例的一個系統(tǒng)中，當客戶端在諸如局域網(wǎng)(LAN)、以太網(wǎng)或因特網(wǎng)的網(wǎng)絡上向服務器提出一個請求時，就會創(chuàng)建一個會話。接收請求的會話服務器可以包括用來存儲會話信息和/或產(chǎn)生對會話請求的響應的任何服務器，例如應用服務器、網(wǎng)頁服務器、對象服務器、或者小服務程序引擎。最終接收請求的服務器成為“主”服務器，或者客戶端會把將來的請求發(fā)送到的服務器成為“主”服務器。隨后該系統(tǒng)可以為那個會話選擇一個“副”服務器，該副服務器充當備援的源。
每次在那個會話中進行更新時，更改不僅應該被存儲在主服務器中，還可以用諸如遠程調(diào)用來發(fā)送到副服務器。每次發(fā)生變化時，不用將整套會話數(shù)據(jù)轉(zhuǎn)送到副服務器，而只需要發(fā)送發(fā)生變化的數(shù)據(jù)或信息，例如以信息的增量或信息的分租的形式來發(fā)送。在增量中發(fā)送所需信息的最少量可以提高整個系統(tǒng)的效率。復制就像一個鏡像系統(tǒng)，除了它對會話數(shù)據(jù)進行處理的事實。在一個示例中，可以使用小服務程序引擎的網(wǎng)頁應用來但當這種鏡像。
當客戶端連接到服務器時，可以創(chuàng)建一個與該客戶端或用戶關(guān)聯(lián)的會話對象。在會話期間，會話對象可以在主服務器上維持，或者在經(jīng)過指定的時間期間后，可以終止該會話對象。每個會話對象可以被給予一個唯一的標識符或標識號碼，以便識別客戶端和/或到服務器的對象。在會話期間，被選擇服務請求的服務器充當主服務器。對于該會話對象，主服務器可以選擇一個副服務器，例如每次更新對象時，所述更新也被保存在副服務器中。副服務器可以被優(yōu)化用來接收僅僅最小的信息或者對更新進行批處理，以便提高系統(tǒng)的效率。
在圖1中示出了根據(jù)本發(fā)明一個實施例的一個基于網(wǎng)頁的系統(tǒng)100。在該系統(tǒng)中，瀏覽器102、或客戶端發(fā)出一個請求，該請求被網(wǎng)頁服務器104接收。網(wǎng)頁服務器104充當一個代理，在這里網(wǎng)頁服務器查看所述請求，并且確定哪個對象服務器110應該接收該請求。網(wǎng)頁服務器可以具有認識到該請求的插件程序、或者插件API。插件通常是一種被添加到應用程序中的對象，以便提供附加的功能，而不需要啟動任何外部應用程序。插件可以做出負載均衡判斷，以便能夠在可以為客戶端102創(chuàng)建和容納會話的對象服務器110之間進行選擇。網(wǎng)頁服務器104代理返回到所選擇的對象服務器110，所述對象服務器110可以被容納在應用程序服務器106中。應用程序服務器106中的小服務程序引擎108可以執(zhí)行用于調(diào)用對象服務器110上的對象的小服務程序，以便響應請求。為了充分響應請求，對象服務器110能夠還會需要從數(shù)據(jù)庫112或者數(shù)據(jù)存儲器中提取信息。對象服務器110一旦接收到請求就可以創(chuàng)建會話。為了提供安全性，應用程序服務器106和數(shù)據(jù)庫可以位于防火墻114之后，如現(xiàn)有技術(shù)所知和所用的。
隨后，在本示例中的對象服務器為該會話選擇一個副服務器。在一個替代的實施例中，一個插件可以用來選擇副服務器。該插件也可以使用負載均衡來進行判斷。
對象服務器將數(shù)據(jù)傳遞到副服務器，并且讓副服務器知道它將是備份。隨后對象服務器創(chuàng)建一個cookie，該cookie將被發(fā)送到客戶端并且被客戶端存儲。該cookie包括用于會話的主和副服務器的身份識別。
當在相同的會話中由客戶端發(fā)送隨后的請求時，由哪個網(wǎng)頁服務器接收到該請求是沒有關(guān)系的。網(wǎng)頁服務器將查看cookie，以便確定所述會話的主服務器，并且隨后將該請求路由到所述主服務器。
假設一個具有三個小服務程序引擎306、308和312的示例，如圖3所示，每個小服務程序引擎能夠充當一個主服務器。如果在主服務器306上正在進行會話，但是主服務器306出現(xiàn)故障，則通過檢查用來自瀏覽器302的請求發(fā)送的cookie信息，網(wǎng)頁服務器304可以確定選擇哪個服務器作為副服務器。隨后網(wǎng)頁服務器可以嘗試將該請求路由到副服務器308，該副服務器308也包含有會話狀態(tài)信息310。網(wǎng)頁服務器可以將一個響應返回到瀏覽器302，而該瀏覽器將提出另一個可以由網(wǎng)頁服務器304指引到該副服務器308的請求。如果副服務器308接收到該請求，則它可以自動變成新的主服務器，因為副服務器308知道如果主服務器306不能接收請求，則它僅接收直接來自該網(wǎng)頁服務器的請求。這里，副服務器308，現(xiàn)在是主服務器308可以選擇新的副服務器312。或者，到網(wǎng)頁服務器304的插件可以選擇新的副服務器312。通信出現(xiàn)故障的一個可能位置由第一虛擬邊界314所示，它存在于瀏覽器/客戶端302與網(wǎng)頁服務器304之間。第二虛擬邊界存在于網(wǎng)頁服務器304與小服務程序引擎306、308和312之間。
在一些實施例中，為了確定主服務器的狀態(tài)，副服務器或網(wǎng)頁服務器主動地監(jiān)視主服務器。這種監(jiān)視可以通過任何適當?shù)姆绞絹磉M行，例如通過持續(xù)地或周期性地“pinging”主服務器來確定它是否仍連接到網(wǎng)絡。如果確定主服務器不能接收請求，則副服務器可以變成新的主服務器。隨后可以選擇一個新的副服務器。這種設計的一個優(yōu)點是由于雙重服務器故障所導致的會話狀態(tài)損失的時間窗口較窄。雖然一些實施例允許該窗口根據(jù)客戶端的請求率來定義，但是這種方案允許該窗口根據(jù)服務器pinging的比率來定義。
新的主服務器和副服務器同樣地對為會話所有的信息負責。先前為主服務器的服務器將不再對那個會話負有任何責任或信息，即使在對話仍在進行時，那個服務器又變得能夠接收和處理請求。副服務器可以自動地改變它的狀態(tài)，從而它為會話而變成新的主服務器，但是它可以選擇不指定一個新的副服務器，直到新的主服務器接收到一個請求為止。
可能不期望主動地創(chuàng)建一個新的副服務器或者備份副服務器上的會話信息，因為可能不會知道新的主服務器是否將接收另一個請求。創(chuàng)建一個不會被使用的新的副服務器或備份將不被使用的信息可能造成不必要的資源浪費。會話或者會是短暫存在的，并且不會“存活”足夠長的時間以接收隨后的請求。典型的，每個會話都會具有一個超時值，從而如果會話在一段確定的時間期間內(nèi)為無效時，該會話將“超時”或“死去”，該會話將結(jié)束，并且為會話存儲的所有數(shù)據(jù)可能被刪除，以便保存存儲器空間。在這種情況下，不僅創(chuàng)建副服務器會浪費資源，而且還需要不必要的“清理”工作來消除來自新的副服務器的會話信息。
根據(jù)一種算法可以選擇主和/或副服務器，該算法可以將例如指定的服務器集群中的任何服務器作為選項。雖然利用一種算法為每個會話選擇主和副服務器是可能是有效的，但是還有存在期望由管理員輸入的情況。例如，可能多個服務器位于一臺機器中。如果算法正在選擇服務器，例如基于負載的算法，則該算法可以選擇在相同機器中的兩個服務器。一旦機器發(fā)生故障，則兩個服務器都不能使用，而會話數(shù)據(jù)也不能使用和/或丟失。然而，管理員可以選擇在不同機器中的特定主和副服務器。這不但可以提供服務器之間的備援還可以提供機器之間的備援。
或者，當進行負載均衡分析時，可以在算法本身中建立一個參數(shù)，并考慮到服務器所位于的機器。如果具有最低當前負載的服務器與主服務器在相同的機器中，則算法可以選擇在不同機器中的具有最低負載的服務器?？梢詫⑦@種方案擴展到任何分開的程度上，例如在不同房間、不同建筑物、或不同城市中的服務器。
為了允許集群中的服務器的能夠獨立地運行，可以寬松地連接服務器。為了實現(xiàn)這種寬松的連接，集群中的每個服務器可以被配置用來檢測其它的集群服務器的狀態(tài)，從而當服務器自愿或非自愿地脫離集群時可以采取動作。在一個實施例中，服務器可以依賴下層的操作系統(tǒng)來監(jiān)視集群服務器的狀態(tài)。其它實施例可以要求服務器進行監(jiān)視。由于服務器的資源可用來提高系統(tǒng)的整體吞吐量，因此在實施例中最好集群服務器不必參與集群監(jiān)視。
圖2示出了根據(jù)本發(fā)明的多級集群結(jié)構(gòu)200。系統(tǒng)中的每個對象可以通過舉例幾個服務器中可用的對象來被集群。示出該結(jié)構(gòu)包括虛擬邊界。術(shù)語“虛擬邊界”是指網(wǎng)絡連接可能失敗的地方。
在圖2中，第一個虛擬邊界212示出在瀏覽器202與網(wǎng)頁服務器204之間。第二個界線214示出在網(wǎng)頁服務器204與小服務程序引擎206之間。第三個界線216示出在小服務程序引擎206與對象服務器208之間。最后，第四個界線218示出在對象服務器208與數(shù)據(jù)庫210之間。每個界線表示通信失敗的可能點，這也可以充分利用負載均衡。
在第一虛擬界線，有可能瀏覽器不能到達特定的網(wǎng)頁服務器。然而，這在根據(jù)本發(fā)明的系統(tǒng)中就不是一個問題，因為有關(guān)主和副服務器的信息可能已經(jīng)存儲在瀏覽器中的cookie中。瀏覽器可以聯(lián)絡到網(wǎng)絡上的任何網(wǎng)頁服務器，因為瀏覽器可以通過cookie指示該網(wǎng)頁服務器哪個服務器應該接收該請求。當在局域網(wǎng)(LAN)上該系統(tǒng)可能是最有效的時候，可以在任何可能的網(wǎng)絡上使用一種類似的方案。例如，瀏覽器可以經(jīng)由因特網(wǎng)聯(lián)絡可能位于與第一網(wǎng)頁服務器分開的建筑物中的第二網(wǎng)頁服務器和/或后端服務器。
根據(jù)該應用，主和副服務器可以是幾種不同的類型的服務器，例如網(wǎng)頁服務器、小服務程序引擎、或企業(yè)Java組件(“ejb”)引擎。還可能在集群中的每個服務器都是分離的和特定的，例如都是不同的服務器類型，但是還能夠充當主和/副服務器。
如果集群在根據(jù)本發(fā)明的系統(tǒng)中是可用的，則能夠明顯地將新服務器添加到系統(tǒng)中充當附加主和副服務器。通常，集群是一種用于服務器管理的方法，通過在一組服務器中建立一個“管理”服務器來允許管理這組服務器。這種方法能夠簡化集群中的服務器之中的可能的各種元件的配置和同步。集群可以充分地提高系統(tǒng)可靠性和可伸擴性。
當對根據(jù)本發(fā)明系統(tǒng)進行集群時，集群中的每個服務器都可以被配置用來檢測進入集群中的新服務器，并且將新服務器作為一個副服務器指定給任意存在的主服務器。用于負載均衡的方法可以立即將新服務器指定為主或副服務器。
根據(jù)本發(fā)明的系統(tǒng)或者可以利用硬件負載均衡器來指引輸入的請求。在因特網(wǎng)設置中，例如，硬件負載均衡器可以使用一個IP(因特網(wǎng)協(xié)議)地址來裝置在網(wǎng)絡上。來自瀏覽器或客戶端的輸入請求可以被指引到那個IP地址。隨后硬件負載均衡器可以將那些請求重新指引到其它IP地址，或其它的每個都分配了一個IP地址，位于系統(tǒng)中、但卻在硬件負載均衡器“后面”的服務器。以這種方式，在瀏覽器看來好像請求一直轉(zhuǎn)到相同的IP地址，但實際上可能轉(zhuǎn)到位于那個IP地址之后的多個服務器。硬件負載均衡器可以被位于其后的所有服務器所認知，例如可能是將服務器硬布線到硬件負載均衡器的結(jié)果，而不是利用諸如軟件集群的另一種方法。
使用硬件負載均衡器是有好處的。對于負載均衡，硬件負載均衡器可以利用比其它方法更好的算法。硬件負載均衡器能夠檢測到節(jié)點故障，從而可以將這些節(jié)點從對算法有用的服務器列表中移除。這種節(jié)點移除可以防止算法試圖轉(zhuǎn)到不能達到的服務器，即使那些特殊服務器還沒有被發(fā)出請求。
根據(jù)本發(fā)明的系統(tǒng)也可以使用域名系統(tǒng)(DNS)協(xié)議，例如DNS循環(huán)(DNSRound Robin)，來代替使用硬件負載均衡器，將域名映射到幾個IP地址，或者將發(fā)送到網(wǎng)頁服務器的請求重新指引到幾個對象服務器。然而，DNS不能典型地確定或檢測那些IP地址是否實際“有效”。
根據(jù)請求是否需要動態(tài)頁產(chǎn)生(dynamic page generation)或請求是否用于靜態(tài)頁，硬件負載均衡器可以被用來將某種類型的請求代理到指定的服務器或服務器集群。在圖4中，示出了在網(wǎng)頁瀏覽器402與網(wǎng)頁瀏覽器404、408與412之間的負載均衡器414。
雖然期望對與本發(fā)明一起使用的硬件負載均衡器414進行優(yōu)化，但是對于負載均衡器本身不能期望要求物理變化。對于硬件負載均衡器，也不能期望其必須讀取cookie，并且判斷到是否第一主服務器404發(fā)生故障，該請求必須被重新指引到由存儲在瀏覽器402中的cookie所指示的副服務器408。然而，可以期望讓負載均衡器將請求指引到負載均衡器希望的地方，并且隨后確保該系統(tǒng)被適當?shù)鼗謴汀?br> 在這樣一種方法中，硬件負載均衡器414趨向于根據(jù)存儲在網(wǎng)頁瀏覽器上的cookie中的一些任意信息，將來自瀏覽器402或客戶端的請求發(fā)送到一個服務器。例如，cookie可以具有信息的初始字符串，隨后是有關(guān)主和副服務器的信息段，以及用于復制的會話標識符。硬件負載均衡器414可以被配置為只查看這個信息段。如果這個信息段在連續(xù)的cookie之間不變化，則負載均衡器可以持續(xù)地重新指引該請求回到主服務器404。那種“會話粘貼stickiness”也可以基于其它合適的方法，例如可以使用客戶端的IP地址。
cookie中的信息段可以保持得與請求返回到主服務器一樣長。如果主服務器因為任何原因發(fā)生故障，則副服務器可以將它自己指定為新的主服務器。該新的主服務器隨后為新的副服務器將新的信息插入到該段中，該新的副服務器可以由新的主服務器或負載均衡機制來選擇?；蛘?，硬件負載均衡器也可以選擇一個新的主服務器，并且將該請求重新指引到該新的主服務器。
由負載均衡器接收的會話的第一個請求可能不被硬編碼轉(zhuǎn)到一個主服務器。在提出第一個請求并且從對象服務器或其它后端服務器返回之后，可以做出“粘貼”到一個服務器的判斷。硬件負載均衡器可以足夠聰明地來實現(xiàn)這種“簡單粘貼”，或者根本上(primarily)返回到負載均衡器連接到的指定的主服務器。
如果不存在cookie，則硬件負載均衡器可以被配置成例如基于負載或響應時間使用任何一定數(shù)量的負載均衡方法。隨后負載均衡器可以選擇一個服務器，例如在合適的集群中，并且將該請求指引到那個服務器。當那個主服務器響應請求時，服務器可以向瀏覽器發(fā)送一個cookie，該cookie包含有關(guān)主和副服務器的信息段。來自那個瀏覽器的、由硬件負載均衡器接收的每個隨后的請求都可以具有與其相關(guān)的那個cookie，從而負載均衡器可以將那個請求與該主服務器關(guān)聯(lián)起來。
系統(tǒng)仍不能保證請求將被轉(zhuǎn)到該主服務器。如圖4所示，如果在主服務器404出現(xiàn)故障并且另一個請求進入負載均衡器414，則負載均衡器可以簡單地做出另一個負載均衡判斷，并且將該請求指引到另一個服務器412。請求可能不會被轉(zhuǎn)到副服務器408。這種方法不同于上述的插件方法，在那個方法中請求可以自動地轉(zhuǎn)到第二個服務器。在本方法中，硬件負載均衡器沒有上述的那種特殊代理插件“聰明”，與上述方法相似。
如果由負載均衡器414選擇的服務器412不是副服務器408，則被選擇的服務器412能夠認識到該請求是一個在會話中的沒有服務器提供服務(hosting)的請求。在這種情況下，被選擇的服務器412可以查看cookie來確定副服務器408。
一旦被選擇的服務器412已經(jīng)定位了副服務器408，則被選擇的服務器412可以從副服務器408請求會話狀態(tài)信息410。被選擇的服務器412然后將它本身轉(zhuǎn)換成該會話新的主服務器。在這種情況下的副服務器408可以保持與原來一樣。Cookie被更新，從而負載均衡器414將持續(xù)將請求指引到新的主服務器412。
在負載均衡器414偶然將請求指引到的信服務器是副服務器408的情況下，則副服務器可以將它自己設置為新的主服務器，并且可以選擇一個新的副服務器。
具有一種硬件負載均衡器的系統(tǒng)可以提供一條快速數(shù)據(jù)路徑，所述負載均衡器在其后具有小服務程序集群。如果網(wǎng)頁服務器執(zhí)行路由，則該請求可能需要調(diào)用執(zhí)行某些代碼的軟件，隨后被發(fā)送回到網(wǎng)絡。負載均衡器/小服務程序集群系統(tǒng)在較低的協(xié)議層上執(zhí)行所有的工作，從而相對非?？斓赝瓿伞?br> 使負載均衡算法盡可能本地化是有好處的。在硬件負載均衡器的情況下，僅需要確保服務器上的軟件正在正常工作，例如用Java寫的軟件。在沒有硬件均衡器的系統(tǒng)中，需要確保系統(tǒng)中每個網(wǎng)頁服務器的每個特定的插件都工作良好。
對于不同的平臺，也都需要支持插件。硬件負載均衡器與基于不同平臺的系統(tǒng)可以同樣地工作得很好，例如Netscape Application ServerTM(NAS)、WebLogic ServerTM(WLS)、MicrosoftInternet Information Server(IIS)、或Apache HTTP Server。利用硬件負載均衡器，由于可以消除其中的一列，系統(tǒng)可以減少一個層次的復雜度。在圖4中示出了這種情況，其中網(wǎng)頁服務器和小服務程序在同一個處理中。
上述系統(tǒng)中的一些可以使用小服務程序用于網(wǎng)頁訪問。一種類似的機制可以被用來訪問有狀態(tài)的(statefull)會話組件，一種類型的企業(yè)Java組件(“ejb”)。小服務程序可以被用于來自瀏覽器客戶端的服務請求，而ejb服務器可以被用于支持來自Java客戶端的請求。
使用Java客戶端，可能在會話的整個持續(xù)期間，有一個持久的單一連接。隨后可以不需要(或支持)cookie。而且，由于存在持久的連接，不再需要負載均衡器。通過使用例如DNS或負載均衡器，Java客戶端可以連接到多個后端服務器中的一個。隨后Java客戶端可以查找到有狀態(tài)的會話的“句柄”(“handle”)。Java中的句柄類似于指針，可以被用來定位合適的會話。
參考圖5的系統(tǒng)500，一旦Java客戶端502連接到一個句柄，則可以創(chuàng)建有狀態(tài)的會話組件510。有狀態(tài)的會話組件510可以被用來處理用于會話的信息的高速緩沖或存儲。當創(chuàng)建有狀態(tài)的會話組件時，具有該會話組件的服務器可以成為主服務器508，從而Java客戶端502可以向其做出請求。隨后主服務器506可以選擇一個副服務器512。副服務器510也可以用有狀態(tài)的會話組件512來對會話信息進行高速緩沖或存儲。
有狀態(tài)的會話組件508通過使用RMI(Java遠程方法調(diào)用)協(xié)議可以將該信息傳遞回Java客戶端502，就像發(fā)送cookie一樣。與處理事務上下文傳播工作的方式類似，為了使該cookie模擬起作用，可以將額外的信息放置在標準RMI的頂部(on top)?？梢詫⒅?副服務器的標識符與每個響應一起傳遞回Java客戶端502。每次Java客戶端502進行呼叫時，可以通過一個接口504來呼叫特定的RMI代碼，所述RMI代碼適合繼續(xù)為那個會話對主服務器506進行呼叫。如果主服務器失敗，則Java客戶端502可以查看有關(guān)副服務器510的位置的信息，并且可以對副服務器提出一個請求作為代替。為了效率，最好是只有關(guān)服務器標識的重要信息被傳遞回RMI的頂部。
Java客戶端502總是知道哪個服務器是副服務器510。Java客戶端也有相同的邏輯，即存在一個代理，譬如，如果主服務器506是不可用的，Java客戶端總是直到轉(zhuǎn)到副服務器510。Java客戶端可以監(jiān)視服務器的健康，以便避免將請求發(fā)送到不可用的服務器。在副服務器510成為新的主服務器的情況下，仍可以選擇一個新的副服務器514。用于選擇一個新的主和/或副服務器的邏輯與上面描述的類似。Java客戶端可以立即更新到新的主/副服務器。
根據(jù)上述討論，根據(jù)本發(fā)明的系統(tǒng)通常按照兩種分支方法之一，盡管也可以使用包括了上面所提到的方法的各種變體。圖6示出了這樣一種方法的公共部分。在圖6的處理600中，從一組服務器602中選擇一個主服務器。一旦選擇了一個主服務器，則在那個主服務器上服務客戶端請求604。隨后可能由主服務器來選擇一個副服務器606。然后會話信息從主服務器發(fā)送到副服務器608。標識主和副服務器的信息可以保存在客戶端610，例如可以保存在cookie中或者傳遞到標準(或其它)RMI的頂部。
根據(jù)這一點，處理分支分為一種對軟件負載均衡有利的方法，以及一種對硬件均衡有利的方法。圖7示出了對軟件負載均衡有利的處理700。在處理700中，在一個已經(jīng)選擇了主和副服務器的會話上接收請求，并且從存儲在客戶端上的信息中獲得(garner)主服務器的識別702。隨后嘗試在主服務器上對該請求進行服務704。如果主服務器不能服務請求，則在副服務器上對所述請求進行服務。一旦副服務器接收該請求，則副服務器成為新的主服務器708。隨后選擇一個新的副服務器，并且從該新的主服務器中發(fā)送會話信息710。
圖8示出了對具有硬件負載均衡器的系統(tǒng)有利的另一種方法。在圖8的處理800中，在一個已經(jīng)選擇了主和副服務器的會話上接收請求，并且從存儲在客戶端上的信息獲得主服務器的識別802。隨后嘗試在主服務器上對該請求進行服務804。如果主服務器不能服務請求，則硬件負載均衡器選擇一個新的主服務器，并且嘗試在新的主服務器上服務該請求806。隨后將會話信息從副服務器發(fā)送到新的服務器808，例如響應來自新的主服務器的一個請求。然后，該新的主服務器可以響應所述請求，并且將所更新的會話信息發(fā)送到副服務器810。
為了在本發(fā)明的任何實施例中維持一致性，會話數(shù)據(jù)中的變化可以與一個版本號關(guān)聯(lián)。每個主和副服務器都可以知道它所存儲的會話的版本。只有在服務器接收一個具有版本號晚于、或高于它當前存儲的版本號的請求時，才可以被命令修改其數(shù)據(jù)。主和副服務器可以定期地互相檢查，以便確保他們都具有相同的版本號。版本號可以使用一種與增加號碼一樣簡單的方法來確保排序。為了將會話信息保持一致，可以期望主和副服務器保持同步。當版本號不同步時，主服務器可以選擇將整個會話信息發(fā)送到副服務器，以便將會話恢復到同步。如果需求增加，同步也提高了服務器在主和副服務器的任務之間進行替換的能力。
如果主服務器由于例如惡劣的連接狀況而不能更新副服務器上的信息，則可能是主服務器保持更新，而副服務器卻沒有覺察到任何更新。隨后也可能是，主服務器比副服務器提前幾個版本。一旦主服務器能夠再次將信息發(fā)送到副服務器，則在兩個連續(xù)版本之間的增量可能不能工作。在那樣的情況下，主服務器可以將整個新一套的會話數(shù)據(jù)發(fā)送到副服務器，以便使數(shù)據(jù)會話一致穿過這兩個服務器。在這樣的情況下，副服務器或者獲得連續(xù)版本之間的增量，或者獲得整個會話的所有數(shù)據(jù)。在其它實施例中，能夠產(chǎn)生任意版本之間的增量，以便使副服務器提升到當前版本。
在模擬cookie以跟蹤Java狀態(tài)的過程中，服務器標識可能會使用很大的隨機數(shù)。這些數(shù)可以足夠大，從而兩個不同的標識號碼對的和不可能相同。也可能僅將這兩個號碼發(fā)送回Java客戶端，并且可以通過將這兩個號碼相加在一起得到一個新號碼來識別這對服務器。這允許通過僅傳遞一個號碼來識別兩個服務器，從而可以提高效率。由于Java客戶端可能與特定服務器具有持久的連接，因此客戶端可以通過將主服務器的標識號碼從傳遞的相加的號碼中減去來識別副服務器，以便達到副服務器的標識號碼。
然而，諸如會話組件的Java對象可以是無狀態(tài)的或者具有瞬變狀態(tài)的，這與上述的持久狀態(tài)相反。如果Java會話組件是無狀態(tài)的，則該組件不能夠維持在調(diào)用或者連續(xù)請求之間的會話信息。如果會話信息被存儲在別處，則無狀態(tài)的組件可以臨時地載入會話信息，以便服務所述請求。只有在完全調(diào)用失敗的情況下，例如，在主服務器從未接收到請求的情況下，所述請求是處理事務性的(transactional)并且被中止的，或者是一次性的請求的情況下，才進行故障切換，或者將會話控制移交到具有復制的會話信息的新主服務器。另一方面，如果會話組件是瞬變的，可以創(chuàng)建通過具有無狀態(tài)的負載均衡和故障切換的無狀態(tài)工廠(factory)的例子。處于瞬變狀態(tài)的組件或者不能被備份，或者可以通過使用如上所述的主/副服務器復制在存儲器中備份。
可以使用批更新來改善具有日益增加的故障窗口的系統(tǒng)的總處理能力。當進行批處理或“盒式攜帶(boxcarring)”時，為了提高效率和可伸擴性，將幾個請求作為一個大的請求一起發(fā)送。請求的批處理可以基于任意數(shù)量的準則，例如時間間隔或請求數(shù)量。例如，系統(tǒng)可以每10秒發(fā)送一批請求，或者對于每100單個會話更新消息。系統(tǒng)也可以適應這兩種準則，即或者經(jīng)過了10秒或者接收到了100個請求，不論哪個標準限達到，就發(fā)送一個批處理。批處理可能使系統(tǒng)不再與同步更新一樣可靠，但是可以提高整個系統(tǒng)可伸擴性。
也可以例如由用戶或管理員來配置準則?？膳渲玫臏蕜t可適用于這樣的情況，即系統(tǒng)在某一時刻遇到大量的通信量，而在其它時刻幾乎沒有通信量。例如，可配置的準則允許在高峰時刻批處理每100個消息，但是在不工作時間根本不進行批處理，從而在合理的時間量內(nèi)發(fā)送每個請求。
系統(tǒng)管理員也可以選擇將一個集群中的兩個服務器配對成主和副服務器。管理員的輸入是可以期望的，以便提高系統(tǒng)的整個容錯性。例如，多個服務器可以位于一個物理機器中，并且一種算法可以選擇將主和副服務器兩者都放入相同的機器中。隨后如果機器發(fā)生故障，則會話信息將會完全丟失。為了防止由于機器發(fā)生故障引起的會話信息的丟失，管理員可以選擇指定一個主服務器和一個副服務器，每個主和副服務器都在獨立的物理機器上。管理員也可以根據(jù)各種各樣的負載均衡方案來選擇主服務器?？赡芊桨傅氖纠蓟诜掌髫撦d、連接數(shù)量、以及物理近似度。
為了說明和描述，已經(jīng)提供了對本發(fā)明優(yōu)選實施例的上述描述。不必窮舉本發(fā)明的實施例，并且本發(fā)明的實施例并不限于所公開的具體形式。顯然的，對于本領(lǐng)域的技術(shù)人員來說許多修改和變化是清楚的。為了最好地解釋本發(fā)明的原理及其實際應用，選擇并描述了這些實施例，從而能夠使本領(lǐng)域的技術(shù)人員理解各種各樣實施例的本發(fā)明以及適合特殊預期使用的各種修改。本發(fā)明的范圍由所附權(quán)利要求及其等價物來定義。
權(quán)利要求
1.一種用于復制在客戶端會話中的信息的系統(tǒng)，包括b.主服務器，適用于接收在客戶端會話中的請求，并且對所述請求進行響應，所述主服務器還適用于存儲所述客戶端會話的會話信息；c.副服務器，適用于接收在客戶端會話中的請求，并且對所述請求進行響應，所述副服務器還適用于存儲所述客戶端會話的會話信息；以及d.網(wǎng)頁服務器，適用于接收來自客戶端的請求，該請求包括所述主和副服務器的標識信息，該網(wǎng)頁服務器適用于處理該標識信息，并且在所述主服務器上服務該處理請求，如果所述主服務器不能處理該請求，則網(wǎng)頁服務器還適用于在所述副服務器上服務該請求。
2.根據(jù)權(quán)利要求1的系統(tǒng)，還包括與所述主和副服務器通信的數(shù)據(jù)庫，所述數(shù)據(jù)庫在處理請求時存儲有用的信息。
3.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述主服務器還適用于在每次所述主服務器接收所述客戶端會話的請求時，更新存儲在所述副會話服務器中的會話信息。
4.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述網(wǎng)頁服務器還適用于當為客戶端會話接收一個初始請求并且在客戶端不存在標識信息時，從多個服務器中選擇所述主服務器。
5.根據(jù)權(quán)利要求1的系統(tǒng)，還包括適于存儲在客戶端的cookie，所述cookie適用于包含所述主和副服務器的標識信息。
6.根據(jù)權(quán)利要求5的系統(tǒng)，其中所述主服務器還適用于在客戶端產(chǎn)生所述cookie。
7.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述網(wǎng)頁服務器還包括一個用于選擇所述主服務器的算法的插件。
8.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述網(wǎng)頁服務器還包括一個用于將請求指引到所述主和副服務器的算法的插件。
9.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述算法是一種負載均衡算法。
10.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述主服務器適用于選擇所述副服務器。
11.根據(jù)權(quán)利要求1的系統(tǒng)，其中當所述主服務器適用于在從客戶端接收到一個初始請求時，被啟動客戶端會話。
12.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述副服務器還適用于如果副服務器接收一個不能被所述主服務器處理的請求，則變成新的主服務器。
13.根據(jù)權(quán)利要求12的系統(tǒng)，其中所述副服務器還適用于選擇一個新的副服務器，并且將會話信息發(fā)送到該新的副服務器。
14.根據(jù)權(quán)利要求12的系統(tǒng)，其中所述網(wǎng)頁服務器選擇一個新的副服務器。
15.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述副服務器還適用于監(jiān)視所述主服務器，以便確定所述主服務器是否可以接收請求。
16.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述副服務器還適用于如果所述主服務器不能接收請求，則變成一個新的主服務器。
17.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述主和副服務器中的一個是從由網(wǎng)頁服務器、小服務程序引擎、以及企業(yè)Java組件引擎組成的組中選擇的。
18.一種用于復制在Java客戶端會話中的信息的系統(tǒng)，包括a.主服務器，適用于從Java客戶端接收客戶端會話中的請求，并且對該請求進行響應，所述主服務器還適用于存儲該客戶端會話的會話信息；b.副服務器，適用于接收在客戶端會話中的請求，并且對該請求進行響應，所述主服務器還適用于存儲該客戶端會話的會話信息；以及c.主服務器中的有狀態(tài)的會話組件，用于存儲客戶端會話的信息，并且將所述主和副服務器的標識傳遞回客戶端。
19.根據(jù)權(quán)利要求18的系統(tǒng)，還包括負載均衡器，適用于從客戶端接收請求，并且選擇所述主服務器。
20.根據(jù)權(quán)利要求18的系統(tǒng)，其中所述主服務器適用于在客戶端會話期間，維持與Java客戶端的持久連接。
21.根據(jù)權(quán)利要求1的系統(tǒng)，其中所述網(wǎng)頁服務器還適用于將請求批量發(fā)送到所述主服務器。
22.一種用于在客戶會話中提供備援的方法，包括a.對在客戶端會話中來自客戶端的初始請求做出負載均衡判斷，以便從多個會話服務器中選擇一個主服務器；b.在所述主服務器上服務所述請求；c.選擇一個副服務器；d.將所述客戶端會話的會話信息從主服務器發(fā)送到副服務器；并且e.每次在客戶端會話中接收到請求時，在主和副服務器上更新會話信息。
23.根據(jù)權(quán)利要求22的方法，還包括將信息存儲在客戶端的cookie中。
24.根據(jù)權(quán)利要求22的方法，還包括如果主服務器不能處理請求，則在副服務器上服務請求。
25.根據(jù)權(quán)利要求24的方法，還包括選擇一個新的副服務器。
26.根據(jù)權(quán)利要求22的方法，還包括將請求批量地提供到主服務器。
27.根據(jù)權(quán)利要求22的方法，還包括將該客戶端會話的會話信息從主服務器批量發(fā)送到副服務器。
28.根據(jù)權(quán)利要求22的方法，還包括將會話信息存儲在有狀態(tài)的會話組件中。
29.根據(jù)權(quán)利要求22的方法，還包括響應請求，將版本號與對會話信息的每次更新相關(guān)聯(lián)。
30.根據(jù)權(quán)利要求22的方法，其中將該客戶端會話的會話信息從主服務器發(fā)送到副服務器，包括發(fā)送包含會話信息的變化的信息的增量。
31.根據(jù)權(quán)利要求22的方法，還包括給主和副服務器中的每個分配一個標識號碼。
32.根據(jù)權(quán)利要求31的方法，還包括將主服務器的標識號碼與副服務器的標識號碼相加，以便獲得描述主和副服務器兩者的一個號碼。
33.一種用于復制在客戶端會話中的信息的系統(tǒng)，包括a.多個會話服務器；b.在所述多個會話服務器中的主服務器，所述主服務器適用于接收在客戶端會話中的請求，并且對所述請求提供響應，所述主服務器還適用于存儲該客戶端會話的會話信息，并且適用于產(chǎn)生包括有關(guān)所述主服務器的信息的cookie，并且將該cookie發(fā)送到會話客戶端；c.由所述主服務器選擇的在所述多個會話服務器中的副服務器，所述副服務器適用于從所述主服務器接收會話信息，并且存儲該會話信息，所述副服務器還適用于接收在客戶端會話中的請求，并且對所述請求提供響應；以及d.網(wǎng)頁服務器，適用于接收來自客戶端的請求，該請求包括所述主和副服務器的標識信息，該網(wǎng)頁服務器適用于處理該標識信息，并且在所述主服務器上服務該處理請求，如果所述主服務器不能處理請求，則該網(wǎng)頁服務器還適用于在所述副服務器上服務請求。
34.一種用于在客戶端會話中提供備援的方法，包括a.對在客戶端會話中來自客戶端的初始請求做出負載均衡判斷，以便從多個會話服務器中選擇一個主服務器；b.在所述主服務器上服務所述請求；c.將該客戶端會話的會話信息從主服務器發(fā)送到由所述主服務器選擇的副服務器；d.在會話客戶端中存儲包含用于標識主和副服務器的信息的cookie；并且e.每次在客戶端會話中接收請求時，更新在主和副服務器的會話信息。
35.根據(jù)權(quán)利要求34的方法，還包括步驟在客戶端會話中接收的請求中讀取標識信息，并且在主服務器上服務該請求。
36.一種用于復制在客戶端會話中的信息的系統(tǒng)，包括a.多個會話服務器；b.在所述多個會話服務器中的主服務器，所述主服務器適用于接收客戶端會話中的請求，并且對所述請求提供響應，所述主服務器還適用于存儲所述客戶端會話的會話信息，并且適用于產(chǎn)生包括有關(guān)所述主服務器的信息的cookie，并且將該cookie發(fā)送到會話客戶端；c.在由所述主服務器選擇的在所述多個會話服務器中的副服務器，所述副服務器適用于從所述主服務器接收會話信息，并且存儲該會話信息，所述副服務器還適用于接收在客戶端會話中的請求，并且對所述請求提供響應；以及d.網(wǎng)頁服務器，包含用于選擇所述主服務器的負載均衡邏輯，所述網(wǎng)頁服務器適用于從客戶端接收初始請求，并且將該請求指引到所述主服務器，所述網(wǎng)頁服務器還適用于接收來自客戶端的隨后請求，該隨后請求包含所述主和副服務器的標識信息，該網(wǎng)頁服務器適用于處理標識信息，并且在所述主服務器上服務處理請求，如果所述主服務器不能處理請求，則該網(wǎng)頁服務器還適用于在所述副服務器上服務該請求。
37.一種用于在客戶端會話中提供備援的方法，包括a.對在客戶端會話中來自客戶端的初始請求做出負載均衡判斷，以便從多個會話服務器中選擇一個主服務器；b.在所述主服務器中服務所述請求；c.將該客戶端會話的會話信息從主服務器發(fā)送到由所述主服務器選擇的副服務器；d.在會話客戶端中存儲cookie，該cookie包含標識主和副服務器的信息；e.讀取在客戶端會話中與任何隨后請求接收的標識信息，并且在主服務器上服務該隨后請求；以及f.每次在主服務器上為該客戶端會話服務隨后請求時，更新主和副服務器上的會話信息。
38.一種用于在客戶端會話中提供備援的方法，包括a.響應來自客戶端的初始請求，從多個會話服務器中選擇一個主服務器；b.在所述主服務器上服務所述請求，以便開始一個客戶端會話；c.選擇一個副服務器；d.將該客戶端會話的會話信息從主服務器發(fā)送到副服務器；并且e.每次在客戶端會話中接收請求時，對主和副服務器上的會話信息進行更新。
39.根據(jù)權(quán)利要求38的方法，還包括步驟將信息存儲在客戶端的cookie中。
40.根據(jù)權(quán)利要求38的方法，還包括步驟如果主服務器不能處理所述請求，則在副服務器上服務該請求。
41.根據(jù)權(quán)利要求40的方法，還包括步驟選擇一個新的副服務器。
42.根據(jù)權(quán)利要求38的方法，還包括步驟將請求批量地提供到主服務器。
43.根據(jù)權(quán)利要求38的方法，還包括步驟將該客戶端會話的會話信息從主服務器批量發(fā)送到副服務器。
44.一種用于復制客戶端會話中的信息的系統(tǒng)，包括a.多個服務器；b.在所述多個服務器中的主服務器，所述主服務器適用于接收在客戶端會話中的請求，并且對該請求提供響應，所述主服務器還適用于存儲該客戶端會話的會話信息；c.在所述多個服務器中的副服務器，所述副服務器適用于接收在客戶會話中的請求，并且對該請求提供響應，所述副服務器還用于存儲該客戶端會話的會話信息；以及d.硬件負載均衡器，適用于從客戶端接收請求，該請求包含所述主和副服務器的標識信息，所述硬件負載均衡器適用于檢查該請求包含標識信息的部分，并且如果那部分自從先前請求以后未被更改則在所述主服務器上服務處理請求，如果那部分被更改，則所述硬件負載均衡器還適用于從所述多個服務器選擇一個新的主服務器。
45.根據(jù)權(quán)利要求44的系統(tǒng)，還包括適于存儲在客戶端的cookie，所述cookie適用于包含所述主和副服務器的標識信息。
46.根據(jù)權(quán)利要求45的系統(tǒng)，其中所述cookie包含所述主服務器的號碼和所述副服務器的號碼。
47.根據(jù)權(quán)利要求45的系統(tǒng)，其中所述cookie包含所述主服務器的號碼和所述副服務器的號碼的相加的和的一個號碼。
48.根據(jù)權(quán)利要求44的系統(tǒng)，其中所述硬件負載均衡器還適用于如果所述主服務器不能處理請求，則從所述多個服務器中選擇一個新的主服務器。
49.根據(jù)權(quán)利要求44的系統(tǒng)，其中所述主服務器適用于當所述主服務器接收到在沒有主服務器為其提供服務的客戶端會話中的請求時，從所述副服務器請求所述客戶端會話的會話信息，所述客戶端會話的信息被存儲在所述副服務器中。
50.根據(jù)權(quán)利要求44的系統(tǒng)，其中所述主服務器還適用于讀取與客戶端會話接收的請求相關(guān)的cookie，并且確定主服務器是否在為所述客戶端會話提供服務。
51.根據(jù)權(quán)利要求44的系統(tǒng)，其中所述硬件負載均衡器還適用于將請求批量地發(fā)送到所述主服務器。
52.一種用于在客戶端會話中提供備援的方法，包括a.對在客戶端會話中來自客戶端的初始請求做出負載均衡判斷，以便從多個會話服務器中選擇一個主服務器，所述負載均衡判斷是使用在硬件負載均衡器中的一個算法做出的；b.在主服務器中服務所述請求；c.使用主服務器來選擇副服務器；d.將該客戶端會話的會話信息從主服務器發(fā)送到副服務器；并且e.每次在客戶端會話中接收請求時，對主和副服務器上的會話信息進行更新。
53.根據(jù)權(quán)利要求52的方法，還包括步驟將信息存儲在客戶端的cookie中。
54.根據(jù)權(quán)利要求52的方法，還包括步驟如果主服務器不能處理所述請求，則使用硬件負載均衡器來選擇新的主服務器。
55.根據(jù)權(quán)利要求54的方法，還包括步驟在新的主服務器上服務請求。
56.根據(jù)權(quán)利要求54的方法，還包括步驟選擇一個新的副服務器。
57.根據(jù)權(quán)利要求52的方法，還包括步驟將請求批量地提供到主服務器。
58.根據(jù)權(quán)利要求52的方法，還包括步驟將該客戶端會話的會話信息從主服務器批量地發(fā)送到副服務器。
59.根據(jù)權(quán)利要求52的方法，還包括步驟響應請求，將版本號與對會話信息的每次更新相關(guān)聯(lián)。
60.根據(jù)權(quán)利要求52的方法，其中將該客戶端會話的會話信息從主服務器批量發(fā)送到副服務器，包括發(fā)送包含在會話信息中的變化的信息的增量。
61.根據(jù)權(quán)利要求52的方法，還包括給主和副服務器中的每個分配一個標識號碼。
62.根據(jù)權(quán)利要求52的方法，還包括將主服務器的標識號碼與副服務器的標識號碼相加，以便獲得描述主和副服務器兩者的一個號碼。
63.一種用于復制客戶端會話中的信息的系統(tǒng)，包括a.多個服務器；b.在所述多個服務器中的主服務器，所述主服務器適用于接收在客戶端會話中的請求，并且對該請求提供響應，所述主服務器還適用于存儲所述客戶端會話的會話信息，并且適用于產(chǎn)生包括有關(guān)所述主服務器的信息的cookie，并且將所述cookie發(fā)送到會話客戶端；c.在由所述主服務器選擇的在所述多個會話服務器中的副服務器，所述副服務器適用于從所述主服務器接收會話信息，并且存儲所述會話信息，所述副服務器還適用于接收在客戶端會話中的請求，并且對該請求提供響應；以及d.硬件負載均衡器，用于從客戶端接收請求，該請求包含所述主和副服務器的標識信息，所述硬件負載均衡器適用于處理標識信息，并且在所述主服務器上服務處理請求，如果所述主服務器不能處理請求，則硬件負載均衡器適用于在新主服務器上的服務該信息。
64.一種用于在客戶端會話中提供備援的方法，包括a.對在客戶端會話中來自客戶端的初始請求做出負載均衡判斷，以便從多個會話服務器中選擇一個主服務器，所述負載均衡判斷是使用在硬件負載均衡器中的一個算法做出的；b.在主服務器中服務所述請求；c.將該客戶端會話的會話信息從主服務器發(fā)送到由所述主服務器選擇的副服務器；d.將包含用于標識主和副服務器的信息的cookie存儲在會話客戶端；并且e.每次在客戶端會話中接收請求時，對主和副服務器上的會話信息進行更新。
65.根據(jù)權(quán)利要求64的方法，還包括步驟對于在客戶端會話中接收的請求，處理包含標識信息的cookie的段，并且在主服務器上服務請求。
66.一種用于復制在客戶端會話中的信息的系統(tǒng)，包括a.多個服務器；b.在所述多個服務器中的主服務器，所述主服務器適用于接收在客戶端會話中的請求，并且對分請求提供響應，所述主服務器還適用于存儲所述客戶端會話的會話信息，并且適用于產(chǎn)生包括有關(guān)所述主服務器的信息的cookie，并且將所述cookie發(fā)送到會話客戶端；c.在由所述主服務器選擇的所述多個會話服務器中的副服務器，所述副服務器適用于從所述主服務器接收會話信息，并且存儲所述會話信息，所述副服務器還適用于接收客戶端會話中的請求，并且對該請求提供響應；以及d.硬件負載均衡器，包含用于選擇所述主服務器的負載均衡邏輯，所述硬件負載均衡器適用于從客戶端接收初始請求，并且將所述請求指引到所述主服務器，所述硬件負載均衡器還適用于從客戶端接收隨后請求，該隨后請求包含所述主和副服務器的標識信息，該硬件負載均衡器適用于處理標識信息，并且在所述主服務器上服務處理請求，如果所述主服務器不能處理請求，則硬件負載均衡器適用于在新主服務器上服務請求。
67.一種用于在客戶端會話中提供備援的方法，包括a.對在客戶端會話中來自客戶端的初始請求做出負載均衡判斷，以便從多個會話服務器中選擇一個主服務器，所述負載均衡判斷是使用在硬件負載均衡器中的一個算法做出的；b.在主服務器中服務所述請求；c.將所述客戶端會話的會話信息從主服務器發(fā)送到由所述主服務器選擇的副服務器；d.將包含用于標識主和副服務器的信息的cookie存儲在會話客戶端；e.讀取與任何在客戶端會話中隨后請求接收的標識信息，并且在主服務器上服務所述隨后請求；并且f.每次對客戶端會話在主服務器上服務隨后請求時，對主和副服務器上的會話信息進行更新。
68.一種用于在客戶端會話中提供備援的方法，包括a.響應來自客戶端的初始請求，從多個服務器中選擇一個主服務器，該選擇步驟使用硬件負載均衡器中的負載均衡邏輯；b.在所述主服務器上服務所述請求，以便開始一個客戶端會話；c.選擇一個副服務器；d.將該客戶端會話的會話信息從主服務器發(fā)送到副服務器；并且e.每次在客戶端會話中接收請求時，對主和副服務器上的會話信息進行更新。
69.根據(jù)權(quán)利要求68的方法，還包括步驟將信息存儲在客戶端的cookie中。
70.根據(jù)權(quán)利要求68的方法，還包括步驟如果主服務器不能處理所述請求，則在新的主服務器上服務請求。
71.根據(jù)權(quán)利要求68的方法，還包括步驟使用硬件負載均衡器中的負載均衡邏輯來選擇一個新的主服務器；
72.根據(jù)權(quán)利要求68的方法，還包括步驟選擇一個新的副服務器。
73.根據(jù)權(quán)利要求68的方法，還包括步驟將請求批量地提供到主服務器。
74.根據(jù)權(quán)利要求68的方法，還包括步驟將所述客戶端會話的會話信息從主服務器批量地發(fā)送到副服務器。
全文摘要
一種會話復制系統(tǒng)(100)提供實時數(shù)據(jù)復制，而不必降低用戶的使用速度。根據(jù)本發(fā)明的系統(tǒng)可以使用主服務器(104)來服務來自網(wǎng)絡客戶端(102)的請求，以及副服務器(110)來復制會話信息。當在會話中接收到請求時，可以嘗試在主服務器(104)上服務所述請求。如果主服務器不能接收和響應所述請求，則在副應用服務器或在一個新的主服務器上服務所述請求。如果副服務器(110)接收所述請求，則副服務器可以成為新的主服務器。如果選擇了一個新的主服務器，則該新的主服務器可以從副服務器請求會話信息。
文檔編號H04L29/06GK1549978SQ02816897
公開日2004年11月24日 申請日期2002年7月15日 優(yōu)先權(quán)日2001年7月16日
發(fā)明者埃里克·M·哈爾彭, 普拉薩德·佩達達, 亞當·梅辛杰, 迪安·B·雅各布斯, 薩姆·普拉拉, B 雅各布斯, 埃里克 M 哈爾彭, 德 佩達達, 普拉拉, 梅辛杰 申請人:Bea系統(tǒng)公司