两个人的电影免费视频_国产精品久久久久久久久成人_97视频在线观看播放_久久这里只有精品777_亚洲熟女少妇二三区_4438x8成人网亚洲av_内谢国产内射夫妻免费视频_人妻精品久久久久中国字幕

基于消息隊列的分布式方法和系統(tǒng)的制作方法

文檔序號:6379635閱讀:221來源:國知局
專利名稱:基于消息隊列的分布式方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域
本發(fā)明涉及一種基于消息中間件的分布式方法和系統(tǒng),更具體地,涉及一種基于消息隊列的分布式方法和系統(tǒng)。
背景技術(shù)
在大規(guī)模分布式系統(tǒng)中,消息中間件(message-oriented middleware, MOM)被廣泛使用。消息中間件是一種由消息傳輸機制或消息隊列模式組成的中間件技術(shù)。消息中間件利用高效可靠的消息傳輸機制進行平臺無關(guān)的數(shù)據(jù)交流,并且基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成。通常,消息中間件并不要求系統(tǒng)具備一個可靠的底部傳輸層,而是通過以消息的形式收發(fā)應(yīng)用程序數(shù)據(jù)來連接運行于不同系統(tǒng)上的應(yīng)用程序。信息可以同步傳送,也支持異步傳送。在異步方式下,應(yīng)用程序并不需要消息即時即刻傳送到對方,只是由MOM確保把信息以消息的方式傳送到適當(dāng)?shù)哪康牡兀⑶抑粋饕淮?。消息隊?MQ) (Message Queuing)是一種應(yīng)用程序?qū)?yīng)用程序的通信方法。應(yīng)用程序通過寫和檢索出入隊列的針對應(yīng)用程序的數(shù)據(jù)(消息)來通信,而無需專用連接來鏈接它們。消息傳遞指的是程序之間通過在消息中發(fā)送數(shù)據(jù)進行通信,而不是通過直接調(diào)用彼此來通信,直接調(diào)用通常是用于諸如遠程過程調(diào)用的技術(shù)。排隊指的是應(yīng)用程序通過隊列來通信。隊列的使用除去了接收和發(fā)送應(yīng)用程序同時執(zhí)行的要求。MQ具有異步通信、消息路由可靠、安全性、協(xié)議無關(guān)性等優(yōu)點。然而,在大規(guī)模分布式系統(tǒng),如果使用通常的MQ解決方案,存在諸多缺點,包括消費消息阻塞;MQ單點;發(fā)送消息阻塞;消息不匹配;MQ/消息無監(jiān)控;消息順序不一致;死信隊列無法處理。因此,需要一種用于增強MQ方案的基于消息隊列的分布式方法和系統(tǒng)。

