本發(fā)明關(guān)于一種互聯(lián)網(wǎng)消息交互技術(shù)領(lǐng)域，特別是涉及一種高可靠的消息訂閱處理裝置、系統(tǒng)及方法。

背景技術(shù)：

企業(yè)和政府部門的IT系統(tǒng)環(huán)境中擁有多種操作系統(tǒng)、數(shù)據(jù)庫、異構(gòu)的網(wǎng)絡(luò)環(huán)境和多種應(yīng)用。在當(dāng)前信息數(shù)據(jù)大爆炸的背景下，各個系統(tǒng)應(yīng)用之間存在非常多的數(shù)據(jù)共享和數(shù)據(jù)交換需求。如何把不同的平臺的異構(gòu)系統(tǒng)結(jié)合成一個有機(jī)的協(xié)同工作整體，真正實(shí)現(xiàn)跨平臺分布式應(yīng)用成為當(dāng)務(wù)之急。消息中間件正是為解決多方應(yīng)用系統(tǒng)之間信息互通、信息孤島、應(yīng)用數(shù)據(jù)丟失、網(wǎng)絡(luò)環(huán)境差導(dǎo)致的數(shù)據(jù)傳輸不穩(wěn)定、應(yīng)用資源隔離、應(yīng)用系統(tǒng)可擴(kuò)展性等一系列問題而生的中間件產(chǎn)品。

Kafka是當(dāng)前比較出色的一款高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)。Kafka的消息訂閱者通常將從某個Partition(分區(qū))讀取的最后一條消息的offset(偏移量)存于ZooKeeper(或消息存儲節(jié)點(diǎn))中，當(dāng)消費(fèi)完消息后，再次將最后一條消息的offset信息更新到ZooKeeper(或消息存儲節(jié)點(diǎn))中，這樣可以保證不斷消費(fèi)到新的消息而不重復(fù)消費(fèi)。

可是，在實(shí)際應(yīng)用中，常常會有如下復(fù)雜的消息消費(fèi)需求：當(dāng)一個消息訂閱者讀取了一批消息后還沒有完全消費(fèi)完畢就異常終止了，如果從原來的offset之后重新讀取消息進(jìn)行消費(fèi)就會重復(fù)消費(fèi)那些已經(jīng)消費(fèi)的消息；而如果從上一次異常時讀取到的最后一條消息的offset之后讀取新的消息就會因?yàn)橛胁糠窒]有被消費(fèi)而發(fā)生消息丟失的問題。在某些場景下，我們讀取的一批消息，不希望一下子完全消費(fèi)完再讀取下一批消息，而是希望允許某些消息還沒有消費(fèi)完畢的情況下，繼續(xù)讀取下一批消息。有時，消息訂閱者讀取到一批消息后，希望根據(jù)自己的處理情況在指定的時間之后重新消費(fèi)某些消息。如上這些情況下，如果采用現(xiàn)有的技術(shù)方案，包含Kafka系統(tǒng)，均無法解決“訂閱者異常造成的消費(fèi)消息丟失”、“跳躍消費(fèi)消息”和“定時重投消息”等問題。

技術(shù)實(shí)現(xiàn)要素：

為克服上述現(xiàn)有技術(shù)存在的不足，本發(fā)明之目的在于提供一種消息訂閱處理裝置、系統(tǒng)及方法，以解決現(xiàn)有技術(shù)存在的訂閱者異常造成的消費(fèi)消息丟失、跳躍消費(fèi)消息和定時重投消息等問題。

為達(dá)上述及其它目的，本發(fā)明提出一種消息訂閱處理裝置，應(yīng)用于消息服務(wù)器，包括：

消息存儲模塊，用于存儲具體的消息，并向其他模塊提供消息存取服務(wù)；

消息配置管理模塊，用于管理被訂閱主題和訂閱消息的消息訂閱端的配置信息；

消費(fèi)狀態(tài)管理模塊，用于存儲消費(fèi)狀態(tài)為待消費(fèi)或消費(fèi)中的消息，并記錄當(dāng)前消息服務(wù)器上所有被訂閱主題里面所屬隊(duì)列中的所有消息被某個訂閱端的消費(fèi)情況，根據(jù)訂閱端對消息的消費(fèi)和簽收情況對被訂閱主題中的消息的消費(fèi)情況進(jìn)行管理；

消費(fèi)進(jìn)度管理模塊，用于管理某個訂閱者消費(fèi)某個主題的進(jìn)度信息；

訂閱請求接收模塊，用于接收消息訂閱端發(fā)送的訂閱消息的請求；

消費(fèi)進(jìn)度查詢模塊，根據(jù)該請求中的主題和隊(duì)列信息于所述消費(fèi)進(jìn)度管理模塊中查詢消費(fèi)進(jìn)度；

待消費(fèi)消息獲取模塊，于該消息狀態(tài)管理模塊中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息；

消息發(fā)送模塊，用于將獲取的消息發(fā)送給消息訂閱端。

反饋處理模塊，用于接收消息訂閱端的反饋信息，并根據(jù)消息訂閱端的反饋信息于修改消息的消費(fèi)狀態(tài)及消費(fèi)進(jìn)度。

