專利名稱：用于被復制的服務器的協(xié)議的制作方法
背景本發(fā)明涉及容錯服務器系統(tǒng)，具體地說，本發(fā)明涉及包括冗余服務器的容錯服務器系統(tǒng)。
可以使用容錯計算機或分布式體系結(jié)構(gòu)來實現(xiàn)遠程通信系統(tǒng)中的服務的高度可利用性。但是，使用這種冗余會對其它系統(tǒng)屬性產(chǎn)生負面影響。例如，使用硬件層次的冗余會增加成本、物理體積、能耗、出錯率等。這就不可能在一個系統(tǒng)內(nèi)使用多層冗余。
例如，分布式系統(tǒng)可包括計算機之間的復制，以便增強其堅固性。如果每個計算機均是容錯的，則成本就會加倍。此外，如果以軟件的方式保持備份拷貝，則為了能從軟件出錯中進行恢復，就分布式系統(tǒng)中的多個備份而言，額外存儲器的成本會隨著容錯硬件的成本而加倍。因此，為了保持低成本，建議避免使用多層冗余。由于這種結(jié)構(gòu)選擇的結(jié)果是僅使用一層冗余，故應選擇成盡可能地彌補多種錯誤和其它故障。
硬件出錯或軟件出錯會導致故障。硬件出錯的特征在于是永久的或者是暫時的。在每一種情況下，這類錯誤都可由容錯計算機來彌補。由于計算機硬件的快速發(fā)展，系統(tǒng)中集成電路和/或器件的總數(shù)會不斷地下降，每種集成電路和器件均會在可靠性方面不斷地改進?？傊斍坝布e誤不是系統(tǒng)故障的主要原因，并且，在將來更不會是這樣。因此，更難以證明需要用獨立的冗余即容錯計算機只去處理潛在的硬件錯誤。
就軟件錯誤而言，上述內(nèi)容也是不成立的。軟件的復雜性不斷增加，并且，對較短開發(fā)時間的要求會阻止在所有可能的配置、操作模式和類似的情況下對日益復雜化的軟件進行測試。較好的測試方法應該是充分地調(diào)試正常情況。就僅在非常特定偶然情況下出現(xiàn)的錯誤即所謂的“海森缺陷”(“Heisenbuggs”)而言，并不存在有可能或經(jīng)濟地執(zhí)行完全測試這樣的例外。相反，這種類型的錯誤需要由系統(tǒng)內(nèi)的冗余來彌補。
進程的松散連接復制幾乎可以彌補所有的硬件和軟件錯誤，包括暫時錯誤。作為一個實例，I.Lee和R.K.Iyer發(fā)表《IEEE軟件工程學報》1995年5月的Vo1.21，No.5中的“串行保護系統(tǒng)中的軟件可靠性”指出，盡管將設置檢查點設計到系統(tǒng)內(nèi)以彌補硬件錯誤，但設置檢查點(即將當前狀態(tài)拷貝至備用計算機)和重啟動(即通過例如讀出自最后一個檢查點以來出現(xiàn)的事務的日志而從最后一個檢查點狀態(tài)開始執(zhí)行，然后開始處理新的檢查點)在某些位置能彌補軟件錯誤的75％至96％。所述報告中的說明是，在測試期間未識別出的軟件錯誤是錯綜復雜的并且是由非常特殊的條件所觸發(fā)的。這些條件(例如存儲器狀態(tài)、時間、競爭條件等)在備份進程接管之后不會在該進程中重新出現(xiàn)，因此，軟件錯誤不會重新出現(xiàn)。
網(wǎng)絡中復制的問題在于，存在有諸如仲裁中心資源之類的少數(shù)服務，這些服務不適于分散。這種類型的服務必須在一個進程中加以實現(xiàn)并且就效率而言需要將其數(shù)據(jù)保持在堆棧內(nèi)。為了獲得冗余信息，必須在分布式網(wǎng)絡內(nèi)復制這種類型的進程。在高性能遠程通信控制系統(tǒng)中，必須用非常低的開銷并在不導致任何額外延遲的情況下進行這種復制。
依照本發(fā)明的一個方面，可在這樣一種容錯客戶機-服務器系統(tǒng)中實現(xiàn)上述和其它目的，所述系統(tǒng)包括主服務器、備份服務器和客戶機?？蛻魴C將請求發(fā)送給主服務器。主服務器接收并處理請求，包括以與主服務器所執(zhí)行的任何備份處理無關的方式將響應發(fā)送給客戶機，其中，所述響應包括主服務器的狀態(tài)信息。通過以與備份處理無關的方式發(fā)送響應，可以獲得較高層次的并發(fā)操作，從而使得系統(tǒng)更有效率。主服務器還執(zhí)行備份處理，包括周期性地將主服務器狀態(tài)信息發(fā)送給備份服務器?？蛻魴C接收來自主服務器的響應并將主服務器狀態(tài)信息從客戶機發(fā)送給備份處理器。
在本發(fā)明的另一個方面中，所述主服務器狀態(tài)信息包括自從最近將主服務器狀態(tài)信息從主服務器傳至備份服務器以來主服務器業(yè)已處理的所有請求-應答對。
在本發(fā)明的又一個方面中，所述主服器將主服務器狀態(tài)信息存儲在存儲裝置內(nèi)?？梢皂憫鎯ρb置被填加至預定量從而進行在主服務器中執(zhí)行備份處理的操作。
在又一個實施例中，可根據(jù)預定的時間間隔來周期性地進行在主服務器中執(zhí)行的備份處理操作。
詳細說明以下就附圖詳細說明本發(fā)明的各種特征，在附圖中，相類似的部分用相同的標號表示。