發(fā)明內(nèi)容
根據(jù)本發(fā)明的一方面,提供了一種基于消息隊列的分布式方法,包括由第一應(yīng)用向隊列管理器發(fā)送消息;確定所述消息是否成功發(fā)送;如果確定沒有成功發(fā)送所述消息,則所述消息被放入第一異常處理模塊進行處理;如果確定已經(jīng)成功發(fā)送所述消息,則由所述隊列管理器對所接收到的消息進行處理;將所述消息發(fā)送到第二應(yīng)用;以及由所述第二應(yīng)用對所接收到的消息進行處理。根據(jù)本發(fā)明的一個實施例,所述由所述隊列管理器對所接收到的消息進行處理的步驟進一步包括確定所述消息是否是死信;以及如果確定所述消息是死信,則所述消息被放入死信處理模塊以進行處理。根據(jù)本發(fā)明的一個實施例,所述由第二應(yīng)用對所接收到的消息進行處理的步驟進一步包括確定所述第二應(yīng)用是否已經(jīng)成功處理了所述消息;以及如果確定沒有成功處理所述消息,則所述消息被放入第二異常處理模塊進行處理。
根據(jù)本發(fā)明的一個實施例,所述消息被放入第一異常處理模塊進行處理的步驟進一步包括確定所述第一異常處理模塊是否已經(jīng)成功處理了所述消息;如果確定沒有成功處理所述消息,則向監(jiān)控模塊報告該情況;以及如果確定已經(jīng)成功處理了所述消息,則將所述消息發(fā)送到所述隊列管理器。根據(jù)本發(fā)明的一個實施例,所述消息被放入死信處理模塊以進行處理的步驟進一步包括確定所述死信處理模塊是否已經(jīng)成功處理所述消息;以及如果確定沒有成功處理所述消息,則向監(jiān)控模塊報告該情況。根據(jù)本發(fā)明的一個實施例,所述消息被放入第二異常處理模塊進行處理的步驟進一步包括確定所述第二異常處理模塊是否已經(jīng)成功處理了所述消息;以及如果確定沒有成功處理所述消息,則向監(jiān)控模塊報告該情況。根據(jù)本發(fā)明的一個實施例,在所述第一應(yīng)用向所述隊列管理器發(fā)送所述消息之前,注冊模塊可以對所述消息進行匹配檢查,并且僅當(dāng)所述消息匹配時,才繼續(xù)后續(xù)操作。根據(jù)本發(fā)明的一個實施例,所述隊列管理器是隊列管理器集群。根據(jù)本發(fā)明的一個實施例,所述由隊列管理器對所接收到的消息進行處理進一步包括確定所述隊列管理器集群中的一個隊列管理器未能正常工作;隔離所述一個隊列管理器,使得不會再有新的消息路由到所述一個隊列管理器;以及由其余的隊列管理器接管所述一個隊列管理器的工作。根據(jù)本發(fā)明的一個實施例,所述確定所述第一異常處理模塊是否已經(jīng)成功處理了所述消息的步驟在預(yù)定時間間隔之后執(zhí)行。根據(jù)本發(fā)明的一個實施例,所述確定所述死信處理模塊是否已經(jīng)成功處理所述消息的步驟在預(yù)定時間間隔之后執(zhí)行。根據(jù)本發(fā)明的一個實施例,所述確定所述第二異常處理模塊是否已經(jīng)成功處理了所述消息的步驟在預(yù)定時間間隔之后執(zhí)行。根據(jù)本發(fā)明的一方面,提供了一種基于消息隊列的分布式系統(tǒng),包括第一應(yīng)用,所述第一應(yīng)用被配置成向隊列管理器發(fā)送消息;第一異常處理模塊,所述第一異常處理模塊連接到所述第一應(yīng)用,并且被配置成對所述第一應(yīng)用沒有成功發(fā)送的消息進行處理;隊列管理器,所述隊列管理器與所述第一應(yīng)用和所述第一異常處理模塊相連,并且被配置成對所接收到的消息進行處理并且將所述消息發(fā)送到第二應(yīng)用;以及第二應(yīng)用,所述第二應(yīng)用連接到所述隊列管理器,并且被配置成對所接收到的消息進行處理。根據(jù)本發(fā)明的一個實施例,所述系統(tǒng)進一步包括監(jiān)控模塊,所述監(jiān)控模塊被配置成對所述第一應(yīng)用、所述隊列管理器和所述第二應(yīng)用進行監(jiān)控。根據(jù)本發(fā)明的一個實施例,所述隊列管理器進一步包括死信處理模塊,所述死信處理模塊被配置成對死信進行處理。根據(jù)本發(fā)明的一個實施例,所述第二應(yīng)用進一步包括第二異常處理模塊,所述第二異常處理模塊被配置成對所述第二應(yīng)用沒有成功處理的消息進行處理。根據(jù)本發(fā)明的一個實施例,所述第一異常處理模塊進一步被配置成確定是否已經(jīng)成功處理了所述消息;如果確定沒有成功處理所述消息,則向所述監(jiān)控模塊報告該情況;以及如果確定已經(jīng)成功處理了所述消息,則將所述消息發(fā)送到所述隊列管理器。根據(jù)本發(fā)明的一個實施例,所述死信處理模塊進一步被配置成確定所述死信處理模塊是否已經(jīng)成功處理所述消息;以及如果確定沒有成功處理所述消息,則向所述監(jiān)控模塊報告該情況。根據(jù)本發(fā)明的一個實施例,所述第二異常處理模塊進一步被配置成確定是否已經(jīng)成功處理了所述消息;以及如果確定沒有成功處理所述消息,則向所述監(jiān)控模塊報告該情況。根據(jù)本發(fā)明的一個實施例,所述系統(tǒng)進一步包括注冊模塊,所述注冊模塊被配置成對所述消息進行匹配檢查,并且僅當(dāng)所述消息匹配時,才繼續(xù)后續(xù)操作。根據(jù)本發(fā)明的一個實施例,所述隊列管理器是隊列管理器集群。根據(jù)本發(fā)明的一個實施例,所述隊列管理器集群進一步被配置成確定所述隊列管理器集群中的一個隊列管理器未能正常工作;隔離所述一個隊列管理器,使得不會再有新的消息路由到所述一個隊列管理器;以及由其余的隊列管理器接管所述一個隊列管理器的工作。根據(jù)本發(fā)明的一個實施例,所述第一異常處理模塊進一步被配置成在預(yù)定時間間隔之后,確定是否已經(jīng)成功處理了所述消息。根據(jù)本發(fā)明的一個實施例,所述死信處理模塊進一步被配置成在預(yù)定時間間隔之后,確定是否已經(jīng)成功處理所述消息。根據(jù)本發(fā)明的一個實施例,所述第二異常處理模塊進一步被配置成在預(yù)定時間間隔之后,確定是否已經(jīng)成功處理了所述消息。根據(jù)本發(fā)明的基于消息隊列的分布式方法和系統(tǒng)針對大規(guī)模分布式系統(tǒng),對MQ解決方案進行了有效改進,解決了存在的諸多缺點,包括消費消息阻塞;MQ單點;發(fā)送消息阻塞;消息不匹配;MQ/消息無監(jiān)控;消息順序不一致;死信隊列無法處理等問題,從而實現(xiàn)了具有高效實時、高擴展性、系統(tǒng)松耦合的分布式方法和系統(tǒng)。