進(jìn)一步地，該消息訂閱處理裝置還包括判斷處理模塊，該判斷處理模塊用于判斷該待消費(fèi)消息獲取模塊獲取的待消費(fèi)消息個數(shù)是否小于訂閱請求中指定的消息個數(shù)，若判斷結(jié)果為獲取的待消費(fèi)消息個數(shù)小于訂閱請求中指定的消息個數(shù)，則從該消息存儲模塊中繼續(xù)獲取消息后，再進(jìn)入該消息發(fā)送模塊。

進(jìn)一步地，從該消息存儲模塊中繼續(xù)獲取消息的步驟如下：

從該消息狀態(tài)管理模塊中獲取對應(yīng)主題對應(yīng)隊(duì)列中緩存消息的最大偏移量；

從該消息存儲模塊中取出該偏移量之后的若干條消息，將該些消息緩存到消息狀態(tài)管理模塊中，并標(biāo)記該些消息的消費(fèi)狀態(tài)為消費(fèi)中。

進(jìn)一步地，該反饋處理模塊進(jìn)一步包括：

重試請求處理模塊，若接收到的消息訂閱端的反饋信息為重試請求，則于該消費(fèi)狀態(tài)管理模塊中將對應(yīng)消息的消息狀態(tài)由消費(fèi)中改為待消費(fèi)，處理結(jié)束；

簽收請求處理模塊，若接收到的消息訂閱端的反饋信息為簽收請求，則于該消費(fèi)狀態(tài)管理模塊中刪除對應(yīng)消息，并于該消費(fèi)狀態(tài)管理模塊中沒有小于該消息對應(yīng)偏移量的待消費(fèi)或者消費(fèi)中的消息時，設(shè)置消費(fèi)進(jìn)度為該消息對應(yīng)的偏移量。

進(jìn)一步地，該重試請求處理模塊進(jìn)一步執(zhí)行如下步驟：

若接收到的消息重試請求中包括重投時間，于該消費(fèi)狀態(tài)管理模塊中設(shè)置對應(yīng)重試消息為待消費(fèi)狀態(tài)并記錄重投時間；

接收消息訂閱端再次發(fā)起的訂閱消息請求；

如果重投消息重投時間已到，則從該消費(fèi)狀態(tài)管理模塊獲取狀態(tài)為待消費(fèi)的待重投消息，發(fā)送給消息訂閱端，否則返回繼續(xù)等待。

進(jìn)一步地，該消息訂閱處理裝置還包括：

故障檢測模塊，用于檢測到消息訂閱端發(fā)生故障；

故障處理模塊，用于將故障的消息訂閱端中沒有簽收的消息的消費(fèi)狀態(tài)由消費(fèi)中改為待消費(fèi)。

為達(dá)到上述目的，本發(fā)明還提供一種消息訂閱處理系統(tǒng)，包括：

消息訂閱處理裝置，應(yīng)用于消息服務(wù)器端，用于接收消息訂閱端發(fā)送的訂閱消息的請求，根據(jù)請求中的主題和隊(duì)列信息查詢消費(fèi)進(jìn)度，于消息狀態(tài)管理模塊中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息，并將獲取的消息發(fā)送給消息訂閱端，根據(jù)消息訂閱端的反饋信息修改消息的消費(fèi)狀態(tài)及消費(fèi)進(jìn)度；

消息訂閱端，用于從該消息訂閱處理裝置接收消息，對消息進(jìn)行相關(guān)業(yè)務(wù)處理，并向消息訂閱處理裝置發(fā)送反饋信息。

為達(dá)到上述目的，本發(fā)明還提供一種消息訂閱處理方法，包括如下步驟：

步驟一，接收消息訂閱端發(fā)送的訂閱消息的請求；

步驟二，根據(jù)請求中的主題和隊(duì)列信息查詢消費(fèi)進(jìn)度；

步驟三，于消息狀態(tài)管理模塊中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息；

步驟四，將獲取的消息發(fā)送給消息訂閱端；

步驟五，接收消息訂閱端的反饋信息，并根據(jù)消息訂閱端的反饋信息修改消息的消費(fèi)狀態(tài)及消費(fèi)進(jìn)度。

進(jìn)一步地，于步驟四之前，還包括如下步驟：

若獲取的待消費(fèi)消息個數(shù)小于訂閱請求中指定的消息個數(shù)，則從消息存儲模塊中繼續(xù)獲取消息，否則直接進(jìn)入步驟四。

進(jìn)一步地，步驟五進(jìn)一步包括：

若接收到的消息訂閱端的反饋信息為重試請求，則于消費(fèi)狀態(tài)管理模塊中將對應(yīng)消息的消息狀態(tài)由消費(fèi)中改為待消費(fèi)，處理結(jié)束；

若接收到的消息訂閱端的反饋信息為簽收請求，則在消費(fèi)狀態(tài)管理模塊中刪除對應(yīng)消息；