圖1是說明冗余服務器在客戶機-服務器應用中的用途的框圖。具體地說，示出了多個客戶機應用程序C。主服務器S101在第一處理器103上運行。獨立于第一處理器103的第二處理器105以與主服務器S101相并行的方式運行備份服務器S’107。一般地說，主服務器S101和備份服務器S’107在處理了任何來自客戶機應用程序C的特定請求之后出現(xiàn)的一個虛擬時刻T應具有相同的內(nèi)部狀態(tài)，因此，在其中的某一個出故障時，另一個可在沒有任何一個客戶機應用程序C注意到問題的情況下進行接管。(由于備份服務器S’107跟蹤主服務器S101，故備份服務器S’107會比主服務器S101更晚地實時地到達上述虛擬時刻)。被復制的服務器進程的存在對使用該服務器的客戶應用程序C來說應是不可見的。為了實現(xiàn)這種策略，需要解決下列問題尋址客戶應用程序C應在與主服務器S101或備份服務器S’107(或它們兩者)是否執(zhí)行該業(yè)務無關的情況下以一致的方式對服務器進行尋址。
復制與同步來自不同客戶應用程序C的輸入請求以及出錯和修復通知，會因為處理器之間物理網(wǎng)絡的不同而按不同次序到達主服務器S101和備份服務器S’107。然而，這些請求應該按照相同次序分類。
出錯和修復通知服務器進程出錯和新服務器進程的開始必須能由仍在工作的服務器檢測到。
狀態(tài)傳遞 當服務器進程在出錯之后重新開始時，正在工作的服務器必須在能開始處理請求之前將其內(nèi)部狀態(tài)傳給新的服務器。
在解決上述問題時，本發(fā)明的最佳實施例力圖達到下列目標--僅解決復制問題一次。實施復制具有多種缺陷并且檢驗起來很復雜。存在有必須加以彌補的多種可能的錯誤。
--僅增加低開銷并僅將這種開銷施加于與被復制的進程的通信。
--在正常操作下，在出故障時和在重整合新進程時，最壞情況的響應時間均應該是事先知道的并被保持于可接受的水平。
--不應將額外的消息添加給臨界的定時路徑。許多通常的實施技術都違背這一目標。例如，主服務器必須將消息發(fā)送給輔助服務器并在將應答發(fā)回客戶機之前取回一個應答。應該避免這點，從而使系統(tǒng)的實時響應時間不能因所增加的冗余而減慢。
--對多個客戶和動態(tài)客戶進行處理。遠程通信應用就一個服務器而言一般具有多個可能的客戶機。這就意味著不能使用例如在服務器進程出錯或恢復時必須對客戶機中的信息進行更新的算法。而且，客戶機進程一般具有短的壽命(它們僅在一個呼叫期間存在)。這就意味著不能使用需要服務器始終監(jiān)視客戶機的算法。
為了使得協(xié)議更為簡單，本發(fā)明的最佳實施例實施了幾條限制。通過使得協(xié)議更為一般化可很容易地提高這些限制中的某些限制。但是，它們所包含的內(nèi)容有利用說明所涉及的基本機理。這些限制是--僅涉及兩個服務器主服務器和備份服務器。本領域的技術人員將會看出，可使協(xié)議擴展成包括更多的內(nèi)容。
--一次容許一個錯誤，即一個客戶機或服務器出故障。所述系統(tǒng)必須在容許另一個錯誤之前進行恢復(例如通過啟動一次冷待機)。
--簡單的網(wǎng)絡配置。不考慮例如將網(wǎng)絡分解成兩個網(wǎng)絡、每個網(wǎng)絡中有服務器對中的一個的復雜網(wǎng)絡出錯情況。
--沒有大的消息。塊數(shù)據(jù)傳輸及類似的工作可能使緩沖區(qū)或隊列溢出。
--軟實時響應。在正常情況下(即在沒有任何出錯服務器的情況下)，就使用非復制服務器的系統(tǒng)而言，可以確保有大致相同的響應時間。但是，在出錯、恢復和重新集成時必須接受較長的響應時間。應該仍能保證這些較長的響應時間不超過預定的最大時間量。
--確定的服務器操作。正如將要更詳細地說明的那樣，備份服務器會接收到來自主服務器的周期性的更新消息。在備份服務器中對這些更新消息的處理必須是確定性的，以便保證能在發(fā)送更新消息時達到與主服務器相同的內(nèi)部狀態(tài)。服務器軟件不可以包括諸如調(diào)用時鐘(時鐘會根據(jù)被調(diào)用的時間的不同而返回不同結(jié)果)之類的不確定的系統(tǒng)調(diào)用，因為，這種調(diào)用會使備份服務器達到與主服務器不同的內(nèi)部狀態(tài)。
因此，備份服務器的狀態(tài)必須100％地由其從主服務器那里接收的信息所指定。這一點可通過以下兩種方式之一來獲得a)提供給主服務器的請求還被傳給備份服務器，然后，備份服務器通過對請求作相同的處理而達到與主服務器相同的狀態(tài)；或者b)將處理的結(jié)果(即主服務器所產(chǎn)生的對客戶機的應答以及服務器內(nèi)部狀態(tài)的變化)發(fā)送給備份服務器。
--僅有簡單的應用程序。在對后述的本發(fā)明協(xié)議的說明中，復制服務器不可以請求來自其它服務器的服務。協(xié)議必須能擴展，以便對這種情況進行處理。在一種這類擴展中，第二服務器能檢測到請求來自復制服務器并遵循相同(或相類似)的協(xié)議。
以上提出了需要加以解決的四個問題。以下說明本發(fā)明對這些問題之一的解決方案即復制與同步。在一個最佳實施例中，將復制和同步實現(xiàn)為在客戶機與服務器之間所使用的通信協(xié)議的一部分。這種方法的優(yōu)點是--在設計協(xié)議時僅實施一次。
--復制相對應用程序是隱藏的。協(xié)議可對復制服務器進行尋址。
本發(fā)明的協(xié)議設計成用于能有效地實現(xiàn)預定的復制和同步1)可以有兩種可選實現(xiàn)方式a)實現(xiàn)方式可以是所述通信方法的延伸。這就意味著對于主服務器中處理來自客戶機的請求不存在有額外的系統(tǒng)調(diào)用。
b)作為另一種方式，所述協(xié)議可包括在協(xié)議棧中。這就意味著可以進行更有效的實施。
用現(xiàn)有操作系統(tǒng)上的軟件層來實現(xiàn)容錯的所謂“中間件”方案得益于第一種可選方案(即可選方案“a”)但并不得益于第二種方案(即可選方案“b”)。
2)可在實時臨界循環(huán)之外進行服務器之間的復制，客戶機獲得應答的速度可以與主服務器S101響應的速度一樣快。
3)使將保持冗余所需的額外信息，附加到應答中以便使開銷最小。
4)周期性地對備份服務器S’107進行更新/監(jiān)聽，以便使開銷最小并能確保出錯之后的恢復時間不超過預定的最大值?？捎芍鞣掌鞯荒苡蓚浞莘嗥骷右蕴幚淼恼埱蟮臄?shù)量，將受到可在兩次周期性更新之間到達的請求的數(shù)量的限制。
5)可在I/O處理器中支持上述復制，以便使主處理器中根本沒有開銷。
所說的協(xié)議能保證被處理的請求以及與處理上述請求的次序有關的信息總是被保存在兩臺獨立計算機中的獨立位置處。這種策略基于以下兩種事實1)可以在比以通常方式進行的較晚一些時間生成主服務器狀態(tài)的冗余拷貝，而同時仍然保持容錯。也就是說，在通常的系統(tǒng)中，要在將應答發(fā)送給客戶機之前將服務器狀態(tài)信息從主服務器傳遞給備份服務器。但是，本發(fā)明認識到，這是一種保守的方法，因為，在將應答發(fā)送給客戶機之前，不會有其它處理器看到這種結(jié)果。因此，可認為在對請求進行處理之前主服務器業(yè)已出現(xiàn)了崩潰。這種情況持續(xù)至客戶機接收到應答時。對生成服務器狀態(tài)的冗余拷貝以便進行容錯來說，這是最后的可能時間。
2)包括有三種獨立的部分請求服務的客戶應用程序C、主服務器S101以及備份服務器S’107。在任何時間都足以將關鍵信息保存在兩個冗余拷貝內(nèi)。但是，這些拷貝不需要僅用主服務器S10’和備份服務器S’107來保存(如在通常的兩階段提交協(xié)議中那樣)。相反，客戶機也可用于(暫時)保存信息。
就簡單的服務器應用程序而言，復制是以圖2所示的消息流為基礎的?？蛻魬贸绦駽通過在客戶機處理器中運行的協(xié)議棧205來訪問主服務器101。配對的協(xié)議棧215、215’還在主服務器和備份服務器處理器PR01和PR02上運行。將請求201從客戶應用程序C傳紿主服務器S101。主服務器S101的協(xié)議棧215將一序列號與請求聯(lián)系起來，然后對該請求進行處理。作為對請求進行處理的結(jié)果，主服務器S101能生成一應答消息203并立即通過協(xié)議棧215將它發(fā)送給客戶應用程序C。依照本發(fā)明的一個方面，服務器的協(xié)議棧215可執(zhí)行這樣的附加功能將輸入的請求201存儲到一個隊列中，該隊列的內(nèi)容通過備份路徑209周期性地與備份服務器S’107的協(xié)議棧215’進行信息交流。依照本發(fā)明的又一個方面，供給客戶機C的應答消息203還包括這樣的信息，該信息指示在輸入的請求序列(自最后一次清除以來)中的一個什么樣的點處對客戶機的請求201進行了處理(即序列號)。
當客戶機的應用程序協(xié)議棧205接收到應答消息203時，該協(xié)議棧就做兩件事1)將應答消息203傳給客戶應用程序C；以及，2)將可能包含例如原始請求以及應答的消息207發(fā)送給備份服務器協(xié)議棧215’，所述備份服務器協(xié)議棧215’則將上述消息傳給備份服務器S’107。在某些實施例中，備份服務器的協(xié)議棧215’可以將確認消息211發(fā)送給客戶協(xié)議棧205，從而確認接收到了客戶的消息。
除了備份服務器接收來自客戶應用程序協(xié)議棧205的信息以外，不論主服務器協(xié)議棧205中的隊列何時達到了預定值或者當經(jīng)過了預定的時間量時，都通過備份路徑209將主服務器協(xié)議棧215中的隊列清除成與備份服務器S’107一致。除了將這種必要的冗余信息提供給備份服務器S’107以外，清除操作還起監(jiān)聽的作用，以便將主服務器S101仍處在激活狀態(tài)的指示給備份服務器S’107。清除/監(jiān)聽之間的時間可設定用于在出錯時進行恢復的最大時間。
備份服務器S’107在不能接收到來自主服務器S101的一個或多個監(jiān)聽信息時接管執(zhí)行權(quán)并開始接收來自客戶機C的請求。
應該被傳給備份服務器以便確保能進行恢復的信息是a)原始請求，以及b)被添加在應答消息內(nèi)的序列號。利用這種信息，備份可(在崩潰之后)對處于同樣次序(所述請求按該次序由主服務器來加以處理)的請求進行排序分類，然后，執(zhí)行同樣的處理過程。盡管就來自主服務器協(xié)議棧215的信息而言，序列號不太重要(因為一般可按進行處理的次序來傳遞輸入請求的拷貝)，但是，可將同樣的信息從客戶應用程序協(xié)議棧205和主服務器協(xié)議棧215傳給備份服務器S’107。
將整個的主服務器應答消息(包括序列號)傳給備份對備份服務器來說可以提高檢錯性能。除使用用來對消息次序進行排序的序列號以外，備份服務器S’107還可以通過比較自己的應答與來自主服務器S101的應答而驗證它是否與主服務器相同步。但是，應該注意，就這一目的而言，傳送這種信息的替代信息(例如應答的檢查和)就足夠了。
就檢錯而言，可從源(即通過客戶機C或通過來自主服務器S101的周期性更新值)或從這兩者傳遞完全的應答信息。在一個實施例中，僅通過來自主服務器協(xié)議棧215的周期性更新值來傳遞完全的應答信息，以便使必須通過客戶機的協(xié)議棧205經(jīng)由較長路徑的信息量達到最少。
還存在有以文本方式將序列信息添加給應答消息的多種替代形式。一種替代形式是僅添加處理請求的序列號。另一種替代形式是包括自最后一次周期性更新以來的整個請求序列。這些替代形式用于同樣的目的，并且，每種形式均可被認為是“服務器狀態(tài)信息”，因為，每種形式都限定了備份服務器S’107必須采取的操作的次序，以便獲得與主服務器S101的狀態(tài)相同的狀態(tài)。
以下說明出錯的情況以及本發(fā)明如何對它們進行處理。在應答發(fā)送之前主服務器崩潰在這種情況下，客戶機C不會接收到來自主服務器S101的確認信息(即應答消息203)。作為響應，客戶機C的協(xié)議棧205將原始請求201重新傳送給主服務器S101和輔助服務器S’107。否則(即在無錯狀態(tài)下)，客戶應用程序C僅將請求發(fā)送給主服務器S101。(應該注意，客戶應用程序通常不知道與容錯有關的活動，因為，它僅對單個的邏輯服務器進行尋址?？蛻魴C處理器中的協(xié)議棧205管理地址翻譯以及與兩個服務器S101和S’107之間的通信。)如果輔助服務器S’107錯過了來自主服務器S101的監(jiān)聽信息，則它就進行接管。否則，它就簡單地丟棄從自客戶機C接收的請求。在發(fā)送應答之后但在將信息清除到備份之前主服務器崩潰可以從客戶機的協(xié)議棧205所提供的更新消息中檢索出這樣的信息，該信息是將備份服務器S’107更新成發(fā)送最后一次應答時存在的狀態(tài)所需要的。從主服務器S101到客戶機C的“應答路徑”中的消息包含對客戶應用程序的應答以及對備份服務器S’107的更新信息?？蛻魬贸绦騼H需要接收來自客戶機C的應答信息而不是附加的更新信息。如圖2所示，(通過備份服務器的協(xié)議棧215’)將更新信息從客戶機協(xié)議棧205傳給備份服務器S’107。這種更新信息是備份服務器S’107在另外的情況下借助于由主服務器S101直接傳送的周期性更新值而接收到的同樣信息。在已存在的消息中增加某些額外信息的成本與必須為其發(fā)送額外消息相比是較小的。在發(fā)送初始請求之后客戶機崩潰在這種情況下，在主服務器清除其隊列時，備份服務器S’107接收用于更新自身的信息。主系統(tǒng)崩潰主服務器S101以及在同一處理器103中執(zhí)行的任何客戶機都將丟失。備份服務器S’107執(zhí)行來自上次被清除的隊列中的其余命令，然后對正在主服務器處理器103之外執(zhí)行的客戶機一直進行更新到在上一次應答給出的那個點。消息丟失在認為接收處理(或處理器)出錯之前，重新傳送未獲得立即確認的消息一次或兩次。
以下參照圖3詳細說明客戶機的協(xié)議棧205。在步驟301，客戶應用程序的執(zhí)行會使得請求被發(fā)送給主服務器。在步驟302，在協(xié)議棧205中處理請求，并將請求發(fā)送給主服務器。所述協(xié)議在消息丟失時實施重新傳送，并且，為做到這一點而保持消息的拷貝。在步驟303，應答業(yè)已返回自主服務器。將應答沒有延遲地發(fā)送回客戶應用程序過程。為復制的協(xié)議保持請求及相關應答的拷貝。因為，在該例中，假定主服務器較快地進行響應，所以，不存在從主服務器發(fā)送至客戶機的獨立確認信息。也就是說，自主服務器返回的應答足以起應答的作用。在包括較慢主服務器的其它實施例中，協(xié)議必須包括獨立的確認信息，這種確認信息總是在傳送應答前從主服務器發(fā)送給客戶機。
在步驟304，應用程序過程可在不等待實行復制的情況下繼續(xù)執(zhí)行。在步驟305，協(xié)議棧205將請求及應答存儲在一個為尚未被復制給備份服務器的請求所設計的隊列內(nèi)。
在步驟306，客戶機將包含原始請求和應答的消息發(fā)送給備份服務器。作為響應，備份服務器將一個確認(步驟307)返回給客戶機，以便確認安全地接收了客戶機的消息。應該注意，在沒有該確認信息的情況下，客戶機沒有知道業(yè)已接收到了消息的其它方法，因為，沒有來自備份服務器的其它應答。
以前提及了多個其它問題，即出錯和修復通告以及狀態(tài)傳遞。以下說明本發(fā)明對這些問題的解決方案。
就出錯和修復通告而言，主、輔助服務器之間的通信還起監(jiān)聽的作用。如果輔助服務器未被規(guī)則地更新，則輔助服務器會等待足夠長的時間去接收任何顯著的客戶機超時，然后進行接管。在服務器過程重新開始時，該過程就檢查是否存在有激活的主服務器。
就狀態(tài)傳遞而言，它在重啟動出錯了的服務器時使用。在執(zhí)行服務器能像主/備份對那樣工作之前，它們的狀態(tài)必須被拷貝成重啟動的狀態(tài)。在這種狀態(tài)傳遞與進行系統(tǒng)軟件和硬件升級時所需的狀態(tài)傳遞類型之間沒有根本的差異。而且，由于現(xiàn)代處理器有很少量的硬件故障，狀態(tài)傳遞機制應該針對系統(tǒng)升級被最佳化。
我們記得，本發(fā)明的一個方面是這樣的要求即即使來自不同客戶機的請求以及出錯和修復通告可在主和備份服務器S101和S’107中按不同的次序到達，但必須按同樣的次序?qū)λ鼈冞M行排序。因此，在某些實施例中，提供用于實施消息之間的因果相關關系(也稱為“因果次序關系”)的機制是有益的。這基本上涉及按符合邏輯地發(fā)送出消息的次序而不是按接收消息的嚴格次序來對消息進行處理。對因果次序關系更完整的說明可以連同對ISIS工具包的說明一起得到，ISIS工具包是由美國紐約Ithaca的Cornell大學開發(fā)的。IEEE計算機學會出版社1994年出版的ISBN 0-8186-5342-6的K.P.Birman和R.van Renesse所著《用ISIS工具包進行可靠的分布式計算》中有上述說明?？捎玫烷_銷來實現(xiàn)因果次序關系，并且，因果次序關系可通過允許較高度的并發(fā)性來改進系統(tǒng)效率。圖4a和4b說明了這種效率的提高。在圖4a中，處理器Pro1將對資源的請求發(fā)送給資源處理器Pro2(步驟401)。在不支持底層系統(tǒng)中因果次序關系的情況下，Pro2必須將消息發(fā)送給資源Pro3，以便對其進行初始化(步驟402)。在業(yè)已應答資源準備好了之后(步驟403)，允許Pro2將一應答發(fā)送給Pro1，以便通知它資源是可用的(步驟404)。處理器Pro1可將一消息發(fā)送給資源Pro3(步驟405)。應該注意，各處理器的行為要受到一些限制，這些限制被設計成要阻止一個處理器在接收先前發(fā)送的消息之前接收(從而處理)以后發(fā)送的消息。
參照圖4b，該圖說明了其中底層系統(tǒng)支持因果次序關系的實例。該實例始于處理器Pro1將對資源的請求發(fā)送給資源處理器Pro2(步驟406)?，F(xiàn)在，資源處理器Pro2不需要等待來自Pro3的應答。相反，它立即將一應答發(fā)送給Pro1，以便通知資源是可用的(步驟407)。在大約同樣的時刻，Pro2將一消息發(fā)送給資源Pro3，以便對其初始化(步驟408)。由于有這種并發(fā)性，故處理器Pro1能比所述的沒有因果次序關系的實例(圖4a)更快地將其消息發(fā)送給資源Pro3(步驟409)。這并不會產(chǎn)生任何問題，因為，即使來自Pro2的消息有所延遲，因果消息次序關系也能確保Pro3會在接收到來自Pro1的消息之前處理初始化消息(另外的步驟408’)。
對于客戶機調(diào)用復制服務器的受限情況而言，不一定要實現(xiàn)完全的因果次序關系模型，因為，在這種情況下，序列號足以使得復制服務器按適當?shù)拇涡驅(qū)φ埱筮M行處理。但是，在將協(xié)議擴展至更普遍的情況(例如允許復制服務器調(diào)用另一個復制服務器)時，就需要調(diào)用上述完全的模型。
業(yè)已參照具體實施例說明了本發(fā)明，但是，本專業(yè)的技術人員很容易注意到，可按除上述最佳實施例以外的具體形式來實施本發(fā)明?？稍诓幻撾x本發(fā)明精神的情況下做到這一點。上述最佳實施例僅僅是說明性的，無論如何都不應認為是限制性的。應該由后附的而不是由前面的說明來給出了本發(fā)明的范圍，本文包括了屬于權(quán)利要求范圍內(nèi)的所有變化形式和等同形式。
權(quán)利要求
1.一種容錯客戶機-服務器系統(tǒng)，所述系統(tǒng)包括主服務器；備份服務器；以及客戶機；其中所述客戶機包括用于將請求發(fā)送給主服務器的裝置；用于接收來自主服務器的響應的裝置，其中該響應包括主服務器狀態(tài)信息；用于將主服務器狀態(tài)信息發(fā)送給備份服務器的裝置；所述主服務器包括用于接收并處理請求的裝置；用于響應上述請求、以與任何備份處理無關的方式將響應發(fā)送給客戶機的裝置；其中，所述響應包括主服務器的狀態(tài)信息；用于執(zhí)行備份處理的裝置，所述備份處理包括周期性地將主服務器狀態(tài)信息發(fā)送給備份服務器；以及所述備份服務器包括用于接收來自主服務器的主服務器狀態(tài)信息的裝置；用于接收來自客戶機的主服務器狀態(tài)信息的裝置。
2.如權(quán)利要求1的容錯客戶機-服務器系統(tǒng)，其特征在于，所述主服務器狀態(tài)信息包括自從最近將主服務器狀態(tài)信息從主服務器傳給備份服務器以來主服務器業(yè)已處理的所有請求-應答對。
3.如權(quán)利要求1的容錯客戶機-服務器系統(tǒng)，其特征在于，所述主服務器狀態(tài)信息包括從一個應答中得出的檢查和。
4.如權(quán)利要求1的容錯客戶機-服務器系統(tǒng)，其特征在于，根據(jù)預定的時間間隔周期性地啟動所述主服務器的用于執(zhí)行備份處理的裝置。
5.如權(quán)利要求1的容錯客戶機-服務器系統(tǒng)，其特征在于所述主服務器還包括用于將主服務器狀態(tài)信息存儲起來的裝置；以及主服務器中的用于執(zhí)行備份處理的裝置響應于用于存儲主服務器狀態(tài)信息的裝置被填加至預定量而被啟動。
6.一種操作容錯客戶機-服務器系統(tǒng)的方法，所述系統(tǒng)包括主服務器、備份服務器以及客戶機；所述方法包括下列步驟將來自客戶機的請求發(fā)送給主服務器；在主服務器中，接收并處理上述請求，包括以與主服務器所執(zhí)行的任何備份處理無關的方式將響應發(fā)送給客戶機，其中，所述響應包括主服務器的狀態(tài)信息；在主服務器中執(zhí)行備份處理，包括周期性地將主服務器狀態(tài)信息發(fā)送給備份服務器；在客戶機中接收來自主服務器的響應；以及將主服務器狀態(tài)信息從客戶機發(fā)送給備份處理器。
7.如權(quán)利要求6的方法，其特征在于，所述主服務器狀態(tài)信息包括自從最近將主服務器狀態(tài)信息從主服務器傳至備份服務器以來主服務器業(yè)已處理的所有請求-應答對。
8.如權(quán)利要求6的方法，其特征在于，所述主服務器狀態(tài)信息包括從一個應答中得出的檢查和。
9.如權(quán)利要求6的方法，其特征在于，根據(jù)預定的時間間隔周期性地執(zhí)行主服務器中所述用于執(zhí)行備份處理的步驟。
10.如權(quán)利要求6的方法，其特征在于所述主服務器還執(zhí)行所述將主服務器狀態(tài)信息存儲在存儲裝置內(nèi)的步驟；響應于存儲裝置被填加至預定量而進行在主服務器中所述用于執(zhí)行備份處理的步驟。
全文摘要
一種容錯客戶機－服務器系統(tǒng)包括主服務器、備份服務器和客戶機?？蛻魴C將請求發(fā)送給主服務器,主服務器接收并處理請求,其中包括以與任何備份處理無關的方式將響應發(fā)送給客戶機。所述響應包括主服務器的狀態(tài)信息。主服務器還執(zhí)行備份處理,備份處理包括周期性地將主服務器狀態(tài)信息發(fā)送給備份服務器?？蛻魴C接收來自主服務器的響應并將主服務器狀態(tài)信息發(fā)送給備份服務器。所述主服務器狀態(tài)信息包括自從最近將主服務器狀態(tài)信息從主服務器傳至備份服務器以來主服務器業(yè)已處理的所有請求－應答對?？筛鶕?jù)預定的時間間隔周期性地啟動主服務器中的用于執(zhí)行備份處理的裝置。另外,可在主服務器中的用于存儲主服務器狀態(tài)信息的存儲器被填加至預定量時啟動上述用于執(zhí)行備份處理的裝置。
文檔編號G06F12/00GK1342280SQ99813680
公開日2002年3月27日 申請日期1999年9月23日 優(yōu)先權(quán)日1998年9月24日
發(fā)明者P·A·霍爾姆貝里 申請人:艾利森電話股份有限公司