專利名稱：一種消息重發(fā)方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)據(jù)傳輸領(lǐng)域，特別涉及一種消息重發(fā)方法和系統(tǒng)。
背景技術(shù)：
在數(shù)據(jù)傳輸領(lǐng)域，以消息通知作為交互模式的應(yīng)用系統(tǒng)越來越多。在消息傳輸時，由于雙方系統(tǒng)或傳輸鏈路的故障，導(dǎo)致消息在傳輸過程中丟失而不能及時、可靠的送達(dá)。針對這一問題，形成了各種不同的消息重發(fā)機制，用于重新發(fā)送未成功送達(dá)的消息。采用重發(fā)機制，在第一次發(fā)送不成功的情況下，能夠進(jìn)行多次的發(fā)送嘗試，在很大程度上解決了消息發(fā)送不能送達(dá)的問題。但對于中長期的通信故障，由于多次的嘗試重發(fā)，即浪費發(fā)送時間又占用系統(tǒng)資源，造成了發(fā)送效率的低下。
在網(wǎng)絡(luò)協(xié)議設(shè)計中，針對數(shù)據(jù)傳輸失敗進(jìn)行回退重傳的算法很多。其中使用最廣的一個算法是二進(jìn)制指數(shù)回退(Binary Exponential Backoff，BEB)算法。下面以以太網(wǎng)802.3協(xié)議為例說明該算法的詳細(xì)過程。
802.3協(xié)議使用CSMA/CD算法解決在共享信道上的數(shù)據(jù)幀沖突問題。該算法持續(xù)偵聽信道，直到信道空閑；一旦信道空閑，立即發(fā)送數(shù)據(jù)；若數(shù)據(jù)沖突，立即停止發(fā)送；然后等待一個重試周期后再次嘗試發(fā)送。計算重試周期的方法是二進(jìn)制指數(shù)后退算法。它首先將時間分片，每個時間片的長度是t(51.2微秒)。則在第i次沖突時，重試周期T是在0到(2i-1)*t之間的一個隨機的長度為t的整數(shù)倍的時間。
二進(jìn)制指數(shù)回退算法使得當(dāng)數(shù)據(jù)傳輸發(fā)生故障時，重試時間間隔呈指數(shù)迅速增長。這種針對隨機故障模式設(shè)計的重試時間間隔計算方法并不適用于互聯(lián)網(wǎng)系統(tǒng)間消息通信的常見故障模式，往往會造成故障恢復(fù)時間過長?；ヂ?lián)網(wǎng)系統(tǒng)間消息通信發(fā)生故障的原因一般是網(wǎng)絡(luò)繁忙造成傳輸超時、網(wǎng)絡(luò)設(shè)備發(fā)生故障、應(yīng)用系統(tǒng)發(fā)生故障、計劃內(nèi)停機維護(hù)等等。這些故障的發(fā)生是隨機的，但故障的恢復(fù)由于人工發(fā)現(xiàn)和維護(hù)的介入，因此不是隨機的，而是具有一定的模式。此外，互聯(lián)網(wǎng)上的故障的恢復(fù)需要的時間往往以小時和天來計，而在這段時間內(nèi)會積累大量未發(fā)出的消息，需要一種高效靈活的消息保存、管理與重傳調(diào)度算法和系統(tǒng)。因此，建立適用于互聯(lián)網(wǎng)消息重傳方法和系統(tǒng)，在系統(tǒng)資源占用和消息通知恢復(fù)的及時性之間取得靈活的平衡，是很有意義的工作。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題是提供一種消息重發(fā)方法和系統(tǒng)，用盡可能少的重試次數(shù)、盡可能及時地將消息發(fā)送到消息接收方。特別，本發(fā)明是針對互聯(lián)網(wǎng)上消息通知失敗的常見原因而設(shè)計的。
為了解決上述問題，本發(fā)明提供了一種消息重發(fā)方法，該方法包括對需要重試的消息設(shè)置重試周期，以當(dāng)前時間加上對應(yīng)的重試周期作為重試時間；所述重試周期隨著重試次數(shù)的增加而增大；發(fā)送重試時間到期的消息。
優(yōu)選的，所述重試次數(shù)達(dá)到預(yù)置的值時，放棄自動重發(fā)。所述重試周期達(dá)到預(yù)置的值時，放棄自動重發(fā)。
優(yōu)選的，所述重試周期的增加值隨著重試次數(shù)的增加而變化；并可以根據(jù)不同的外部系統(tǒng)設(shè)置所述重試周期增加值的大小。
本發(fā)明還提供了一種消息重發(fā)系統(tǒng)，該系統(tǒng)包括數(shù)據(jù)庫，用于保存待發(fā)送的新消息和等待重試的消息；通知執(zhí)行器，用于發(fā)送新消息或重試的消息，若消息發(fā)送成功，則從所述數(shù)據(jù)庫中刪除本條消息；否則對應(yīng)所述消息設(shè)置重試周期，以當(dāng)前時間加上對應(yīng)的重試周期作為重試時間，并更新所述數(shù)據(jù)庫中的對應(yīng)消息；所述重試周期隨著重試次數(shù)的增加而增大；通知恢復(fù)器，用于檢查等待重試的消息，如果存在重試時間到期的消息，則通知所述通知執(zhí)行器。優(yōu)選的，所述的通知恢復(fù)器定時運行。
本發(fā)明還提供了一種系統(tǒng)間消息通知方法，包括以下步驟將通知消息持久存儲；發(fā)送存儲的新通知消息或重試的通知消息；若通知消息發(fā)送成功，則刪除存儲的本條通知消息；否則對該通知消息設(shè)置重試周期，以當(dāng)前時間加上對應(yīng)的重試周期作為重試時間，并更新存儲；所述重試周期隨著重試次數(shù)的增加而增大；檢查等待重試的通知消息，如果存在重試時間到期的通知消息，則執(zhí)行發(fā)送步驟。
優(yōu)選的，所述系統(tǒng)間消息通知方法還包括同時發(fā)送新通知消息以及重試的通知消息。優(yōu)選的，所述檢查為定時檢查。
與現(xiàn)有技術(shù)相比，本發(fā)明具有的優(yōu)點是所述方法和系統(tǒng)針對短期和中長期通信故障模式提出現(xiàn)實、高效的超時和消息重發(fā)解決方案。隨著重試次數(shù)的增加，其重試周期也越來越長。重試周期的變化，兼顧了通知恢復(fù)的及時性和效率。對于短期的通信故障，系統(tǒng)能夠在故障恢復(fù)之后及時將消息通知送達(dá)接收方；對于中長期通信故障，系統(tǒng)能夠避免多次重試的開銷。