若該消費(fèi)狀態(tài)管理模塊中沒有小于該消息對應(yīng)偏移量的待消費(fèi)或者消費(fèi)中的消息，設(shè)置消費(fèi)進(jìn)度為該消息對應(yīng)的偏移量，處理結(jié)束。

與現(xiàn)有技術(shù)相比，本發(fā)明一種消息訂閱處理裝置、系統(tǒng)及方法，通過利用消息存儲模塊存儲具體的消息、消息配置管理模塊管理被訂閱主題和訂閱消息的消息訂閱端的配置信息、消費(fèi)狀態(tài)管理模塊存儲消費(fèi)狀態(tài)為待消費(fèi)或消費(fèi)中的消息以及消費(fèi)進(jìn)度管理模塊管理訂閱端消費(fèi)訂閱主題的進(jìn)度信息，于接收訂閱端發(fā)送的訂閱消息的請求時，根據(jù)請求中的主題和隊(duì)列信息查詢消費(fèi)進(jìn)度，于消息狀態(tài)管理模塊中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息，并將獲取的消息發(fā)送給消息訂閱端，根據(jù)消息訂閱端的反饋信息修改消息的消費(fèi)狀態(tài)及消費(fèi)進(jìn)度，實(shí)現(xiàn)了高可靠的分布式消息訂閱的目的，并解決了現(xiàn)有技術(shù)中訂閱端異常造成的消費(fèi)消息丟失、跳躍消費(fèi)消息以及定時重投消息等問題。

附圖說明

圖1為本發(fā)明一種消息訂閱處理裝置的系統(tǒng)架構(gòu)圖；

圖2為本發(fā)明一種消息訂閱處理系統(tǒng)的系統(tǒng)架構(gòu)圖；

圖3為本發(fā)明具體實(shí)施例中消息訂閱端21的細(xì)部結(jié)構(gòu)圖；

圖4為本發(fā)明一種消息訂閱處理方法的步驟流程圖；

圖5為本發(fā)明實(shí)施例一的步驟流程圖；

圖6為本發(fā)明實(shí)施例二的步驟流程圖；

圖7為本發(fā)明實(shí)施例三的步驟流程圖。

具體實(shí)施方式

以下通過特定的具體實(shí)例并結(jié)合附圖說明本發(fā)明的實(shí)施方式，本領(lǐng)域技術(shù)人員可由本說明書所揭示的內(nèi)容輕易地了解本發(fā)明的其它優(yōu)點(diǎn)與功效。本發(fā)明亦可通過其它不同的具體實(shí)例加以施行或應(yīng)用，本說明書中的各項(xiàng)細(xì)節(jié)亦可基于不同觀點(diǎn)與應(yīng)用，在不背離本發(fā)明的精神下進(jìn)行各種修飾與變更。

圖1為本發(fā)明一種消息訂閱處理裝置的系統(tǒng)架構(gòu)圖。如圖1所示，本發(fā)明一種消息訂閱處理裝置，應(yīng)用于消息服務(wù)器端，包括：消息存儲模塊101、消息配置管理模塊102、消費(fèi)狀態(tài)管理模塊103、消費(fèi)進(jìn)度管理模塊104、訂閱請求接收模塊105、消費(fèi)進(jìn)度查詢模塊106、待消費(fèi)消息獲取模塊107、消息發(fā)送模塊108以及反饋處理模塊109。

其中，消息存儲模塊101，用于存儲具體的消息，并向其他模塊提供消息存取服務(wù)。

消息配置管理模塊102，用于管理被訂閱主題和訂閱消息的消息訂閱端的配置信息。一個主題可以有多個隊(duì)列(或分區(qū))，這些隊(duì)列可以分布到多個不同的消息服務(wù)器上。

消費(fèi)狀態(tài)管理模塊103，用于存儲消費(fèi)狀態(tài)為待消費(fèi)或消費(fèi)中的消息，并記錄當(dāng)前消息服務(wù)器上所有被訂閱主題里面所屬隊(duì)列中的所有消息被某個訂閱者的消費(fèi)情況，并根據(jù)消息訂閱端對消息的消費(fèi)和簽收情況對被訂閱者主題中的消息的消費(fèi)情況進(jìn)行管理。

消費(fèi)進(jìn)度管理模塊104，用于管理某個訂閱端消費(fèi)某個主題的進(jìn)度信息。主題隊(duì)列中的消息從隊(duì)頭開始消費(fèi)到隊(duì)尾，中間允許跳躍消費(fèi)，第一個跳躍點(diǎn)前面被消費(fèi)過的消息的在隊(duì)列中的偏移量稱之為該主題的某個隊(duì)列被訂閱端消費(fèi)的消費(fèi)進(jìn)度。

訂閱請求接收模塊105，用于接收消息訂閱端發(fā)送的訂閱消息的請求。具體地，該請求中包括訂閱主題名稱、主題隊(duì)列編號和訂閱消息的個數(shù)等信息。