附示了本發(fā)明的實施例,并與說明書一起用于解釋本發(fā)明的原理。在附圖中圖1圖示了根據(jù)本發(fā)明的實施例的用于基于消息隊列的分布式系統(tǒng)的示意框圖。圖2圖示了根據(jù)本發(fā)明的實施例的用于基于消息隊列的分布式方法的流程圖。圖3圖示了根據(jù)本發(fā)明的實施例的在隊列管理器集群中消息的一個處理流程圖。
具體實施例方式下面結(jié)合說明書附圖詳細描述本發(fā)明的實施例。在消息中間件中,不同的應(yīng)用之間傳遞交換的信息統(tǒng)稱為消息,它是數(shù)據(jù)交換的基本單位。消息可以是各種各樣的媒體,諸如文本、聲音、圖像等。每一個消息都可以擁有一個優(yōu)先級屬性,表示與其他消息的相對重要性。消息可以包含發(fā)送和接收者的標(biāo)識、時間戳、到期時間等信息。無法傳遞或已過期的消息被稱為死信。隊列可以看作一個容器,用于存放消息。隊列可以分為很多種類型,例如包括本地隊列、遠程隊列等。本地隊列按功能又被分為初始化隊列、傳輸隊列、目標(biāo)隊列、死信隊列等。初始化隊列用作消息觸發(fā)。傳輸隊列用于暫時存放待傳送的消息,在條件許可的情況下將通過管道將消息傳送到其他隊列管理器。目標(biāo)隊列是消息的目的地,可以長期存放消息。死信隊列是普通的本地隊列。如果消息不能送達目標(biāo)隊列,也不能再路由出去,將自動將其放入死信隊列保存。集群通常指的是由多機系統(tǒng)共同負(fù)擔(dān)計算機任務(wù),如果其中一個節(jié)點出現(xiàn)故障,則剩余的部分會接管其工作。從本質(zhì)上看,集群要解決的是系統(tǒng)容錯和負(fù)載均衡這兩個問題。圖1圖示了根據(jù)本發(fā)明的實施例的用于基于消息隊列的分布式系統(tǒng)100的示意框圖。如圖1所示,根據(jù)本發(fā)明的用于管理消息隊列的系統(tǒng)100包括應(yīng)用102、隊列管理器集群103、應(yīng)用104、注冊模塊106、監(jiān)控模塊108以及異常處理模塊110和112。應(yīng)用102是發(fā)送方,用于將消息發(fā)送到隊列管理器集群103,并且可以例如是業(yè)務(wù)系統(tǒng)。應(yīng)用104是接收方,用于從隊列管理器集群接收消息并且將其發(fā)送到服務(wù)器,并且可以例如是報表系統(tǒng)。例如,業(yè)務(wù)系統(tǒng)在必要的處理環(huán)節(jié),可以通過消息隊列推送消息給報表系統(tǒng),并且在報表系統(tǒng)偵聽到消息后,對其進行相關(guān)處理。替代地,應(yīng)用102可以是接收方,而應(yīng)用104可以是發(fā)送方。應(yīng)用102和104可以分布于同一臺機器上,也可以分布于相連的網(wǎng)絡(luò)空間中的任一位置。而且,可以存在不止一個應(yīng)用102和104。隊列管理器集群103用于從應(yīng)用102接收消息、處理本地消息并且將消息發(fā)送到應(yīng)用104。隊列管理器集群103可以包括一個或多個隊列管理器。為了簡單說明,在此僅示出了兩個隊列管理器114和116。隊列管理器114和116用于管理所有的消息隊列,包括消息的出隊、入隊以及分發(fā)到其他隊列管理器。隊列管理器114和116可以是本地隊列管理器,也可以是遠程隊列管理器,而且它們也可以是不同操作系統(tǒng)上的隊列管理器。根據(jù)本發(fā)明的實施例,隊列管理器114包括消息處理模塊118和死信處理模塊120,而隊列管理器116包括消息處理模塊122和死信處理模塊124。解決發(fā)送消息阻塞在現(xiàn)有技術(shù)中,如果消息發(fā)送方由于隊列管理器或消息接收方等問題而無法成功發(fā)送消息,則造成發(fā)送消息阻塞,從而消息丟失。在根據(jù)本發(fā)明的實施例中,如果應(yīng)用102不能成功發(fā)送消息,則將沒有成功處理的消息放入異常處理模塊110,該異常處理模塊110將對該沒有成功處理的消息進行處理,并且在成功處理該消息之后,由異常處理模塊Iio將其發(fā)送到隊列管理器集群103,由此避免了消息阻塞的問題。異常處理模塊110可以包括異常數(shù)據(jù)庫,在這種情況下在異常數(shù)據(jù)庫中利用worker來處理沒有成功處理的消息。此外,也可以對進入異常處理模塊110的沒有成功處理的消息設(shè)定優(yōu)先級,并根據(jù)優(yōu)先級對這些消息進行處理,使得能夠優(yōu)先處理重要事件,從而使消息傳遞更有效率。如果異常處理模塊110對沒有成功處理的消息進行處理的次數(shù)或時間達到預(yù)定閾值仍然不成功,則通過監(jiān)控模塊108提示進行人工處理,以避免死循環(huán)。解決MQ故障在現(xiàn)有技術(shù)中,由于MQ是單點,所以如果隊列管理器出現(xiàn)故障,則業(yè)務(wù)處理將失敗。在根據(jù)本發(fā)明的實施例中,將隊列管理器實現(xiàn)為隊列管理器集群,集群內(nèi)部的隊列管理器之間進行通信時,不需要兩兩之間建立通信信道,并且集群中的隊列管理器之間能夠自動進行負(fù)載均衡。如圖1所示,隊列管理器集群103包括多個并行設(shè)置的隊列管理器。為了簡單解釋起見,圖1中僅示出了兩個隊列管理器114和116。而且,隊列管理器集群103可以水平擴展。如果隊列管理器集群103中的一個隊列管理器出現(xiàn)故障或因其他原因而不工作,例如,隊列管理器114出現(xiàn)故障,則隊列管理器集群103可以自動將其隔離,使得不會再有新的消息路由到隊列管理器114,并且由隊列管理器116接管隊列管理器114的工作,從而避免了業(yè)務(wù)處理失敗。因此,系統(tǒng)100可以在充分利用現(xiàn)有資源、簡化系統(tǒng)配置的同時,大大提高了消息傳送的可靠性。解決死信隊列無法處理如已知的,每個隊列管理器都具有死信隊列,死信隊列保存的是未送達的消息。未送達可能是例如由于網(wǎng)絡(luò)或目的地等問題造成的。雖然死信隊列的設(shè)置可以一定程度上防止通道關(guān)閉或減少影響隊列管理器的正常操作,但是如果死信過多,則仍然會對隊列管理器甚至整個系統(tǒng)造成不利影響。根據(jù)本發(fā)明的實施例,隊列管理器118和122分別包括死信處理模塊120和124。死信處理模塊120、124用于對死信進行處理。死信處理模塊120和124的設(shè)置使得可以在沒有人工介入的情況下自動處理死信隊列,從而有效避免了死信的積壓并提高了系統(tǒng)效率。具體地,死信處理模塊120和124例如可以基于死信產(chǎn)生的原因、死信的目的地等等因素來進行重發(fā)、轉(zhuǎn)發(fā)、刪除等處理。死信產(chǎn)生的原因例如包括目標(biāo)隊列已經(jīng)滿了、目標(biāo)隊列不存在、消息不允許被放置在隊列中、發(fā)送者沒有被授權(quán)使用目標(biāo)隊列、消息過大、消息含有重復(fù)的序列號等等。例如,對于暫時性錯誤,死信處理模塊120、124可以采取重試的策略,但是死信處理模塊120、124應(yīng)當(dāng)控制重試的間隔和/或次數(shù),例如可以事先設(shè)置預(yù)定的時間間隔和/或次數(shù)??蛇x地,可以在每一次重試之間增大間隔時間,從而防止增大系統(tǒng)的負(fù)荷。例如,對于由于系統(tǒng)繁忙引起的錯誤,死信處理模塊120、124可以盡可能降低吞吐從而減少恢復(fù)的時間。然而,如果死信處理模塊120、124在超過預(yù)定的時間間隔和/或次數(shù)之后仍未成功處理死信,則通過監(jiān)控模塊108將錯誤報告給管理員,以便人工介入分析原因。解決消費消息阻塞在現(xiàn)有技術(shù)中,業(yè)務(wù)涉及完全依賴于隊列管理器。也就是,只有數(shù)據(jù)處理成功之后,才消費消息。如果接收方出現(xiàn)故障,則會造成堵塞,過多堵塞甚至造成消息積壓,以致使報表系統(tǒng)無法工作,甚至因為死信隊列過大而引發(fā)隊列管理器故障。在根據(jù)本發(fā)明的實施例中,隊列管理器114、116僅用作一個通知系統(tǒng),它們與應(yīng)用104解耦,也就是說應(yīng)用104本身直接消費消息。如果應(yīng)用104本身出現(xiàn)故障或沒有成功處理消息,則該消息被放入異常處理模塊112,該異常處理模塊112將對該消息進行處理,由此避免了消息阻塞的問題。另外,異常處理模塊112可以包括異常數(shù)據(jù)庫,在這種情況下在異常數(shù)據(jù)庫中利用worker來處理沒有成功處理的消息。類似地,也可以對進入異常處理模塊112的沒有成功處理的消息設(shè)定優(yōu)先級,并根據(jù)優(yōu)先級對這些消息進行處理,從而使消息傳遞更有效率。如果異常處理模塊112對沒有成功處理的消息進行處理的次數(shù)或時間達到預(yù)定閾值仍然不成功,則通過監(jiān)控模塊108提示進行人工處理,以避免死循環(huán)。解決消息不匹配在現(xiàn)有技術(shù)中,消息生產(chǎn)者和消費者利用配置文件獨立定義消息,缺乏匹配檢查。如果消息生產(chǎn)者和消費者的消息不一致,則會造成報表數(shù)據(jù)不準(zhǔn)或者產(chǎn)生大量死信隊列。根據(jù)本發(fā)明的實施例,作為消息生產(chǎn)者的應(yīng)用102和作為消息消費者的應(yīng)用104需要通過注冊模塊106進行注冊,并且在系統(tǒng)100啟動時注冊模塊106進行消息匹配檢查,如果出現(xiàn)消息不一致的情況,則系統(tǒng)100不能啟動,避免上線出現(xiàn)問題。該消息集中注冊機制可以防止出現(xiàn)數(shù)據(jù)不準(zhǔn)或大量死信隊列的產(chǎn)生。解決MQ/消息無監(jiān)控在現(xiàn)有技術(shù)中,由于沒有對隊列管理器和/或消息進行監(jiān)控,因此在出現(xiàn)異常的情況下,不能做到提前預(yù)警,也無法知道發(fā)送和/或接收數(shù)量是否準(zhǔn)確。根據(jù)本發(fā)明的實施例,系統(tǒng)100包括監(jiān)控模塊108,該監(jiān)控模塊108對應(yīng)用102、隊列管理器集群103、應(yīng)用104的各項指標(biāo)進行監(jiān)控,并根據(jù)需要相應(yīng)地發(fā)出警報。例如,監(jiān)控模塊108可以對發(fā)送和消費消息數(shù)量進行統(tǒng)計監(jiān)控。例如,如果正常隊列超過某個閾值(例如,5000條),則監(jiān)控模塊108就會報警。又例如,如果死信隊列有數(shù)據(jù),則監(jiān)控模塊108就會報警。通常,如上所述,對于應(yīng)用或隊列管理器自己能夠處理和解決的可恢復(fù)的錯誤是由其相應(yīng)的異常處理模塊110、112或死信處理模塊120、124自行處理,例如,連接失敗(可以按照一定規(guī)則重新連接)、暫時的錯誤(可以稍后進行重試)。然而,對于在進行人工介入之前不可能由應(yīng)用程序恢復(fù)的錯誤是由監(jiān)控模塊108通知給管理員,例如,應(yīng)用錯誤(例如,使用了不正確的參數(shù))、系統(tǒng)錯誤(例如,硬件問題、磁盤滿或隊列損壞等)以及軟件問題(例如,其他應(yīng)用停止工作導(dǎo)致隊列滿等)。然而,如果對可恢復(fù)的錯誤處理若干次后,仍然不能成功處理的情況下,則認(rèn)為這個錯誤是不可恢復(fù)。在這種情況下,通過監(jiān)控模塊108將該情況通知給管理員,同時釋放其他相關(guān)的資源。例如,如果當(dāng)前鏈接失效或中斷,則應(yīng)用或隊列管理器可以重新建立連接并嘗試重新開始操作,但是如果在重試預(yù)定次數(shù)和/或預(yù)定時間間隔之后,仍未能成功連接,則應(yīng)用或隊列管理器通過監(jiān)控模塊108將該情況通知給管理員,以保證系統(tǒng)正常運行并防止意外的發(fā)生。對本領(lǐng)域技術(shù)人員顯而易見的是,對于以上描述的發(fā)送消息阻塞、MQ故障、死信隊列無法處理、消費消息阻塞、消息不匹配以及MQ/消息無監(jiān)控的問題的解決方案,可以同時應(yīng)用以上所有的技術(shù)方案,也可以選擇性地應(yīng)用以上解決方案中的一個或多個。例如,可以僅應(yīng)用針對發(fā)送消息阻塞的技術(shù)方案。替代地,可以應(yīng)用包括針對發(fā)送消息阻塞和MQ/消息無監(jiān)控的技術(shù)方案,等等。圖2圖示了根據(jù)本發(fā)明的實施例的用于基于消息隊列的分布式方法的流程圖200。如圖2所示,根據(jù)本發(fā)明的實施例的方法的流程圖200,在步驟204中,應(yīng)用102向隊列管理器集群103發(fā)送消息。在可選步驟206中,確定該消息是否成功發(fā)送。如果在步驟206中確定沒有成功發(fā)送,則在步驟208中,該消息被放入異常處理模塊110進行處理。然后,在可選步驟210中,確定是否已經(jīng)成功處理了該消息。如果在預(yù)定時間間隔之后,仍然沒有成功處理該消息,則在步驟212中,向監(jiān)控模塊108報告該情況。如果在步驟210中確定已經(jīng)成功處理了該消息,則在步驟214中異常處理模塊110將該消息發(fā)送到隊列管理器集群103。如果在步驟206中確定已經(jīng)成功發(fā)送了消息或者在步驟214中異常處理模塊110將成功處理的消息發(fā)送到隊列管理器集群103,則在步驟216中,隊列管理器集群103對所接收到的消息進行處理。然后,在可選步驟218中,確定該消息是否是死信。如果在步驟218中確定該消息是死信,則在步驟220中,該消息被放入死信處理模塊120中進行處理。接著,在可選步驟222中,確定該消息是否已經(jīng)被成功處理。如果在預(yù)定時間間隔之后,仍然沒有成功處理該消息,則在步驟224中,向監(jiān)控模塊108報告該情況。如果在步驟218中確定該消息不是死信或者在步驟222中確定已經(jīng)成功處理了該消息,則隊列管理器集群103向應(yīng)用104發(fā)送該消息。在步驟228中,應(yīng)用104從隊列管理器集群103接收消息并對所接收到的消息進行處理。然后,在可選步驟230中,確定是否成功處理了所接收到的消息。如果在步驟230中確定沒有成功處理所接收到的消息,則在步驟232中,沒有成功處理的消息被放入異常處理模塊中進行處理。然后,在可選步驟234中,確定是否已經(jīng)成功處理了該消息。如果在預(yù)定時間間隔之后,仍然沒有成功處理該消息,則在步驟236中,向監(jiān)控模塊108報告該情況。如果在步驟230中確定已經(jīng)成功處理了該消息或者在步驟234中確定已經(jīng)成功處理了該消息,則該流程圖200結(jié)束。應(yīng)當(dāng)理解,對于上述流程圖200中的可選步驟206、210、218、222、230和234,可以同時應(yīng)用所有的可選步驟,也可以選擇性地應(yīng)用以上可選步驟中的一個或多個。例如,在可選步驟206、210、218、222、230和234當(dāng)中,可以僅應(yīng)用可選步驟206。替代地,可以應(yīng)用可選步驟206和218,等等。而且,在根據(jù)本發(fā)明的一個實施例中,在應(yīng)用102向隊列管理器集群103發(fā)送消息之前,注冊模塊106可以對消息進行匹配檢查。僅當(dāng)消息匹配時,才繼續(xù)后續(xù)操作。圖3圖示了根據(jù)本發(fā)明的實施例的在隊列管理器集群中消息的一個處理流程圖。在隊列管理器是隊列管理器集群的情況下,如圖3所示,流程圖200可以進一步包括以下步驟。在步驟302中,確定隊列管理器集群103中的一個隊列管理器(例如,隊列管理器114)未能正常工作。然后,在步驟304中,隔離該未能正常工作的隊列管理器,使得不會再有新的消息路由到該隊列管理器。在步驟306中,由其余的隊列管理器(例如,隊列管理器116)接管未能正常工作的隊列管理器的工作。根據(jù)本發(fā)明的基于消息隊列的分布式方法和系統(tǒng)針對現(xiàn)有MQ解決方案中的諸多問題改進了現(xiàn)有大規(guī)模分布式系統(tǒng)MQ解決方案,提高了系統(tǒng)性能、穩(wěn)定性和安全性。上述實施例僅是本發(fā)明的優(yōu)選實施例,并不用于限制本發(fā)明。對本領(lǐng)域技術(shù)人員顯而易見的是,在不脫離本發(fā)明的精神和范圍的情況下,可以對本發(fā)明的實施例進行各種修改和改變。因此,本發(fā)明意在涵蓋落入如權(quán)利要求所限定的本發(fā)明的范圍之內(nèi)的所有這樣的修改或變型。
權(quán)利要求
1.一種基于消息隊列的分布式方法,包括由第一應(yīng)用向隊列管理器發(fā)送消息;確定所述消息是否成功發(fā)送;如果確定沒有成功發(fā)送所述消息,則所述消息被放入第一異常處理模塊進行處理; 如果確定已經(jīng)成功發(fā)送所述消息,則由所述隊列管理器對所接收到的消息進行處理; 將所述消息發(fā)送到第二應(yīng)用;以及由所述第二應(yīng)用對所接收到的消息進行處理。
2.根據(jù)權(quán)利要求1所述的方法,其中所述由所述隊列管理器對所接收到的消息進行處理的步驟進一步包括確定所述消息是否是死信;以及如果確定所述消息是死信,則所述消息被放入死信處理模塊以進行處理。
3.根據(jù)權(quán)利要求1所述的方法,其中所述由第二應(yīng)用對所接收到的消息進行處理的步驟進一步包括確定所述第二應(yīng)用是否已經(jīng)成功處理了所述消息;以及如果確定沒有成功處理所述消息,則所述消息被放入第二異常處理模塊進行處理。
4.根據(jù)權(quán)利要求1所述的方法,其中所述消息被放入第一異常處理模塊進行處理的步驟進一步包括確定所述第一異常處理模塊是否已經(jīng)成功處理了所述消息;如果確定沒有成功處理所述消息,則向監(jiān)控模塊報告該情況;以及如果確定已經(jīng)成功處理了所述消息,則將所述消息發(fā)送到所述隊列管理器。
5.根據(jù)權(quán)利要求2所述的方法,其中所述消息被放入死信處理模塊以進行處理的步驟進一步包括確定所述死信處理模塊是否已經(jīng)成功處理所述消息;以及如果確定沒有成功處理所述消息,則向監(jiān)控模塊報告該情況。
6.根據(jù)權(quán)利要求3所述的方法,其中所述消息被放入第二異常處理模塊進行處理的步驟進一步包括確定所述第二異常處理模塊是否已經(jīng)成功處理了所述消息;以及如果確定沒有成功處理所述消息,則向監(jiān)控模塊報告該情況。
7.根據(jù)權(quán)利要求1所述的方法,其中在所述第一應(yīng)用向所述隊列管理器發(fā)送所述消息之前,注冊模塊可以對所述消息進行匹配檢查,并且僅當(dāng)所述消息匹配時,才繼續(xù)后續(xù)操作。
8.根據(jù)權(quán)利要求1所述的方法,其中所述隊列管理器是隊列管理器集群。
9.根據(jù)權(quán)利要求8所述的方法,其中所述由隊列管理器對所接收到的消息進行處理進一步包括確定所述隊列管理器集群中的一個隊列管理器未能正常工作;隔離所述一個隊列管理器,使得不會再有新的消息路由到所述一個隊列管理器;以及由其余的隊列管理器接管所述一個隊列管理器的工作。
10.根據(jù)權(quán)利要求4所述的方法,其中所述確定所述第一異常處理模塊是否已經(jīng)成功處理了所述消息的步驟在預(yù)定時間間隔之后執(zhí)行。
11.根據(jù)權(quán)利要求5所述的方法,其中所述確定所述死信處理模塊是否已經(jīng)成功處理所述消息的步驟在預(yù)定時間間隔之后執(zhí)行。
12.根據(jù)權(quán)利要求6所述的方法,其中所述確定所述第二異常處理模塊是否已經(jīng)成功處理了所述消息的步驟在預(yù)定時間間隔之后執(zhí)行。
13.—種基于消息隊列的分布式系統(tǒng),包括第一應(yīng)用,所述第一應(yīng)用被配置成向隊列管理器發(fā)送消息;第一異常處理模塊,所述第一異常處理模塊連接到所述第一應(yīng)用,并且被配置成對所述第一應(yīng)用沒有成功發(fā)送的消息進行處理;隊列管理器,所述隊列管理器與所述第一應(yīng)用和所述第一異常處理模塊相連,并且被配置成對所接收到的消息進行處理并且將所述消息發(fā)送到第二應(yīng)用;以及第二應(yīng)用,所述第二應(yīng)用連接到所述隊列管理器,并且被配置成對所接收到的消息進行處理。
14.根據(jù)權(quán)利要求13所述的系統(tǒng),進一步包括監(jiān)控模塊,所述監(jiān)控模塊被配置成對所述第一應(yīng)用、所述隊列管理器和所述第二應(yīng)用進行監(jiān)控。
15.根據(jù)權(quán)利要求13或14所述的系統(tǒng),其中所述隊列管理器進一步包括死信處理模塊,所述死信處理模塊被配置成對死信進行處理。
16.根據(jù)權(quán)利要求13或14所述的系統(tǒng),其中所述第二應(yīng)用進一步包括第二異常處理模塊,所述第二異常處理模塊被配置成對所述第二應(yīng)用沒有成功處理的消息進行處理。
17.根據(jù)權(quán)利要求14所述的系統(tǒng),其中所述第一異常處理模塊進一步被配置成確定是否已經(jīng)成功處理了所述消息;如果確定沒有成功處理所述消息,則向所述監(jiān)控模塊報告該情況;以及如果確定已經(jīng)成功處理了所述消息,則將所述消息發(fā)送到所述隊列管理器。
18.根據(jù)權(quán)利要求15所述的系統(tǒng),其中所述死信處理模塊進一步被配置成確定所述死信處理模塊是否已經(jīng)成功處理所述消息;以及如果確定沒有成功處理所述消息,則向所述監(jiān)控模塊報告該情況。
19.根據(jù)權(quán)利要求16所述的系統(tǒng),其中所述第二異常處理模塊進一步被配置成確定是否已經(jīng)成功處理了所述消息;以及如果確定沒有成功處理所述消息,則向所述監(jiān)控模塊報告該情況。
20.根據(jù)權(quán)利要求13所述的系統(tǒng),進一步包括注冊模塊,所述注冊模塊被配置成對所述消息進行匹配檢查,并且僅當(dāng)所述消息匹配時,才繼續(xù)后續(xù)操作。
21.根據(jù)權(quán)利要求13所述的系統(tǒng),其中所述隊列管理器是隊列管理器集群。
22.根據(jù)權(quán)利要求21所述的系統(tǒng),其中所述隊列管理器集群進一步被配置成確定所述隊列管理器集群中的一個隊列管理器未能正常工作;隔離所述一個隊列管理器,使得不會再有新的消息路由到所述一個隊列管理器;以及由其余的隊列管理器接管所述一個隊列管理器的工作。
23.根據(jù)權(quán)利要求17所述的系統(tǒng),其中所述第一異常處理模塊進一步被配置成在預(yù)定時間間隔之后,確定是否已經(jīng)成功處理了所述消息。
24.根據(jù)權(quán)利要求18所述的系統(tǒng),其中所述死信處理模塊進一步被配置成在預(yù)定時間間隔之后,確定是否已經(jīng)成功處理所述消息。
25.根據(jù)權(quán)利要求19所述的系統(tǒng),其中所述第二異常處理模塊進一步被配置成在預(yù)定時間 間隔之后,確定是否已經(jīng)成功處理了所述消息。
全文摘要
本發(fā)明提供一種基于消息隊列的分布式方法和系統(tǒng)。該基于消息隊列的分布式方法包括由第一應(yīng)用向隊列管理器發(fā)送消息;確定所述消息是否成功發(fā)送;如果確定沒有成功發(fā)送所述消息,則所述消息被放入第一異常處理模塊進行處理;如果確定已經(jīng)成功發(fā)送所述消息,則由所述隊列管理器對所接收到的消息進行處理;將所述消息發(fā)送到第二應(yīng)用;以及由所述第二應(yīng)用對所接收到的消息進行處理。
文檔編號G06F9/54GK103019866SQ20121041048
公開日2013年4月3日 申請日期2012年10月24日 優(yōu)先權(quán)日2012年10月24日
發(fā)明者李鵬濤 申請人:北京京東世紀(jì)貿(mào)易有限公司
網(wǎng)友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點贊!
1
桐乡市| 贺州市| 大石桥市| 霍山县| 兴仁县| 大名县| 龙口市| 南木林县| 柳河县| 体育| 盖州市| 突泉县| 增城市| 林芝县| 托里县| 桐梓县| 合川市| 东明县| 株洲县| 合水县| 临高县| 文化| 屏山县| 尉氏县| 赣州市| 大兴区| 随州市| 龙海市| 高台县| 叙永县| 舟曲县| 鄯善县| 通渭县| 双辽市| 成武县| 东阿县| 吉木萨尔县| 永川市| 嵊州市| 休宁县| 平顺县|