專利名稱：一種基于消息日志的容錯集群系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計算機領(lǐng)域中容錯集群系統(tǒng)及方法，尤其為不具有可靠存 儲設(shè)備和備用計算節(jié)點的集群環(huán)境提供基于消息日志的高效容錯系統(tǒng)及方 法。
背景技術(shù)：
隨著網(wǎng)絡(luò)和計算技術(shù)的迅猛發(fā)展，網(wǎng)絡(luò)業(yè)務(wù)與應(yīng)用服務(wù)變得越來越復(fù) 雜龐大，使得集群系統(tǒng)得到了廣泛地應(yīng)用。這些集群系統(tǒng)中往往包含了眾 多的計算節(jié)點，非常容易遭受頻繁的局部故障，在沒有容錯方法的情況下， 集群系統(tǒng)很難保證長時間的正常運行。對進程狀態(tài)和進程間通信消息加以 保存是一種有效的容錯手段，集群系統(tǒng)遇到故障時，通過調(diào)用先前保存的 檢查點和消息日志可以幫助進程恢復(fù)到它在故障前所處的狀態(tài)。在基于消 息日志的容錯方法中，進程除了按一定策略設(shè)置包含進程狀態(tài)的檢查點外， 還要將進程間的通信消息以日志的形式保存到可靠存儲介質(zhì)上。在故障恢 復(fù)過程中，進程首先回巻到檢查點狀態(tài)，然后利用消息日志進行重演。根據(jù)消息日志被保存到穩(wěn)定存儲上的頻率，目前公開的基于消息日志 的容錯方法主要有三類第一類是悲觀消息日志，它假定任何非確定事件 之后都可能發(fā)生故障，最直接的實現(xiàn)方式就是在事件影響進程狀態(tài)前，將 事件的日志信息保存到穩(wěn)定存儲上，這保證了系統(tǒng)可以很容易地從任何時 刻的故障中恢復(fù)。悲觀消息日志有兩個主要優(yōu)勢 一是不會產(chǎn)生孤立進程， 二是消息日志和檢査點的垃圾收集算法非常簡單，然而悲觀日志會導(dǎo)致很 高的系統(tǒng)開銷。第二類樂觀消息日志先將事件的日志信息臨時記錄在易失 的內(nèi)存中，然后周期性地存放到穩(wěn)定存儲上。盡管這可以顯著減少了系統(tǒng) 無故障運行開銷，但它需要復(fù)雜的恢復(fù)和垃圾收集算法。同時，還可能會 由于孤立進程而產(chǎn)生無邊界回巻問題。第三類因果消息日志方法結(jié)合了前 兩類方法的優(yōu)點。它具有較低的無故障運行開銷，同時也限制了失效回巻 的程度，并保證進程回巻到最近的檢查點狀態(tài)。然而這些優(yōu)勢的獲得是以 復(fù)雜的恢復(fù)步驟為代價的。以上所述的容錯方法雖然各有特色，但都是基于目前集群系統(tǒng)中大多
包含冗余設(shè)備，比如專門用于保存檢查點和消息日志的穩(wěn)定存儲設(shè)備；用 于代替失效計算節(jié)點的備用節(jié)點等。而在實際情況中，很多集群系統(tǒng)往往 資源有限，難以提供額外設(shè)備，這使得上述的方法無法為這些系統(tǒng)提供容 錯功能。另一方面，在目前的集群系統(tǒng)中，保存檢査點和消息日志會頻繁 地對外部存儲設(shè)備進行讀寫，這會大大增加系統(tǒng)的無故障開銷。而且，在 故障出現(xiàn)后，新的計算節(jié)點重新啟動失效進程，也會影響系統(tǒng)性能，增加 故障恢復(fù)時間。發(fā)明內(nèi)容本發(fā)明解決的技術(shù)問題是克服目前基于消息日志的容錯方法過分依賴 集群系統(tǒng)中擁有額外存儲設(shè)備或計算節(jié)點的缺陷，并解決由于讀寫外部存 儲設(shè)備和重啟失效進程所導(dǎo)致的系統(tǒng)性能開銷問題，提出了一種基于消息 日志的容錯集群系統(tǒng)和方法。本發(fā)明提出的基于消息日志的容錯集群系統(tǒng)，包括多個計算節(jié)點，每 個計算節(jié)點上運行著多個應(yīng)用進程，每個應(yīng)用進程都對應(yīng)設(shè)有至少一個備 用進程，且備用進程與其對應(yīng)的應(yīng)用進程不在一個計算節(jié)點上；各應(yīng)用進 程及其備用進程均記錄有該應(yīng)用進程所發(fā)送消息的消息日志，備用進程用于 在計算節(jié)點發(fā)生故障時通過激活消息日志取代應(yīng)用進程。優(yōu)選的，所述應(yīng)用進程和備用進程中還設(shè)有用于記錄給其它進程發(fā)送 消息的最大發(fā)送序列號列表，以及用于記錄從其它進程接收消息的接收序 列號列表。優(yōu)選的，所述的最大發(fā)送序列號列表、接收序列號列表、進程所發(fā)送 消息的消息日志保存在進程所屬計算節(jié)點的主存中。本發(fā)明提出的基于消息日志的容錯方法，包括以下處理過程1) 設(shè)定檢查點，應(yīng)用進程將其狀態(tài)保存到檢查點中，并將檢査點信息同步到備用進程；2) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送消息，并對發(fā)送的消息以消息日 志的方式保持到發(fā)送應(yīng)用進程和接收應(yīng)用進程中；3)當計算節(jié)點發(fā)生故障，計算節(jié)點中失效的應(yīng)用進程對應(yīng)的備用進程 通過保存的檢查點和消息日志激活，并取代應(yīng)用進程的工作。優(yōu)選的，所述步驟l)中具體包括以下處理過程11) 設(shè)定檢査點，應(yīng)用進程將其狀態(tài)保存到檢査點中，并將檢査點信息給其備用進程；12) 備用進程收到檢查點信息后，用新的檢查點信息替代舊的檢查點信息，并向應(yīng)用進程反饋確認信息。優(yōu)選的，所述步驟12)之后還包括以下處理步驟13) 應(yīng)用進程通過向更新檢查點前所有與其有消息交互的應(yīng)用進程以及其備份進程發(fā)送垃圾收集信息，收到垃圾收集信息的進程根據(jù)信息內(nèi)容 刪除消息日志中的歷史垃圾消息。優(yōu)選的，所述步驟2)具體包括以下處理過程21) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送帶有消息發(fā)送序列號的通信請求；22) 接收應(yīng)用進程收到請求后，根據(jù)請求中帶有的消息發(fā)送序列號在 接收應(yīng)用進程的消息日志中査詢，對于確認該消息沒有收到過，則為待接 收的消息分配接收序列號，并向發(fā)送應(yīng)用進程反饋；23) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送消息。 優(yōu)選的，所述步驟23)具體為 當發(fā)送應(yīng)用進程與接收應(yīng)用進程在同一計算節(jié)點時，231) 發(fā)送應(yīng)用進程將消息、發(fā)送序列號、接收序列號發(fā)送到發(fā)送應(yīng)用 進程的備份進程；232) 發(fā)送應(yīng)用進程的備份進程收到消息后，將內(nèi)容保存到其消息日志 中，并向發(fā)送應(yīng)用進程發(fā)送確認信息；233) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送消息； 當發(fā)送應(yīng)用進程與接收應(yīng)用進程在不同的計算節(jié)點時，234) 發(fā)送應(yīng)用進程將待發(fā)送消息、接收序列號保存在其消息日志中；235) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送消息。 優(yōu)選的，所述步驟3)具體包括以下處理過程31) 當計算節(jié)點發(fā)生故障，計算節(jié)點中失效的應(yīng)用進程對應(yīng)的備用進 程通過保存的檢査點和消息日志激活，并向其它應(yīng)用進程發(fā)送廣播消息；32) 其它應(yīng)用進程收到廣播消息后，向備用進程發(fā)送之前已發(fā)送給失 效的應(yīng)用進程的消息，并附有各消息的接收序列號和最大接收序列號；33) 被激活的備份進程從收到的接收序列號中找到最大值，開始重新 分配接收序列號，完成取代應(yīng)用進程的工作。本發(fā)明利用備份進程保存檢査點和消息日志，同時，通過將它們記錄 到消息發(fā)送者側(cè)的內(nèi)存中避免同步日志記錄產(chǎn)生的系統(tǒng)開銷。這不僅減小 了記錄日志的費用，還取消了對穩(wěn)定存儲介質(zhì)的依賴。本發(fā)明不需要任何 保存檢査點和日志的可靠存儲設(shè)備，在恢復(fù)期間，也不會依賴額外備用的 計算節(jié)點去接替失效節(jié)點，進程無需重新啟動就會繼續(xù)運行在剩余的節(jié)點 上。同時，系統(tǒng)還可以方便地增加負載均衡功能，有效降低節(jié)點失效對整 個系統(tǒng)的影響。