消費(fèi)進(jìn)度查詢模塊106，根據(jù)該請求中的主題和隊(duì)列信息于消費(fèi)進(jìn)度管理模塊104中查詢消費(fèi)進(jìn)度。具體地，消費(fèi)進(jìn)度管理模塊管理著某個訂閱端消費(fèi)某個主題的進(jìn)度信息，消費(fèi)進(jìn)度指的是某個訂閱組消費(fèi)某個主題中某個隊(duì)列中消息的偏移量，在這個偏移量之前的消息(包括當(dāng)前偏移量對應(yīng)的消息)全部都被該訂閱組消費(fèi)過。

待消費(fèi)消息獲取模塊107，于消息狀態(tài)管理模塊103中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息。具體地，消息狀態(tài)管理模塊緩存那些正在被消費(fèi)或即將被消費(fèi)的消息，當(dāng)消息被消費(fèi)后會從消息狀態(tài)管理模塊中刪除，所以通常情況下消息狀態(tài)管理模塊中的消息在隊(duì)列中對應(yīng)的偏移量都會大于當(dāng)前的消費(fèi)進(jìn)度。

消息發(fā)送模塊108，用于將獲取的消息發(fā)送給消息訂閱端。

反饋處理模塊109，用于接收消息訂閱端的反饋信息，并根據(jù)消息訂閱端的反饋信息修改消息的消費(fèi)狀態(tài)及消費(fèi)進(jìn)度。

具體地，反饋處理模塊109進(jìn)一步包括：

重試請求處理模塊，若接收到的消息訂閱端的反饋信息為重試請求，則于消費(fèi)狀態(tài)管理模塊103中將對應(yīng)消息的消息狀態(tài)由消費(fèi)中改為待消費(fèi)，處理結(jié)束。具體地，在消費(fèi)狀態(tài)管理模塊中將需要重試消費(fèi)的消息的消費(fèi)狀態(tài)由消費(fèi)中改為待消費(fèi)，保證了訂閱組下一次拉取消息時可以重新獲取到該消息。

簽收請求處理模塊，若接收到的消息訂閱端的反饋信息為簽收請求，則在消費(fèi)狀態(tài)管理模塊103中刪除對應(yīng)消息，并于消費(fèi)狀態(tài)管理模塊103中沒有小于該消息對應(yīng)偏移量的待消費(fèi)或者消費(fèi)中的消息時，設(shè)置消費(fèi)進(jìn)度為該消息對應(yīng)的偏移量，處理結(jié)束。具體地說，簽收的消息在隊(duì)列中對應(yīng)的偏移量之前可能還有其他消息沒有被簽收，這個時候不可以更新消費(fèi)進(jìn)度，只有當(dāng)簽收的消息對應(yīng)的偏移量之前的所有消息都已經(jīng)被簽收了，才可以更新訂閱組在當(dāng)前主題當(dāng)前隊(duì)列中的消費(fèi)進(jìn)度。

較佳地，本發(fā)明之消息訂閱處理裝置還包括判斷處理模塊110，用于判斷待消費(fèi)消息獲取模塊107獲取的待消費(fèi)消息個數(shù)是否小于訂閱請求中指定的消息個數(shù)，若判斷結(jié)果為獲取的待消費(fèi)消息個數(shù)小于訂閱請求中指定的消息個數(shù)，則從消息存儲模塊101中繼續(xù)獲取消息，再進(jìn)入消息發(fā)送模塊108。也就是說，若待消費(fèi)消息獲取模塊107獲取的待消費(fèi)消息個數(shù)小于訂閱請求中指定的消息個數(shù)，即，消息狀態(tài)管理模塊中緩存的待消費(fèi)的消息不足夠時，則需要從消息存儲模塊101中繼續(xù)獲取消息，從消息存儲模塊101中繼續(xù)獲取消息的步驟如下：

從消息狀態(tài)管理模塊103中獲取對應(yīng)主題對應(yīng)隊(duì)列中緩存消息的最大偏移量，具體地，消息狀態(tài)管理模塊103記錄了需要從消息存儲模塊101中獲取消息的起始偏移量信息，這個起始偏移量信息在消息狀態(tài)管理模塊103中對應(yīng)所有緩存消息在隊(duì)列中對應(yīng)的最大偏移量；

從消息存儲模塊101中取出該偏移量之后的若干條消息，將該些消息的標(biāo)識(包括主題名稱、主題隊(duì)列編號、消息在隊(duì)列中對應(yīng)的偏移量和訂閱者的連接信息等)緩存到消息狀態(tài)管理模塊中，并標(biāo)記這些消息的消費(fèi)狀態(tài)為消費(fèi)中。

在本發(fā)明中，當(dāng)消息訂閱端進(jìn)行消息業(yè)務(wù)處理后不簽收消息進(jìn)行消息重試并設(shè)定重投時間時，本發(fā)明可以實(shí)現(xiàn)定時重投，較佳地，重試請求處理模塊還可執(zhí)行如下步驟：

若接收到的消息重試請求中包括重投時間，于消費(fèi)狀態(tài)管理模塊中設(shè)置對應(yīng)重試消息為待消費(fèi)狀態(tài)并記錄重投時間；

接收消息訂閱端再次發(fā)起的訂閱消息請求；