下面結(jié)合附圖和具體實施方式
對本發(fā)明作進(jìn)一步詳細(xì)的說明。
圖1是本發(fā)明重試周期確定方法的概念模式圖；圖2是一種可靠的系統(tǒng)間消息通知系統(tǒng)的系統(tǒng)結(jié)構(gòu)示意圖；圖3是本發(fā)明一種消息重發(fā)方法的執(zhí)行步驟流程圖；圖4是消息通知的恢復(fù)流程圖；圖5是一種可靠的系統(tǒng)間消息通知方法的步驟流程圖；
圖6是消息通知的注冊流程圖；圖7是消息通知的發(fā)送流程圖。
具體實施例方式
基于互聯(lián)網(wǎng)的電子商務(wù)在當(dāng)今社會中占據(jù)了越來越重要的地位。越來越多的商業(yè)實體通過互聯(lián)網(wǎng)組織信息流、資金流和物流，以消息通知作為交互模式的互聯(lián)網(wǎng)應(yīng)用系統(tǒng)也越來越多。以銀行為例，用戶在銀行完成支付后，銀行需要將用戶支付的情況通過消息通知的形式告知商戶系統(tǒng)；以第三方安全交易平臺為例，當(dāng)用戶在交易平臺上推進(jìn)交易流程后，交易平臺需要將交易的當(dāng)前狀態(tài)通知相關(guān)的外部商戶系統(tǒng)。這些都是典型的基于互聯(lián)網(wǎng)的消息通知。本發(fā)明適用于任何協(xié)作的系統(tǒng)之間，但特別是針對互聯(lián)網(wǎng)上消息通知失敗的常見原因而設(shè)計的，因此以下優(yōu)選消息通知為例進(jìn)行說明。
互聯(lián)網(wǎng)上跨系統(tǒng)的消息通知失敗的可能原因有以下幾種網(wǎng)絡(luò)暫時繁忙，造成傳輸協(xié)議超時；網(wǎng)絡(luò)短暫中斷；對方服務(wù)器暫時繁忙，造成不響應(yīng)請求；對方系統(tǒng)存在BUG，造成不響應(yīng)請求或者請求處理出錯；對方服務(wù)器宕機，造成不響應(yīng)請求；網(wǎng)絡(luò)長時間故障，造成長達(dá)數(shù)小時以至于數(shù)天的中斷；對方系統(tǒng)長時間故障，造成長達(dá)數(shù)小時以至于數(shù)天不可用；對方系統(tǒng)不存在或者永久關(guān)閉。
從上述原因可見，造成消息通知不成功的原因既有可能在數(shù)分鐘內(nèi)消失或緩解，也有可能長達(dá)數(shù)小時或者數(shù)天。消息通知的最佳重試策略應(yīng)為當(dāng)原因可以在數(shù)分鐘內(nèi)消失或緩解時，消息通知能夠及時地發(fā)送給對方；而當(dāng)原因需要數(shù)小時或者數(shù)天才能消失時，系統(tǒng)也能將消息通知發(fā)送給對方，而且不做太多無謂的嘗試。因此，本發(fā)明優(yōu)選采用下述的一種重試周期確定方法進(jìn)行重試時間間隔的確定。所述重試時間間隔即為重試周期。
參照圖1，是本發(fā)明重試周期確定方法的概念模式圖。對所述確定方法說明如下假定有一組編號從1到n+1的盒子，1到n號盒子上都綁定一個定時器，盒子的編號越大，定時間隔越長，例如第一次間隔2分鐘，第二次間隔5分鐘，第3次間隔10分鐘等等。第n+1號盒子上沒有定時器，認(rèn)為消息接收方永久不可達(dá)，放棄自動重試，等待人工恢復(fù)。
一個消息通知任務(wù)第i次(i＝1..n)發(fā)送不成功，則進(jìn)第i個盒子；第i個盒子的定時器每次觸發(fā)都會重試本盒子中的所有消息通知任務(wù)；當(dāng)一個消息通知任務(wù)第n+1次發(fā)送不成功時，則進(jìn)第n+1個盒子，由于第n+1個盒子上沒有綁定定時器，因此系統(tǒng)將會放棄對該消息通知任務(wù)的自動重試，轉(zhuǎn)入人工處理。
此外，本發(fā)明中的通知系統(tǒng)針對不同類型外部系統(tǒng)的特點，對盒子上的定時器進(jìn)行了調(diào)整，使之符合相應(yīng)外部系統(tǒng)的故障模式。
如上所述，本發(fā)明方法的核心思想是重試周期隨著重試次數(shù)的增加而增大。采用圖1所示的重試周期確定方法，如果消息通知任務(wù)重試的次數(shù)較少，說明造成消息通知發(fā)送不成功的原因在很短時間內(nèi)消失了，則由于每次重試的時間間隔也較小，故可以保證故障恢復(fù)時消息通知的及時發(fā)送；如果消息通知任務(wù)重試的次數(shù)較多，說明造成消息通知發(fā)送不成功的原因?qū)儆陂L期通信故障，則后來重試的時間間隔也較長，可以有效避免太多無效的重試嘗試，減少系統(tǒng)資源占用，但也可以保證消息通知的確定送達(dá)。即上述重試周期確定方法確保了短期通信故障能夠及時恢復(fù)消息通知，而對于長期通信故障則能夠避免大量無效的通知嘗試，兼顧了通知恢復(fù)的及時性和效率。
在上述說明中，放棄自動重發(fā)的條件是以重試次數(shù)達(dá)到預(yù)置的值進(jìn)行說明的，但本發(fā)明并不局限在這一條件下，當(dāng)重試周期達(dá)到預(yù)置的值時，也會放棄自動重發(fā)。根據(jù)不同的應(yīng)用系統(tǒng)或不同業(yè)務(wù)情況，選擇任一方式設(shè)置預(yù)置值，都是為了避免無限制的重發(fā)嘗試。
本發(fā)明所述的重試周期確定方法中，優(yōu)選的，重試周期的增加值隨著重試次數(shù)的增加而變化，即當(dāng)前的重發(fā)周期和上次重發(fā)周期的差值與下次重發(fā)周期和當(dāng)前重發(fā)周期的差值是不同的。如在圖1中，第3個盒子與第2個盒子的定時間隔的差值是5分鐘，而第4個盒子與第3個盒子的定時間隔的差值是20分鐘，即重試周期的增加值如5分鐘和20分鐘，并不是固定變化的。當(dāng)然，也不排除采用重試周期的增加值固定變化的方法。對于優(yōu)選方法，所述重試周期增加值的變化是根據(jù)不同的外部系統(tǒng)設(shè)置的。針對不同類型外部系統(tǒng)的特點，每種情況下重試周期增加值的大小和重試時間間隔值是不同的。這樣的設(shè)置兼顧了通知恢復(fù)的及時性和效率，更符合應(yīng)用需求。
參照圖2，是一種可靠的系統(tǒng)間消息通知系統(tǒng)的系統(tǒng)結(jié)構(gòu)示意圖，包含本發(fā)明一種消息重發(fā)系統(tǒng)。所述消息重發(fā)系統(tǒng)包括數(shù)據(jù)庫13，用于保存待發(fā)送的新消息和等待重試的消息；通知執(zhí)行器152，用于發(fā)送新消息或重試的消息，若消息發(fā)送成功，則從數(shù)據(jù)庫13中刪除本條消息；否則對應(yīng)所述消息設(shè)置重試周期，以當(dāng)前時間加上對應(yīng)的重試周期作為重試時間，并更新數(shù)據(jù)庫13中的對應(yīng)消息；所述重試周期隨著重試次數(shù)的增加而增大；通知恢復(fù)器151，用于檢查等待重試的消息，如果存在重試時間到期的消息，則通知通知執(zhí)行器152。
如圖2所示，業(yè)務(wù)應(yīng)用11可以為某個商業(yè)應(yīng)用，它是消息通知的發(fā)起者。外部系統(tǒng)17可以為某個商業(yè)系統(tǒng)，它是消息通知的接收者。本發(fā)明所提供的通知系統(tǒng)用于發(fā)送所述業(yè)務(wù)應(yīng)用11發(fā)來的通知消息，并能夠確保該通知消息通過互聯(lián)網(wǎng)可靠到達(dá)所述的外部系統(tǒng)17。
數(shù)據(jù)庫13可以是任何通用的關(guān)系型數(shù)據(jù)庫，用以保存待發(fā)送的新通知消息和曾經(jīng)發(fā)送不成功等待重發(fā)的通知消息。通知客戶端12可以為供業(yè)務(wù)應(yīng)用11使用的一個客戶端模塊，嵌入到消息的業(yè)務(wù)系統(tǒng)中，業(yè)務(wù)應(yīng)用11可以使用通知客戶端12注冊一個通知消息。一旦通知消息注冊成功，系統(tǒng)就能夠確保該通知消息到達(dá)消息的接收方，即使此時消息接收方不在線，或者網(wǎng)絡(luò)暫時無法連通。所述注冊可以為，通知客戶端12將業(yè)務(wù)應(yīng)用11發(fā)來的通知消息存放到數(shù)據(jù)庫中，并通過消息隊列14觸發(fā)消息即時發(fā)送。所述業(yè)務(wù)系統(tǒng)是指針對業(yè)務(wù)應(yīng)用11，進(jìn)行相應(yīng)的業(yè)務(wù)處理的系統(tǒng)。結(jié)合網(wǎng)上銀行與商戶之間的消息通知實例，所述消息的事務(wù)處理是指用戶在網(wǎng)上銀行進(jìn)行實際支付，若支付完成則事務(wù)處理提交，否則還處于事務(wù)處理中；所述通知消息指用戶的支付結(jié)果，即是否完成支付。所述事務(wù)是一個技術(shù)上的專有名詞，表示具有ACID特性的一組操作，事務(wù)的ACID特性是實現(xiàn)消息通知與業(yè)務(wù)操作100％一致性的關(guān)鍵。當(dāng)創(chuàng)建事務(wù)時，應(yīng)確保事務(wù)具有某些可以自行管理的特性，這些特性就稱為ACID特性。ACID是指原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)。
將通知客戶端12嵌入到消息的業(yè)務(wù)系統(tǒng)中，可以在同一個數(shù)據(jù)庫事務(wù)中完成業(yè)務(wù)處理以及通知任務(wù)的注冊，完全可以避免業(yè)務(wù)處理和通知任務(wù)不一致的情況。所述一致為一通知消息只有當(dāng)事務(wù)處理完成提交后，該通知消息才注冊成功，進(jìn)行即時發(fā)送。所述數(shù)據(jù)庫事務(wù)中的數(shù)據(jù)庫可以是系統(tǒng)中保存消息通知請求的數(shù)據(jù)庫。一般說來，這個數(shù)據(jù)庫與業(yè)務(wù)系統(tǒng)保存業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)庫是同一個。如果是同一個數(shù)據(jù)庫，則可以避免使用復(fù)雜低效的分布式事務(wù)機制就能實現(xiàn)通知消息的注冊與業(yè)務(wù)數(shù)據(jù)的處理位于同一數(shù)據(jù)庫事務(wù)中。但也可以使用不同的數(shù)據(jù)庫，并通過分布式事務(wù)機制保證通知消息注冊與業(yè)務(wù)數(shù)據(jù)處理的一致性。
消息隊列14是一種標(biāo)準(zhǔn)的用于系統(tǒng)間異步消息通訊的中間件。通過使用消息隊列，消息的發(fā)送過程和接收過程之間是異步的，同時使得消息發(fā)送方和消息接收方不直接進(jìn)行通訊，而是通過消息隊列進(jìn)行間接通訊。這樣做最大程度地減小了消息發(fā)送方和消息接收方之間的相互依賴，使得消息發(fā)送方與消息接收方之間可以相對獨立地進(jìn)行工作。目前的消息隊列一般都能夠做到當(dāng)接收到消息之后，只要消息接收方工作正常，可以即時將消息傳遞給消息接收方。本實施例中，消息隊列14用以觸發(fā)通知消息的即時發(fā)送。
通知服務(wù)器15可以為一臺或一組獨立運行的，用以專門負(fù)責(zé)通知消息發(fā)送和通知消息重發(fā)的服務(wù)器，可以包括通知恢復(fù)器151、通知執(zhí)行器152以及多種協(xié)議適配器153。其中，通知恢復(fù)器151為負(fù)責(zé)調(diào)度未成功發(fā)送的通知消息在恰當(dāng)?shù)臅r間進(jìn)行重新發(fā)送的模塊；通知執(zhí)行器152為負(fù)責(zé)執(zhí)行實際的通知消息發(fā)送的模塊；多種協(xié)議適配器153中，每種協(xié)議適配器支持一種傳輸協(xié)議，通過互聯(lián)網(wǎng)完成與外部系統(tǒng)17的實際數(shù)據(jù)傳輸。通知業(yè)務(wù)處理插件庫16為各種業(yè)務(wù)插件161的管理器。業(yè)務(wù)插件161負(fù)責(zé)通知消息發(fā)送前的預(yù)處理和返回的通知結(jié)果處理，所述預(yù)處理和結(jié)果處理均與業(yè)務(wù)應(yīng)用緊密相關(guān)，不同的業(yè)務(wù)應(yīng)用，其處理過程也不相同。
參照圖3，是本發(fā)明一種消息重發(fā)方法的執(zhí)行步驟流程圖。當(dāng)消息第一次發(fā)送不成功時，進(jìn)入消息重發(fā)步驟步驟g1，計算消息的下一次重發(fā)時間。通知執(zhí)行器根據(jù)重試周期確定方法計算下一次重試需要等待的時間間隔，并用該間隔加上當(dāng)前時間作為下一次消息發(fā)送重試的時間點。
步驟g2，更新數(shù)據(jù)庫存儲。通知執(zhí)行器根據(jù)計算的重試時間，更新數(shù)據(jù)庫中對應(yīng)消息通知請求的發(fā)送時間，并放棄本輪通知，等待通知恢復(fù)器的重新調(diào)度。
步驟g 3，在定時時間點調(diào)度重試時間到期的消息并發(fā)送。參照圖4，是消息通知的恢復(fù)流程圖。當(dāng)所述通知消息需要重新發(fā)送時，進(jìn)入通知恢復(fù)流程。優(yōu)選的，通知恢復(fù)器定時運行，在每一輪運行中，執(zhí)行以下步驟步驟c1，通知恢復(fù)器等待定時時間，當(dāng)時間點到開始運行。
步驟c2，從數(shù)據(jù)庫中查找重試時間到期的消息通知請求。檢查需要重試的消息通知請求，將通知執(zhí)行器計算所得的重試時間與本輪的定時時間相比較，若有重試時間點小于或等于定時時間點的情況，則存在重試時間到期的消息通知請求，繼續(xù)步驟c3；否則放棄本輪重試，繼續(xù)步驟c4。
步驟c3，對于重試時間到期的通知消息，向通知執(zhí)行器發(fā)送重試請求，逐條交給通知執(zhí)行器進(jìn)行通知發(fā)送。
步驟c4，等待下一定時時間點，進(jìn)行下一輪運行。
通知恢復(fù)流程的定時時間一般是固定的，比如每隔1分鐘運行一次。定時時間間隔的大小關(guān)系到通知恢復(fù)的及時性，因此，這個時間間隔一般設(shè)置得越小越好，但必須在通知服務(wù)器能夠承受的性能范圍內(nèi)。此外，這個定時時間間隔與消息通知重試的間隔并不相同，消息通知重試的間隔時間是通過重試周期確定方法針對每一條通知消息單獨計算和設(shè)置的。
在步驟g3中，若所述步驟c3的發(fā)送成功，則本次消息重發(fā)成功完成；否則繼續(xù)執(zhí)行步驟g1。
本發(fā)明還提供了一種可靠的系統(tǒng)間消息通知方法，參照圖5，是一種可靠的系統(tǒng)間消息通知方法的步驟流程圖。當(dāng)業(yè)務(wù)應(yīng)用需要向外部系統(tǒng)發(fā)送一通知消息時，執(zhí)行以下步驟即可可靠送達(dá)步驟s1，業(yè)務(wù)應(yīng)用將自己的通知需求封裝成一個消息通知請求，發(fā)送至通知客戶端。
步驟s2，通知客戶端將所述通知消息進(jìn)行注冊。一旦通知消息注冊成功，業(yè)務(wù)應(yīng)用就可以繼續(xù)其它業(yè)務(wù)處理，所述系統(tǒng)就能夠確保該通知消息到達(dá)消息的接收方，即使此時消息接收方不在線，或者網(wǎng)絡(luò)暫時無法連通。
步驟s3，當(dāng)通知消息注冊成功后，通知系統(tǒng)進(jìn)行通知消息的發(fā)送。若發(fā)送成功，則消息通知任務(wù)結(jié)束；否則繼續(xù)步驟s4。
步驟s4，進(jìn)行消息發(fā)送的恢復(fù)處理，調(diào)度未成功發(fā)送的通知消息在恰當(dāng)?shù)臅r間進(jìn)行重新發(fā)送，繼續(xù)步驟s3。
在此過程中，步驟s4與步驟s1、步驟s2和步驟s3可以同時執(zhí)行。步驟s4即上述的步驟g3，可參照圖4消息通知的恢復(fù)流程圖。下面分別對步驟s2和s3進(jìn)行詳細(xì)說明。
參照圖6，是消息通知的注冊流程圖，包括以下步驟步驟a1，通知客戶端接收所述業(yè)務(wù)應(yīng)用發(fā)來的消息通知請求；所述消息通知請求可以包括消息通知的內(nèi)容。
步驟a2，通知客戶端將所述通知請求存放到數(shù)據(jù)庫中，直到通知消息發(fā)送成功，這樣可以避免在發(fā)送過程中由于網(wǎng)絡(luò)、服務(wù)器或程序系統(tǒng)不穩(wěn)定造成的通知消息丟失且不可恢復(fù)的問題。
步驟a3，通知客戶端判斷所述消息的事務(wù)處理是否完成提交，若還處于事務(wù)處理中，則繼續(xù)執(zhí)行步驟a4、步驟a5和步驟a6；若事務(wù)已完成提交，則通知客戶端自動觸發(fā)消息隊列，直接執(zhí)行步驟a6。結(jié)合網(wǎng)上銀行與商戶之間的消息通知實例，所述消息的事務(wù)處理是指用戶在網(wǎng)上銀行進(jìn)行實際支付，若支付完成則事務(wù)處理提交，否則還處于事務(wù)處理中；所述通知消息指用戶的支付結(jié)果，即是否完成支付。本實施例中，由于通知客戶端嵌入到業(yè)務(wù)系統(tǒng)中，能夠在業(yè)務(wù)事務(wù)內(nèi)完成將通知任務(wù)注冊到數(shù)據(jù)庫中，這樣避免使用復(fù)雜的機制就實現(xiàn)了業(yè)務(wù)處理和通知注冊的一致性。
步驟a4，通知客戶端向事務(wù)管理器注冊一個事務(wù)同步器。所述事務(wù)管理器是對事務(wù)進(jìn)行管理的軟件，包括事務(wù)同步器。所述事務(wù)同步器設(shè)置在通知客戶端，用于實現(xiàn)在事務(wù)提交之后通過消息隊列向通知服務(wù)器發(fā)送一個立即發(fā)送通知消息的請求，可以保證通知的及時性。
步驟a5，當(dāng)事務(wù)完成提交之后，事務(wù)同步器自動觸發(fā)消息隊列。
步驟a6，消息隊列向通知執(zhí)行器發(fā)送一個立即發(fā)送通知消息的請求，驅(qū)動通知執(zhí)行器進(jìn)行發(fā)送，保證了通知的即時性。
參照圖7，是消息通知的發(fā)送流程圖，包括以下步驟
步驟b1，通知執(zhí)行器接收到通知客戶端通過消息隊列發(fā)來的新消息通知請求，或者消息恢復(fù)器發(fā)來的重試消息通知請求。如果同時收到消息隊列發(fā)來的新消息通知請求和消息恢復(fù)器發(fā)來的重試消息通知請求，則優(yōu)選的，通知執(zhí)行器執(zhí)行多線程處理，可以同時發(fā)送新通知消息以及重試的通知消息。當(dāng)然，也可以采用確定優(yōu)先級進(jìn)行發(fā)送。
步驟b2，通知執(zhí)行器根據(jù)消息通知請求的類型，從業(yè)務(wù)插件庫中找到相應(yīng)的業(yè)務(wù)插件，將消息通知請求交給業(yè)務(wù)插件進(jìn)行預(yù)處理，得到實際的外部系統(tǒng)通知地址、通知協(xié)議和通知參數(shù)。
步驟b3，通知執(zhí)行器根據(jù)通知協(xié)議選擇合適的協(xié)議適配器，將通知消息內(nèi)容、通知地址和通知參數(shù)交給協(xié)議適配器進(jìn)行實際的消息發(fā)送。
步驟b4，如果網(wǎng)絡(luò)、雙方服務(wù)器與系統(tǒng)均正常工作，則消息通過互聯(lián)網(wǎng)到達(dá)外部系統(tǒng)，外部系統(tǒng)接收到消息并處理后返回處理結(jié)果；否則所述通知執(zhí)行器能夠自動檢測到通知消息未到達(dá)外部系統(tǒng)，繼續(xù)步驟b8和b9。
步驟b5，通知執(zhí)行器將返回結(jié)果交給業(yè)務(wù)插件，由業(yè)務(wù)插件完成相應(yīng)的業(yè)務(wù)處理。在上述例子中，當(dāng)收到外部商戶的返回結(jié)果之后，業(yè)務(wù)插件需要將交易的狀態(tài)變?yōu)橐寻l(fā)貨，并且記錄發(fā)貨單的詳情，通知用戶發(fā)貨情況。由于通知服務(wù)器本身是通用的，與具體業(yè)務(wù)無關(guān)，因此這些處理是由業(yè)務(wù)插件來完成的。
步驟b6，業(yè)務(wù)插件判斷本次發(fā)送是否需要重試。業(yè)務(wù)插件是根據(jù)是否有返回結(jié)果，以及返回結(jié)果的格式和內(nèi)容是否有效決定。仍以上述例子為例，如果返回結(jié)果中包含有效的商戶發(fā)貨信息，則業(yè)務(wù)插件判斷消息通知是成功的；如果沒有返回結(jié)果，或者返回結(jié)果格式無效，或者外部商戶在返回結(jié)果中直接表明暫時無法處理，需要過一段時間重試，則業(yè)務(wù)插件判斷消息通知未成功，需要重試。
因為消息發(fā)送不成功的可能原因不但包括網(wǎng)絡(luò)或系統(tǒng)故障，還取決于業(yè)務(wù)處理是否能夠成功，而通用的通知服務(wù)器可以判定網(wǎng)絡(luò)與系統(tǒng)的故障，但無法判定業(yè)務(wù)處理是否成功，因此將判定職責(zé)交給業(yè)務(wù)插件去完成。當(dāng)然，明顯的網(wǎng)絡(luò)與系統(tǒng)故障是通知服務(wù)器本身能夠判斷的，因此，當(dāng)發(fā)生這種情況時，由通知服務(wù)器直接決定需要重試。
步驟b7，如果業(yè)務(wù)插件表明本次消息不需要重試，則通知執(zhí)行器從數(shù)據(jù)庫中刪除本條消息通知請求，成功完成通知發(fā)送。
步驟b8，如果由于網(wǎng)絡(luò)等原因發(fā)送的通知消息未到達(dá)外部系統(tǒng)，或業(yè)務(wù)插件表明本次消息需要重試，則通知執(zhí)行器根據(jù)重試策略計算下一次重試需要等待的時間間隔，并用該間隔加上當(dāng)前時間作為下一次消息發(fā)送重試的時間點。
步驟b9，對于等待重新發(fā)送的通知消息，通知執(zhí)行器根據(jù)計算的重試時間，更新數(shù)據(jù)庫中對應(yīng)消息通知請求的發(fā)送時間，并放棄本輪通知，等待通知恢復(fù)器的重新調(diào)度。
在上述通知發(fā)送流程中，通過擴展業(yè)務(wù)插件，可以實現(xiàn)在同一個消息通知系統(tǒng)中支持各種類型的業(yè)務(wù)通知；通過擴展協(xié)議處理器，可以實現(xiàn)在同一個消息通知系統(tǒng)上支持不同協(xié)議的通知。此外，通知的接收者不需要實現(xiàn)任何特殊的可靠消息通知協(xié)議，只需要根據(jù)業(yè)務(wù)的要求返回消息處理的結(jié)果，就能夠可靠接收來自消息提供方的消息。
上述本發(fā)明一種消息重發(fā)方法和系統(tǒng)，用盡可能少的重試次數(shù)、盡可能及時地將消息發(fā)送到消息接收方。所述方法和系統(tǒng)針對短期和中長期通信故障模式提出現(xiàn)實、高效的超時和消息重發(fā)解決方案。隨著重試次數(shù)的增加，其重試周期也越來越長。重試周期的變化，兼顧了通知恢復(fù)的及時性和效率。對于短期的通信故障，系統(tǒng)能夠在故障恢復(fù)之后及時將消息通知送達(dá)接收方；對于中長期通信故障，系統(tǒng)能夠避免多次重試的開銷。
本發(fā)明還提供了一種可靠的系統(tǒng)間消息通知方法和系統(tǒng)，適用于任何協(xié)作的系統(tǒng)之間，尤其解決了系統(tǒng)之間通過互聯(lián)網(wǎng)進(jìn)行消息通知時，由于網(wǎng)絡(luò)內(nèi)在的不可靠性和系統(tǒng)軟、硬件故障造成的通知消息丟失且不可恢復(fù)的問題，確保消息的可靠、及時到達(dá)。本發(fā)明支持不同系統(tǒng)間的多協(xié)議傳輸，接收方不需要實現(xiàn)復(fù)雜的交互協(xié)議就能夠可靠接收通知消息，適合廣泛應(yīng)用于互聯(lián)網(wǎng)。所述方法和系統(tǒng)還支持多業(yè)務(wù)處理，可作為一個通用的業(yè)務(wù)應(yīng)用平臺。同時，可以進(jìn)行多業(yè)務(wù)和多協(xié)議的靈活擴展。
以上對本發(fā)明所提供的一種消息重發(fā)方法和系統(tǒng)、以及一種可靠的系統(tǒng)間消息通知方法和系統(tǒng)進(jìn)行了詳細(xì)介紹，本文僅以優(yōu)選實施例對本發(fā)明進(jìn)行說明。特別是，本發(fā)明所述的方法和系統(tǒng)適用于任何協(xié)作的系統(tǒng)之間，并不僅局限在基于互聯(lián)網(wǎng)的系統(tǒng)之間，只是優(yōu)選保證了互聯(lián)網(wǎng)間的消息重發(fā)和可靠消息通知，更適合廣泛應(yīng)用于互聯(lián)網(wǎng)。所以，并不能因此即局限本發(fā)明的權(quán)利范圍，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實施方式
及應(yīng)用范圍上均會有改變之處。綜上所述，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。
權(quán)利要求
1.一種消息重發(fā)方法，其特征在于對需要重試的消息設(shè)置重試周期，以當(dāng)前時間加上對應(yīng)的重試周期作為重試時間，所述重試周期隨著重試次數(shù)的增加而增大；發(fā)送重試時間到期的消息。
2.根據(jù)權(quán)利要求1所述的一種消息重發(fā)方法，其特征在于所述重試次數(shù)達(dá)到預(yù)置的值時，放棄自動重發(fā)。
3.根據(jù)權(quán)利要求1所述的一種消息重發(fā)方法，其特征在于所述重試周期達(dá)到預(yù)置的值時，放棄自動重發(fā)。
4.根據(jù)權(quán)利要求1所述的一種消息重發(fā)方法，其特征在于所述重試周期的增加值隨著重試次數(shù)的增加而變化。
5.根據(jù)權(quán)利要求4所述的一種消息重發(fā)方法，其特征在于根據(jù)不同的外部系統(tǒng)設(shè)置所述重試周期增加值的大小。
6.一種消息重發(fā)系統(tǒng)，其特征在于，包括數(shù)據(jù)庫，用于保存待發(fā)送的新消息和等待重試的消息；通知執(zhí)行器，用于發(fā)送新消息或重試的消息，若消息發(fā)送成功，則從所述數(shù)據(jù)庫中刪除本條消息；否則對應(yīng)所述消息設(shè)置重試周期，以當(dāng)前時間加上對應(yīng)的重試周期作為重試時間，并更新所述數(shù)據(jù)庫中的對應(yīng)消息；所述重試周期隨著重試次數(shù)的增加而增大；通知恢復(fù)器，用于檢查等待重試的消息，如果存在重試時間到期的消息，則通知所述通知執(zhí)行器。
7.根據(jù)權(quán)利要求6所述的一種消息重發(fā)系統(tǒng)，其特征在于所述的通知恢復(fù)器定時運行。
8.一種系統(tǒng)間消息通知方法，其特征在于，包括以下步驟將通知消息持久存儲；發(fā)送存儲的新通知消息或重試的通知消息；若通知消息發(fā)送成功，則刪除存儲的本條通知消息；否則對該通知消息設(shè)置重試周期，以當(dāng)前時間加上對應(yīng)的重試周期作為重試時間，并更新存儲；所述重試周期隨著重試次數(shù)的增加而增大；檢查等待重試的通知消息，如果存在重試時間到期的通知消息，則執(zhí)行發(fā)送步驟。
9.根據(jù)權(quán)利要求1所述的一種系統(tǒng)間消息通知方法，其特征在于，還包括同時發(fā)送新通知消息以及重試的通知消息。
10.根據(jù)權(quán)利要求1所述的一種系統(tǒng)間消息通知方法，其特征在于所述檢查為定時檢查。
全文摘要
本發(fā)明公開一種消息重發(fā)方法和系統(tǒng)，能夠用盡可能少的重試次數(shù)、盡可能及時地將消息通知發(fā)送到消息接收方。所述方法包括對需要重試的消息設(shè)置重試周期，以當(dāng)前時間加上對應(yīng)的重試周期作為重試時間；所述重試周期隨著重試次數(shù)的增加而增大；發(fā)送重試時間到期的消息。當(dāng)所述重試次數(shù)或所述重試周期達(dá)到預(yù)置的值時，放棄自動重發(fā)。本發(fā)明還公開一種可靠的系統(tǒng)間消息通知方法和系統(tǒng)，能夠保證消息通知的可靠到達(dá)。所述方法和系統(tǒng)支持不同系統(tǒng)間的多協(xié)議傳輸，接收方不需要實現(xiàn)復(fù)雜的交互協(xié)議就能夠可靠接收通知消息，適合廣泛應(yīng)用于互聯(lián)網(wǎng)。此外，還支持多業(yè)務(wù)處理，可作為一個通用的業(yè)務(wù)應(yīng)用平臺。同時，還可以進(jìn)行多業(yè)務(wù)和多協(xié)議的靈活擴展。
文檔編號H04L1/08GK1829139SQ20061006636
公開日2006年9月6日 申請日期2006年3月30日 優(yōu)先權(quán)日2006年3月30日
發(fā)明者錢志龍, 程立, 李磊 申請人:阿里巴巴公司