圖1為本發(fā)明實現(xiàn)容錯功能的集群系統(tǒng)結(jié)構(gòu)原理圖；圖2為本發(fā)明實現(xiàn)進程檢查點保存的流程圖；圖3為本發(fā)明實現(xiàn)進程間通信的流程圖；圖4為本發(fā)明實現(xiàn)同一節(jié)點進程間通信消息保存的流程圖；圖5為本發(fā)明實現(xiàn)不同節(jié)點進程間通信消息保存的流程圖。
具體實施方式
下面結(jié)合附圖對本發(fā)明技術(shù)方案的實施作進一步的詳細描述。 圖l為本發(fā)明實現(xiàn)容錯功能的集群系統(tǒng)結(jié)構(gòu)圖。其中 有m個進程運行在含有n個計算節(jié)點的集群系統(tǒng)中，計算節(jié)點故障均 為失效停止，當一個節(jié)點失效時，其它的節(jié)點能夠立即檢測到它的失效。 節(jié)點上運行的進程可以被描述為一個二元組P=(pm，bk)， pm和bk分別表 示該進程的主版本和副版本。由于本發(fā)明的實施例中每個進程僅含有一個 相應(yīng)的副本，所以容錯模型只允許單點失效，若使用更多的進程副本，該 模型可以擴展到多點失效。本發(fā)明的容錯方法完全基于軟件，不依賴于任
何特殊的硬件。系統(tǒng)中沒有完全可靠的設(shè)備，節(jié)點間的通信都是通過網(wǎng)絡(luò)消息傳遞；網(wǎng)絡(luò)是可靠的；分段確定性(PWD， Piece Wise Deterministic) 假設(shè)也被保留，它假設(shè)消息接收是影響進程狀態(tài)唯一不確定事件。本發(fā)明的實現(xiàn)需要向系統(tǒng)中每一個進程增加一些數(shù)據(jù)模塊，在了解這 些數(shù)據(jù)模塊之前，首先認識兩個數(shù)據(jù)項發(fā)送序列號(SSN， Send Sequence Number)-進程發(fā)送的每一條消息都有一個發(fā)送序列號，記錄了當前發(fā)送者 發(fā)給接收者消息的數(shù)目；接收序列號(RSN， Receive Sequence Number)-接收進程會為其接收到的每一條消息分配一個RSN，并按照RSN的遞增順 序處理消息?；谏鲜龅臄?shù)據(jù)項，在進程中定義了以下數(shù)據(jù)模塊進程所發(fā)送消息的消息日志進程發(fā)送的每一條消息連同消息的RSN 號都被記錄在一個消息日志中。如果消息在相同處理器上兩個進程間發(fā)送， 它們將被記錄在發(fā)送進程副版本的消息日志中。記錄最大SSN列表每個進程都維護了一個發(fā)送給其它進程最大SSN 的列表，稱之為SSNTable，它還維護了一個從不同進程接收的SSN滑動窗 口，這被用于復(fù)制消息檢測。維護RSN值的列表: 一個進程維護一個自從最近檢查點后已分配的RSN 列表，可以通過發(fā)送者和SSN號檢索對應(yīng)的消息是否已被接收，RSN列表 中還包含已分配的最大RSN號Rcount。除了最新的值，這些數(shù)據(jù)模塊必須要包含在進程的檢查點中，當進程 從其檢查點重啟時，它們的值也將隨著檢查點數(shù)據(jù)恢復(fù)。如圖2所示，進程P周期性地決定將它的狀態(tài)保存到檢查點中，并將 檢查點發(fā)送給它的備份進程P. bk。每一個主進程還記錄它已經(jīng)處理的最大 RSN的消息，保存發(fā)送給不同主進程的RSN列表將通過移除對應(yīng)消息的入 口被垃圾收集。當接收到檢査點后，P.bk將用新的檢査點替換舊的檢査點拷貝，然后 發(fā)送一個確認消息給P. pm。接收到確認后，P. pm會發(fā)送一個包含最高RSN 的垃圾收集消息給最新檢査點前所有發(fā)送給它消息的進程，當進程Q.pm 收到來自P. pm的垃圾收集消息后，Q. pm將刪除消息日志中所有發(fā)送給P. pm 且RSN小于消息中指定RSN的消息。同時，P.pm發(fā)送另一條相似的垃圾收 集消息給它的備份進程P.bk，用以刪除本地消息日志中舊的記錄。在決定檢査點周期的問題上，內(nèi)存和速度之間存在一個有趣的平衡 如果檢査點周期過小，記錄在發(fā)送者上的消息將占用比較小的內(nèi)存，但保 存檢查點的開銷將比較大。如果檢査點周期過大，記錄在發(fā)送者上的消息 將變多而檢査點的開銷將變小。而且，稀少的檢査點將由于需要重發(fā)的舊 消息過多而使恢復(fù)變慢。所以在決定檢查點周期中預(yù)期的故障數(shù)目也是重 要的因素，而且一些應(yīng)用可能有內(nèi)存限制，所以檢查點周期可能作為用戶 輸入設(shè)置或者動態(tài)決定，針對檢査點的需求驅(qū)動策略也可能被應(yīng)用。不像其它基于消息日志的容錯方法，本發(fā)明不依賴于多個保存檢査點 的可靠服務(wù)器。取而代之的是依賴進程的主副版本不會在同一個檢查點周 期內(nèi)出現(xiàn)故障。圖3表現(xiàn)了進程P發(fā)送消息給進程Q必須要執(zhí)行的步驟。如圖所示， 兩個進程在進行通信的過程中，會根據(jù)相互位置的不同而采取不同的方式 保存消息日志。本地進程間消息發(fā)送虛擬化意味著多個進程可能被映射到相同計算 節(jié)點上，相同節(jié)點上的進程可以被看作互為本地。發(fā)送給本地進程的消息 日志和接收者在相同的節(jié)點上，如果節(jié)點失效，消息的所有信息都將從系 統(tǒng)中消失，盡管消息可以被恢復(fù)的發(fā)送者重新生成，但是它還需要被接收 者準確地按照先前的順序處理，由于發(fā)送者和順序號可以唯一確定一條消息，所以只要記錄發(fā)送者進程序列號、消息的SSN和RSN，就可以滿足正 確性的需要。來自于本地進程P的RSN(m)可以通過下列方法獲得帶有RSN的本地 消息被發(fā)送給發(fā)送者備份進程保存，只有在收到自己備份進程確認后才開 始該消息的處理工作，發(fā)送本地消息的消息交換序列如圖4所示，由于在 遠端節(jié)點上記錄日志，本地進程間消息延時與遠端進程間消息延時相同。等待備份進程確認并不意味著進程執(zhí)行的實際停止，而是進程記著它 正在等待特定的消息繼續(xù)執(zhí)行，無論等待的消息何時到達，消息發(fā)送協(xié)議 都將假設(shè)處于等待狀態(tài)，這在下面所有的算法中都是正確的。遠端進程間消息發(fā)送在不同節(jié)點上的兩個進程被稱為相互遠端，在 這種情況下，進程間通信按照遠端消息發(fā)送步驟模式執(zhí)行，消息發(fā)送的流 程如圖5所示。進程P記錄消息并發(fā)送入場券請求并等待回復(fù)。當進程Q接收到帶有 特定SSN的入場券請求，它將查詢包含RSN列表的〈sender， SSN〉項，如果 發(fā)現(xiàn)SSN已存在，則返回列表中存儲的值，如果發(fā)現(xiàn)對應(yīng)SSN的消息已收 到，而且在最近的檢査點以后，則標記RSN為已收到；如果發(fā)現(xiàn)消息在最近的檢查點前收到，則標記RSN是舊的。如果以上的情況沒有一個滿足， 將意味著這是一個新消息的請求。它將增加Rcount值并返回RSN給P，同 時在列表中增加相應(yīng)發(fā)送者，SSN和RSN的數(shù)據(jù)項。標記為已接收的RSN意味著消息不需要發(fā)送給接收者，除非它被重啟。 對應(yīng)于標記舊RSN的消息可以不需要記錄，發(fā)送者只需簡單地在它的日志 中添加RSN即可。如果RSN是新的，它將分配給日志中對應(yīng)的消息，并將 該消息發(fā)送給接收者，RSN表還可以處理發(fā)送者P重發(fā)一個入場券請求的 情況，如果Q已經(jīng)為這個請求派發(fā)了 RSN, Q將永遠不會收到帶有舊RSN 的消息。消息按照RSN遞增順序被處理，雖然這會延長Q在舊RSN上的執(zhí) 行時間，然而卻可以避免為新的SSN分配舊的RSN。當P開始發(fā)送消息m 到Q處理m之間會有一個時間差，這個時間差由一個小消息往返時間所決 定。由于失效的計算節(jié)點上可能存在多個進程，所以，容錯方法中更需要 恢復(fù)步驟。以下是本發(fā)明在進程恢復(fù)中所涉及到的步驟。失效探測器檢測到有計算節(jié)點失效后，立刻通知失效主進程的備份進 程，備份進程會通過最近的檢查點和本地消息日志激活，并從檢查點位置 開始繼續(xù)執(zhí)行，以接管主進程的工作，激活完畢后備份進程會廣播消息表 示它已經(jīng)準備好接收被記錄的日志。作為對廣播的回應(yīng)，所有的主進程都 將重發(fā)附有RSN的日志消息給被激活的備份進程。對于沒有RSN的日志消 息，入場券請求將會發(fā)送。每個主進程還會發(fā)送一個包含它所收到的來自 該備份進程主版本最高的RSN號消息，同時，被激活的備份進程會拒絕任 何它接收到的重復(fù)消息。 一旦被激活的備份進程知道它的主版本在崩潰前 所派發(fā)的最大RSN，它會開始重新派發(fā)RSN。在恢復(fù)期間如果一個本地消息 被生成，來自備份進程的本地消息日志將被用于找到RSN。針對集群系統(tǒng)的容錯需求，本發(fā)明提出了一種基于消息日志的容錯集 群系統(tǒng)和方法。與其它的容錯方法不同，本發(fā)明不依賴于任何完全可靠的 存儲設(shè)備，允許在沒有額外節(jié)點替代的情況下，當小部分節(jié)點失效時，進 程無需重新啟動就可繼續(xù)執(zhí)行。本發(fā)明具有較低的系統(tǒng)開銷和快速的錯誤 恢復(fù)性能，有力地保證了集群計算業(yè)務(wù)不中斷。以上內(nèi)容是結(jié)合具體的優(yōu)選實施方式對本發(fā)明所作的進一步詳細說 明，不能認定本發(fā)明的具體實施只局限于這些說明。對于本發(fā)明所屬技術(shù) 領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明構(gòu)思的前提下，還可以做出若 干簡單推演或替換，都應(yīng)當視為屬于本發(fā)明的保護范圍。
權(quán)利要求
1. 一種基于消息日志的容錯集群系統(tǒng)，其特征在于，所述集群系統(tǒng)包 括多個計算節(jié)點，每個計算節(jié)點上運行著多個應(yīng)用進程，每個應(yīng)用進程都 對應(yīng)設(shè)有至少一個備用進程，且備用進程與其對應(yīng)的應(yīng)用進程不在一個計 算節(jié)點上；各應(yīng)用進程及其備用進程均記錄有該應(yīng)用進程所發(fā)送消息的消息 曰志，備用進程用于在計算節(jié)點發(fā)生故障時通過激活消息日志取代應(yīng)用進 程。
2. 根據(jù)權(quán)利要求1所述的基于消息日志的容錯集群系統(tǒng)，其特征在于， 所述應(yīng)用進程和備用進程中還設(shè)有用于記錄給其它進程所發(fā)送消息的最大 發(fā)送序列號列表，以及用于記錄從其它進程接收消息的接收序列號列表。
3. 根據(jù)權(quán)利要求2所述的基于消息日志的容錯集群系統(tǒng)，其特征在于， 所述的最大發(fā)送序列號列表、接收序列號列表、進程所發(fā)送消息的消息日 志保存在進程所屬計算節(jié)點的主存中。
4. 一種基于消息日志的容錯方法，其特征在于，所述方法包括以下處 理過程1) 設(shè)定檢査點，應(yīng)用進程將其狀態(tài)保存到檢查點中，并將檢査點信息 同步到備用進程；2) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送消息，并對發(fā)送的消息以消息日 志的方式保持到發(fā)送應(yīng)用進程和接收應(yīng)用進程中；3) 當計算節(jié)點發(fā)生故障，計算節(jié)點中失效的應(yīng)用進程對應(yīng)的備用進程 通過保存的檢查點和消息日志激活，并取代應(yīng)用進程的工作。
5. 根據(jù)權(quán)利要求4所述的基于消息日志的容錯方法，其特征在于，所 述步驟l)中具體包括以下處理過程11) 設(shè)定檢査點，應(yīng)用進程將其狀態(tài)保存到檢查點中，并將檢查點信 息給其備用進程；12) 備用進程收到檢査點信息后，用新的檢查點信息替代舊的檢查點 信息，并向應(yīng)用進程反饋確認信息。
6. 根據(jù)權(quán)利要求5所述的基于消息日志的容錯方法，其特征在于，所 述步驟12)之后還包括以下處理步驟13) 應(yīng)用進程通過向更新檢查點前所有與其有消息交互的應(yīng)用進程以及其備份進程發(fā)送垃圾收集信息，收到垃圾收集信息的進程根據(jù)信息內(nèi)容 刪除消息日志中的歷史垃圾消息。
7. 根據(jù)權(quán)利要求4所述的基于消息日志的容錯方法，其特征在于，其特征在于，所述步驟2)具體包括以下處理過程21) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送帶有消息發(fā)送序列號的通信請求；22) 接收應(yīng)用進程收到請求后，根據(jù)請求中帶有的消息發(fā)送序列號在 接收應(yīng)用進程的消息日志中査詢，對于確認該消息沒有收到過，則為待接 收的消息分配接收序列號，并向發(fā)送應(yīng)用進程反饋；23) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送消息。
8. 根據(jù)權(quán)利要求7所述的基于消息日志的容錯方法，其特征在于，所 述步驟23)具體為當發(fā)送應(yīng)用進程與接收應(yīng)用進程在同一計算節(jié)點時，231) 發(fā)送應(yīng)用進程將消息、發(fā)送序列號、接收序列號發(fā)送到發(fā)送應(yīng)用 進程的備份進程；232) 發(fā)送應(yīng)用進程的備份進程收到消息后，將內(nèi)容保存到其消息日志 中，并向發(fā)送應(yīng)用進程發(fā)送確認信息；233) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送消息； 當發(fā)送應(yīng)用進程與接收應(yīng)用進程在不同的計算節(jié)點時，234) 發(fā)送應(yīng)用進程將待發(fā)送消息、接收序列號保存在其消息日志中；235) 發(fā)送應(yīng)用進程向接收應(yīng)用進程發(fā)送消息。
9. 根據(jù)權(quán)利要求4所述的基于消息日志的容錯方法，其特征在于，所 述步驟3)具體包括以下處理過程31) 當計算節(jié)點發(fā)生故障，計算節(jié)點中失效的應(yīng)用進程對應(yīng)的備用進 程通過保存的檢査點和消息日志激活，并向其它應(yīng)用進程發(fā)送廣播消息；32) 其它應(yīng)用進程收到廣播消息后，向備用進程發(fā)送之前已發(fā)送給失效的應(yīng)用進程的消息，并附有各消息的接收序列號和最大接收序列號；33) 被激活的備份進程從收到的接收序列號中找到最大值，開始重新 分配接收序列號，完成取代應(yīng)用進程的工作。
全文摘要
本發(fā)明公開了一種基于消息日志的容錯集群系統(tǒng)和方法，本發(fā)明系統(tǒng)中無需額外增加可靠設(shè)備，而是利用備份進程保存檢查點和消息日志，同時，通過將它們記錄到消息發(fā)送者側(cè)的內(nèi)存中避免同步日志記錄產(chǎn)生的系統(tǒng)開銷。這不僅減小了記錄日志的費用，還取消了對穩(wěn)定存儲介質(zhì)的依賴。本發(fā)明不需要任何保存檢查點和日志的可靠存儲設(shè)備，在恢復(fù)期間，也不會依賴額外備用的計算節(jié)點去接替失效節(jié)點，進程無需重新啟動就會繼續(xù)運行在剩余的節(jié)點上。同時，系統(tǒng)還可以方便地增加負載均衡功能，有效降低節(jié)點失效對整個系統(tǒng)的影響。
文檔編號H04L12/24GK101145946SQ200710077179
公開日2008年3月19日 申請日期2007年9月17日 優(yōu)先權(quán)日2007年9月17日
發(fā)明者翌 李, 王繼剛, 謝世波 申請人:中興通訊股份有限公司