如果重投消息重投時間已到，則從消費(fèi)狀態(tài)管理模塊獲取狀態(tài)為待消費(fèi)的待重投消息，發(fā)送給消息訂閱端，否則返回繼續(xù)等待。

這里需說明的是，對于那些不需要進(jìn)行重投的消息，于消費(fèi)狀態(tài)管理模塊中將重投時間設(shè)置為消息生成的時間，表明不需要等待消息就可以被獲取。

另外，由于消息訂閱端在消費(fèi)消息過程中有可能會產(chǎn)生故障，因此，較佳地，本發(fā)明之消息訂閱處理裝置還可包括：

故障檢測模塊，用于檢測到消息訂閱端發(fā)生故障；

在本發(fā)明具體實(shí)施例中，故障檢測模塊是通過接收消息訂閱端發(fā)送的心跳信號檢測消息訂閱端是否發(fā)生故障的，也就是說或，消息訂閱端故障后，消息服務(wù)器與消息訂閱端的長連接會斷開。消息訂閱端每隔一段時間向消息服務(wù)器發(fā)送心跳，告訴消息服務(wù)器訂閱端還活著，消息服務(wù)器上會保存消息訂閱端的連接信息，如果超過一定時間未接收到消息訂閱端發(fā)送的心跳信號，則消息服務(wù)器會認(rèn)為消息訂閱端故障。

故障處理模塊，用于將故障的消息訂閱端中沒有簽收的消息的消費(fèi)狀態(tài)由消費(fèi)中改為待消費(fèi)。這樣新的消息訂閱端會重新消費(fèi)到上述未簽收的消息。

具體地，新的消息訂閱端將優(yōu)先獲取到消費(fèi)狀態(tài)管理模塊中處于待消費(fèi)狀態(tài)的消息，并重新進(jìn)行消費(fèi)和簽收。

圖2為本發(fā)明一種消息訂閱處理系統(tǒng)的系統(tǒng)架構(gòu)圖。如圖2所示，本發(fā)明一種消息訂閱處理系統(tǒng)，包括：

消息訂閱處理裝置20，應(yīng)用于消息服務(wù)器端，用于接收消息訂閱端發(fā)送的訂閱消息的請求，根據(jù)請求中的主題和隊(duì)列信息查詢消費(fèi)進(jìn)度，于消息狀態(tài)管理模塊中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息，并將獲取的消息發(fā)送給消息訂閱端，根據(jù)消息訂閱端的反饋信息修改消息的消費(fèi)狀態(tài)及消費(fèi)進(jìn)度。由于消息訂閱處理裝置20已于裝置項(xiàng)中予以詳述，在此不予贅述；

消息訂閱端21，用于從消息訂閱處理裝置接收消息，對消息進(jìn)行相關(guān)業(yè)務(wù)處理，并向消息訂閱處理裝置發(fā)送反饋信息，該反饋信息包括簽收請求以及消息重試請求。

圖3為本發(fā)明具體實(shí)施例中消息訂閱端21的細(xì)部結(jié)構(gòu)圖。如圖3所示，該消息訂閱端21包括包括消息接收模塊210、消息處理模塊211和消息簽收模塊212。

其中，消息接收模塊210，用于從消息訂閱處理裝置20接收消息；消息處理模塊211，用于對接收到的消息進(jìn)行相關(guān)業(yè)務(wù)處理；消息簽收模塊212，用于用于消息業(yè)務(wù)處理完畢之后的消息確認(rèn)或消息重試操作，向消息訂閱處理裝置20反饋簽收請求或消息重試請求，如果消息被確認(rèn)，則消息訂閱處理裝置20認(rèn)為該條消息已經(jīng)被訂閱者消費(fèi)過，消息訂閱端不需要再獲取該條消息；如果消息被重試，則消息訂閱處理裝置20認(rèn)為該條消息還沒有被消費(fèi)過，消息訂閱端需要重新獲取該條消息，較佳地，為提升簽收和重試性能，消息簽收模塊212可以批量發(fā)送簽收或重試請求。

圖4為本發(fā)明一種消息訂閱處理方法的步驟流程圖。如圖4所示，本發(fā)明一種消息訂閱處理方法，包括如下步驟：

步驟401，接收消息訂閱端發(fā)送的訂閱消息的請求；

具體地，該請求中包括訂閱主題名稱、主題隊(duì)列編號和訂閱消息的個數(shù)等信息。

步驟402，根據(jù)請求中的主題和隊(duì)列信息查詢消費(fèi)進(jìn)度。具體地，本發(fā)明中，消費(fèi)進(jìn)度管理模塊管理著某個訂閱者消費(fèi)某個主題的進(jìn)度信息，消費(fèi)進(jìn)度指的是某個訂閱組消費(fèi)某個主題中某個隊(duì)列中消息的偏移量，在這個偏移量之前的消息(包括當(dāng)前偏移量對應(yīng)的消息)全部都被該訂閱組消費(fèi)過。

步驟403，于消息狀態(tài)管理模塊中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息；

具體地，消息狀態(tài)管理模塊緩存那些正在被消費(fèi)或即將被消費(fèi)的消息，當(dāng)消息被消費(fèi)后會從消息狀態(tài)管理模塊中刪除，所以通常情況下消息狀態(tài)管理模塊中的消息在隊(duì)列中對應(yīng)的偏移量都會大于當(dāng)前的消費(fèi)進(jìn)度。

步驟404，將獲取的消息發(fā)送給消息訂閱端。

步驟405，接收消息訂閱端的反饋信息，并根據(jù)消息訂閱端的反饋信息修改消息的消費(fèi)狀態(tài)及消費(fèi)進(jìn)度。

具體地，步驟405進(jìn)一步包括：

步驟5.1，若接收到的消息訂閱端的反饋信息為重試請求，則于消費(fèi)狀態(tài)管理模塊中將對應(yīng)消息的消息狀態(tài)由消費(fèi)中改為待消費(fèi)，處理結(jié)束。

具體地，于步驟5.1中，在消費(fèi)狀態(tài)管理模塊中將需要重試消費(fèi)的消息的消費(fèi)狀態(tài)由消費(fèi)中改為待消費(fèi)，保證了訂閱組下一次拉取消息時可以重新獲取到該消息。

步驟5.2，若接收到的消息訂閱端的反饋信息為簽收請求，則在消費(fèi)狀態(tài)管理模塊中刪除對應(yīng)消息；

步驟5.3，若消費(fèi)狀態(tài)管理模塊中沒有小于該消息對應(yīng)偏移量的待消費(fèi)或者消費(fèi)中的消息，設(shè)置消費(fèi)進(jìn)度為該消息對應(yīng)的偏移量，處理結(jié)束。

具體地說，簽收的消息在隊(duì)列中對應(yīng)的偏移量之前可能還有其他消息沒有被簽收，這個時候不可以更新消費(fèi)進(jìn)度，只有當(dāng)簽收的消息對應(yīng)的偏移量之前的所有消息都已經(jīng)被簽收了，才可以更新訂閱組在當(dāng)前主題當(dāng)前隊(duì)列中的消費(fèi)進(jìn)度。

較佳地，于步驟404之前，本發(fā)明還包括如下步驟：

若獲取的待消費(fèi)消息個數(shù)小于訂閱請求中指定的消息個數(shù)，則從消息存儲模塊中繼續(xù)獲取消息，否則直接進(jìn)入步驟404。

具體地，若獲取的待消費(fèi)消息個數(shù)小于訂閱請求中指定的消息個數(shù)，也就是說消息狀態(tài)管理模塊中緩存的待消費(fèi)的消息不足夠時，需要從消息存儲模塊中繼續(xù)獲取消息，從消息存儲模塊中繼續(xù)獲取消息的步驟進(jìn)一步包括如下步驟：

步驟S11，從消息狀態(tài)管理模塊中獲取對應(yīng)主題對應(yīng)隊(duì)列中緩存消息的最大偏移量。

具體地，消息狀態(tài)管理模塊記錄了需要從消息存儲模塊中獲取消息的起始偏移量信息，這個起始偏移量信息在消息狀態(tài)管理模塊中對應(yīng)所有緩存消息在隊(duì)列中對應(yīng)的最大偏移量。

步驟S12，從消息存儲模塊中取出該偏移量之后的若干條消息，緩存到消息狀態(tài)管理模塊中，并標(biāo)記這些消息的消費(fèi)狀態(tài)為消費(fèi)中。這里需說明的是，假如訂閱請求中指定的消息個數(shù)為N，消息狀態(tài)管理模塊中緩存的待消費(fèi)的消息個數(shù)為M，則從消息存儲模塊中取出該偏移量之后的N-M條消息。

在本發(fā)明中，當(dāng)消息訂閱端進(jìn)行消息業(yè)務(wù)處理后不簽收消息進(jìn)行消息重試并設(shè)定重投時間時，本發(fā)明可以實(shí)現(xiàn)定時重投，較佳地，于步驟405中，還包括如下步驟：

步驟S21，若接收到的消息重試請求中包括重投時間，于消費(fèi)狀態(tài)管理模塊中設(shè)置對應(yīng)重試消息為待消費(fèi)狀態(tài)并記錄重投時間；

步驟S22，接收消息訂閱端再次發(fā)起的訂閱消息請求；

步驟S23，如果重投消息重投時間已到，則從消費(fèi)狀態(tài)管理模塊獲取狀態(tài)為待消費(fèi)的待重投消息，發(fā)送給消息訂閱端，否則返回步驟S23繼續(xù)等待。

也就是說，這里當(dāng)消息服務(wù)器從消費(fèi)狀態(tài)管理模塊中獲取待消費(fèi)消息時，增加了判斷重投時間是否已到的判斷條件，如果對應(yīng)的待消費(fèi)消息沒有達(dá)到重投時間，則該消息會一直處于待消費(fèi)狀態(tài)。

這里需說明的是，對于那些不需要進(jìn)行重投的消息，消費(fèi)狀態(tài)管理模塊中將重投時間設(shè)置為消息生成的時間，表明不需要等待消息就可以被獲取。

由于消息訂閱端在消費(fèi)消息過程中有可能會產(chǎn)生故障，因此，較佳地，本發(fā)明之消息訂閱處理方法還包括如下步驟：

步驟S31，檢測到消息訂閱端發(fā)生故障；

在本發(fā)明具體實(shí)施例中，是通過接收消息訂閱端發(fā)送的心跳信號檢測消息訂閱端是否發(fā)生故障的，也就是說或，消息訂閱端故障后，消息服務(wù)器與消息訂閱端的長連接會斷開。消息訂閱端每隔一段時間向消息服務(wù)器發(fā)送心跳，告訴消息服務(wù)器訂閱端還活著，消息服務(wù)器上會保存消息訂閱端的連接信息，如果超過一定時間未接收到消息訂閱端發(fā)送的心跳信號，則消息服務(wù)器會認(rèn)為消息訂閱端故障。

步驟S32，將故障的消息訂閱端中沒有簽收的消息的消費(fèi)狀態(tài)由消費(fèi)中改為待消費(fèi)。這樣新的消息訂閱端會重新消費(fèi)到上述未簽收的消息。

具體地，新的消息訂閱端將優(yōu)先獲取到消費(fèi)狀態(tài)管理模塊中處于待消費(fèi)狀態(tài)的消息，并重新進(jìn)行消費(fèi)和簽收。

以下將配合具體實(shí)施例進(jìn)一步說明本發(fā)明之消息訂閱處理方法，在以下各實(shí)施例中，消息訂閱端也稱之為消息訂閱者，消息訂閱處理裝置也稱之為消息服務(wù)器。

實(shí)施例一

參見圖5，本實(shí)施例提供了一種消息訂閱處理方法，在該實(shí)施例中，

501，消息訂閱者(消息訂閱端)向消息服務(wù)器(消息訂閱處理裝置)發(fā)送訂閱消息的請求；

具體地，請求中包括訂閱主題名稱、主題隊(duì)列編號和訂閱消息的個數(shù)等信息。

502，消息服務(wù)器根據(jù)請求中的主題和隊(duì)列信息查詢消費(fèi)進(jìn)度；

具體地，消費(fèi)進(jìn)度指的是某個訂閱組消費(fèi)某個主題中某個隊(duì)列中消息的偏移量。在這個偏移量之前的消息(包括當(dāng)前偏移量對應(yīng)的消息)全部都被該訂閱組消費(fèi)過。

503，消息服務(wù)器從消息狀態(tài)管理模塊中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息；

具體地，消息狀態(tài)管理模塊緩存那些正在被消費(fèi)或即將被消費(fèi)的消息，當(dāng)消息被消費(fèi)后會從消息狀態(tài)管理模塊中刪除，所以通常情況下消息狀態(tài)管理模塊中的消息在隊(duì)列中對應(yīng)的偏移量都會大于當(dāng)前的消費(fèi)進(jìn)度。

504，判斷待消費(fèi)消息個數(shù)，如果獲取的待消費(fèi)消息個數(shù)小于訂閱請求中指定的消息個數(shù)，進(jìn)入下一步，否則直接進(jìn)入507；

也就是說，消息狀態(tài)管理模塊中緩存的待消費(fèi)的消息不足夠，需要從消息存儲模塊中繼續(xù)獲取消息。

505，消息服務(wù)器從消息狀態(tài)管理模塊中獲取對應(yīng)主題對應(yīng)隊(duì)列中緩存消息的最大偏移量；

具體地，消息狀態(tài)管理模塊記錄了需要從消息存儲模塊中獲取消息的起始偏移量信息，這個起始偏移量信息在消息狀態(tài)管理模塊中對應(yīng)所有緩存消息在隊(duì)列中對應(yīng)的最大偏移量。

506，消息服務(wù)器從消息存儲模塊中取出該偏移量之后的若干條消息，緩存到消息狀態(tài)管理模塊中，并標(biāo)記這些消息的消費(fèi)狀態(tài)為消費(fèi)中；

507，消息服務(wù)器將獲取的消息發(fā)送給消息訂閱者；

508，消息訂閱者的消息處理模塊對獲取到的消息進(jìn)行消息業(yè)務(wù)處理；

509，發(fā)送簽收或重試消息請求給消息服務(wù)器；

510，消息服務(wù)器收到簽收或重試請求；

511，如果是重試請求，消息服務(wù)器在消費(fèi)狀態(tài)管理模塊中將對應(yīng)消息的消息狀態(tài)由消費(fèi)中改為待消費(fèi)，處理結(jié)束。

具體地，在消費(fèi)狀態(tài)管理模塊中將需要重試消費(fèi)的消息的消費(fèi)狀態(tài)由消費(fèi)中改為了待消費(fèi)，保證了訂閱組下一次拉取消息時可以重新獲取到該消息。

512，如果是簽收請求，消息服務(wù)器在消費(fèi)狀態(tài)管理模塊中刪除對應(yīng)消息；

513，如果消費(fèi)狀態(tài)管理模塊中沒有小于該消息對應(yīng)偏移量的待消費(fèi)或者消費(fèi)中的消息，設(shè)置消費(fèi)進(jìn)度為該消息對應(yīng)的偏移量，處理結(jié)束。

具體地，簽收的消息在隊(duì)列中對應(yīng)的偏移量之前可能還有其他消息沒有被簽收，這個時候不可以更新消費(fèi)進(jìn)度，只有當(dāng)簽收的消息對應(yīng)的偏移量之前的所有消息都已經(jīng)被簽收過了，才可以更新訂閱組在當(dāng)前主題當(dāng)前隊(duì)列中的消費(fèi)進(jìn)度。

實(shí)施例二

參見圖6，本實(shí)施例提供了訂閱者消費(fèi)消息過程中產(chǎn)生故障后的消息訂閱方法：

601，消息訂閱者消費(fèi)消息過程中故障；

602，消息服務(wù)器檢測到訂閱者發(fā)生故障；

具體地，訂閱者故障后，消息服務(wù)器與訂閱者的長連接會斷開。訂閱者每隔一段時間向消息服務(wù)器發(fā)送心跳，告訴消息服務(wù)器訂閱者還活著。消息服務(wù)器上回保存訂閱者的連接信息，如果訂閱者超過一定時間沒有發(fā)送心跳給消費(fèi)服務(wù)器，則會認(rèn)為訂閱端故障。

603，消息服務(wù)器將故障訂閱者中沒有簽收的消息的消費(fèi)狀態(tài)由消費(fèi)中改為待消費(fèi)；

604，新的訂閱者重新消費(fèi)到上述未簽收的消息；

也就是說，按照實(shí)施例一中的方法，新的訂閱端將優(yōu)先獲取到消息訂閱處理裝置的消費(fèi)狀態(tài)管理模塊中處于待消費(fèi)狀態(tài)的消息，并重新進(jìn)行消費(fèi)和簽收。

使用實(shí)施例一和實(shí)施例二的技術(shù)方案可以很好的解決訂閱者故障造成的消費(fèi)中消息丟失的問題。

實(shí)施例三

參見圖7，本實(shí)施例提供了可以實(shí)現(xiàn)消息定時重投的消息訂閱處理方法：

701，訂閱者進(jìn)行消息業(yè)務(wù)處理后不簽收消息進(jìn)行消息重試并設(shè)定重投時間；

702，消息服務(wù)器收到消息重試請求；

703，消息服務(wù)器在消費(fèi)狀態(tài)管理模塊中設(shè)置對應(yīng)重試消息為待消費(fèi)狀態(tài)并記錄重投時間；

704，訂閱者再次發(fā)起訂閱消息請求；

705，如果重投消息重投時間已到，消息服務(wù)器從消費(fèi)狀態(tài)管理模塊獲取狀態(tài)為待消費(fèi)的待重投消息，發(fā)送給訂閱者，否則進(jìn)去704繼續(xù)等待。

本實(shí)施例中，與實(shí)施例一方案不同的是當(dāng)消息服務(wù)器從消費(fèi)狀態(tài)管理模塊中獲取待消費(fèi)消息時，增加了判斷重投時間是否已到。如果對應(yīng)的待消費(fèi)消息沒有達(dá)到重投時間，則該消息會一直處于待消費(fèi)狀態(tài)。

特別的，對于那些不需要進(jìn)行重投的消息，消費(fèi)狀態(tài)管理模塊中將重投時間設(shè)置為消息生成的時間，表明不需要等待消息就可以被消息訂閱處理裝置獲取。

綜上所述，本發(fā)明一種消息訂閱處理裝置、系統(tǒng)及方法，通過利用消息存儲模塊存儲具體的消息、消息配置管理模塊管理被訂閱主題和訂閱消息的消息訂閱端的配置信息、消費(fèi)狀態(tài)管理模塊存儲消費(fèi)狀態(tài)為待消費(fèi)或消費(fèi)中的消息以及消費(fèi)進(jìn)度管理模塊管理訂閱端消費(fèi)訂閱主題的進(jìn)度信息，于接收訂閱端發(fā)送的訂閱消息的請求時，根據(jù)請求中的主題和隊(duì)列信息查詢消費(fèi)進(jìn)度，于消息狀態(tài)管理模塊中獲取消費(fèi)進(jìn)度對應(yīng)偏移量之后的待消費(fèi)的消息，并將獲取的消息發(fā)送給消息訂閱端，根據(jù)消息訂閱端的反饋信息修改消息的消費(fèi)狀態(tài)及消費(fèi)進(jìn)度，實(shí)現(xiàn)了高可靠的分布式消息訂閱的目的，并解決了現(xiàn)有技術(shù)中訂閱端異常造成的消費(fèi)消息丟失、跳躍消費(fèi)消息以及定時重投消息等問題。

上述實(shí)施例僅例示性說明本發(fā)明的原理及其功效，而非用于限制本發(fā)明。任何本領(lǐng)域技術(shù)人員均可在不違背本發(fā)明的精神及范疇下，對上述實(shí)施例進(jìn)行修飾與改變。因此，本發(fā)明的權(quán)利保護(hù)范圍，應(yīng)如權(quán)利要求書所列。