本發(fā)明涉及計算機通信技術領域，尤其涉及一種數(shù)據(jù)通信方法及裝置。

背景技術：

消息隊列系統(tǒng)RabbitMQ(Rabbit Message Queue)包括消息隊列服務器RabbitMQ Server和消費客戶端RabbitMQ Client，其中，消息隊列服務器中配置有消息隊列Queue。消息隊列服務器在對消息進行消費處理時，將消息保存于消息隊列中，供之后消費客戶端消費消息隊列中的消息。由于消息可能會消費成功，也可能會消費失敗，在消息消費失敗時，消費客戶端會將消息發(fā)送至消息隊列服務器，消息隊列服務器在接收到消費失敗的消息時，立即對該消費失敗的消息重新投遞至消費客戶端繼續(xù)進行消費處理，直至該消息消費成功，這就會造成一直對該消息進行多次消費處理，此過程中其他消息的消費處理就受到了阻礙，導致消息隊列服務器的消息處理效率不高。

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

本發(fā)明的主要目的在于提供一種數(shù)據(jù)通信方法和裝置，旨在解決消息隊列服務器的消息處理效率不高的技術問題。

為實現(xiàn)上述目的，本發(fā)明提供一種數(shù)據(jù)通信方法，所述數(shù)據(jù)通信方法包括以下步驟：

接收消費客戶端發(fā)送的消息對應的狀態(tài)值，其中，所述消費客戶端在對消息進行業(yè)務邏輯處理完成時，返回處理結果的狀態(tài)值，所述狀態(tài)值包括成功、稍后重試、失敗丟棄；

當所述狀態(tài)值為稍后重試時，調用延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列；

在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至重試消息隊列。

優(yōu)選地，所述接收消費客戶端發(fā)送的消息對應的狀態(tài)值的步驟之前，還包括：

將所述消息發(fā)送至所述消費客戶端，以供所述消費客戶端對所述消息進行業(yè)務邏輯處理，并通過回調函數(shù)返回處理結果的狀態(tài)值；

所述當所述狀態(tài)值為稍后重試時，調用延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列的步驟包括：

當所述狀態(tài)值為稍后重試時，根據(jù)所述消息的消息頭設置的重試次數(shù)，選擇所述消息要發(fā)回的延遲交換機，并將所述消息發(fā)回選擇的所述延遲消息交換機；

調用所述延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列。

優(yōu)選地，所述當所述狀態(tài)值為稍后重試時，根據(jù)所述消息的消息頭設置的重試次數(shù)，選擇所述消息要發(fā)回的延遲交換機的步驟包括：

當所述狀態(tài)值為稍后重試時，判斷所述消息的消息頭設置的重試次數(shù)是否小于預設的重試次數(shù)閾值；

在所述重試次數(shù)小于所述重試次數(shù)閾值時，根據(jù)所述重試次數(shù)選擇所述消息要發(fā)回的延遲交換機。

優(yōu)選地，所述當所述狀態(tài)值為稍后重試時，判斷所述消息的消息頭設置的重試次數(shù)是否小于預設的重試次數(shù)閾值的步驟之后，還包括：

在所述重試次數(shù)大于所述重試次數(shù)閾值時，將所述消息發(fā)送至死信消息隊列。

優(yōu)選地，所述在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至重試消息隊列的步驟包括：

在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至所述延遲消息隊列對應的重試消息交換機，并通過所述重試消息交換機將所述消息發(fā)送至所述重試消息隊列。

此外，為實現(xiàn)上述目的，本發(fā)明還提出一種數(shù)據(jù)通信裝置，所述數(shù)據(jù)通信裝置包括：

接收模塊，用于接收消費客戶端發(fā)送的消息對應的狀態(tài)值，其中，所述消費客戶端在對消息進行業(yè)務邏輯處理完成時，返回處理結果的狀態(tài)值，所述狀態(tài)值包括成功、稍后重試、失敗丟棄；

發(fā)送模塊，用于當所述狀態(tài)值為稍后重試時，調用延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列；

處理模塊，用于在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至重試消息隊列。

優(yōu)選地，所述發(fā)送模塊還用于：

將所述消息發(fā)送至所述消費客戶端，以供所述消費客戶端對所述消息進行業(yè)務邏輯處理，并通過回調函數(shù)返回處理結果的狀態(tài)值；

以及當所述狀態(tài)值為稍后重試時，根據(jù)所述消息的消息頭設置的重試次數(shù)，選擇所述消息要發(fā)回的延遲交換機，將所述消息發(fā)回選擇的所述延遲消息交換機，并調用所述延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列。

優(yōu)選地，所述發(fā)送模塊包括：

判斷單元，用于當所述狀態(tài)值為稍后重試時，判斷所述消息的消息頭設置的重試次數(shù)是否小于預設的重試次數(shù)閾值；

選擇單元，用于在所述重試次數(shù)小于所述重試次數(shù)閾值時，根據(jù)所述重試次數(shù)選擇所述消息要發(fā)回的延遲交換機。

優(yōu)選地，所述發(fā)送模塊還用于：

在所述重試次數(shù)大于所述重試次數(shù)閾值時，將所述消息發(fā)送至死信消息隊列。

優(yōu)選地，所述處理模塊用于：

在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至所述延遲消息隊列對應的重試消息交換機，并通過所述重試消息交換機將所述消息發(fā)送至所述重試消息隊列。

本發(fā)明提出的數(shù)據(jù)通信方法及裝置，當接收到消費客戶端發(fā)送的消息對應的狀態(tài)值為稍后重試時，調用延遲消息交換機將該消息發(fā)送至延遲消息交換機對應的延遲消息隊列，并在歷時該延遲消息隊列對應的預設延遲時間后，將該消息發(fā)送至重試消息隊列，供消費客戶端對重試消息隊列中的該消息進行消費。也即在消息消費失敗時，并不是立即對該消息再次重新進行消費，直至該消息消費成功，而是經(jīng)過一段延遲時間后再對該消息進行消費，在該延遲時間內，可以對其他消息進行消費處理，因此，提高了消息隊列服務器的消息處理效率。

附圖說明

圖1為本發(fā)明數(shù)據(jù)通信方法第一實施例的流程示意圖；

圖2為本發(fā)明數(shù)據(jù)通信方法第二實施例中當所述狀態(tài)值為稍后重試時，調用延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列的細化流程示意圖；

圖3為本發(fā)明數(shù)據(jù)通信裝置第一實施例的功能模塊示意圖；

圖4為本發(fā)明數(shù)據(jù)通信裝置第二實施例中發(fā)送模塊的細化功能模塊示意圖。

具體實施方式

應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

本發(fā)明提供一種數(shù)據(jù)通信方法。參照圖1，圖1為本發(fā)明數(shù)據(jù)通信方法第一實施例的流程示意圖。在本實施例中，所述數(shù)據(jù)通信方法包括以下步驟：

步驟S10，接收消費客戶端發(fā)送的消息對應的狀態(tài)值，其中，所述消費客戶端在對消息進行業(yè)務邏輯處理完成時，返回處理結果的狀態(tài)值，所述狀態(tài)值包括成功、稍后重試、失敗丟棄；

消息隊列系統(tǒng)RabbitMQ(Rabbit Message Queue)包括消息隊列服務器RabbitMQ Server和消費客戶端RabbitMQ Client，其中，消息隊列服務器RabbitMQ Server中配置有延遲消息交換機Delay Exchange、重試消息交換機Redelivery Exchange、延遲消息隊列Delay Queue、重試消息隊列Retry Queue、死信消息隊列Dead Letter Queue等。當消費客戶端RabbitMQ Client對消息隊列服務器RabbitMQ Server中的消息進行業(yè)務邏輯處理時，可能會消費成功，也有可能會消費失敗。在對消息進行業(yè)務邏輯處理完成時，消費客戶端RabbitMQ Client向消息隊列服務器RabbitMQ Server返回對消息進行業(yè)務邏輯處理結果的狀態(tài)值。其中，對消息進行業(yè)務邏輯處理結果的狀態(tài)值包括成功、稍后重試、失敗丟棄等等。例如，當消費客戶端RabbitMQ Client消費消息失敗時，消費客戶端RabbitMQ Client將該消息發(fā)送至消息隊列服務器RabbitMQ Server，并向消息隊列服務器RabbitMQ Server返回稍后重試的狀態(tài)值。消息隊列服務器RabbitMQ Server接收消費客戶端RabbitMQ Client發(fā)送的消息以及對消息進行業(yè)務邏輯處理結果的狀態(tài)值。

步驟S20，當所述狀態(tài)值為稍后重試時，調用延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列；

本實施例中，延遲消息交換機Delay Exchange與延遲消息隊列Delay Queue具有綁定的對應關系。當消息隊列服務器RabbitMQ Server接收到消費客戶端RabbitMQ Client發(fā)送的對消息進行業(yè)務邏輯處理結果的狀態(tài)值為稍后重試時，消息隊列服務器RabbitMQ Server調用延遲消息交換機Delay Exchange將消息發(fā)送至延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue。其中，延遲消息隊列Delay Queue對應有一個預設延遲時間。在未到達延遲時間時，延遲消息隊列Delay Queue中的消息無法進行提取、投遞等處理，只有當?shù)竭_延遲時間時，才能提取延遲消息隊列Delay Queue中的消息。

步驟S30，在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至重試消息隊列。

當消息隊列服務器RabbitMQ Server調用延遲消息交換機Delay Exchange將該消息發(fā)送至延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue，在歷時該延遲消息隊列Delay Queue對應的預設延遲時間之后，將該消息發(fā)送至重試消息隊列Retry Queue。本實施例中，默認訂閱重試消息隊列Retry Queue，當消息發(fā)送至重試消息隊列Retry Queue中之后，消費客戶端RabbitMQ Client即可獲取并消費該消息。若此次該消息還未消費成功，則消費客戶端RabbitMQ Client可繼續(xù)向消息隊列服務器RabbitMQ Server發(fā)送該消息以及稍后重試的狀態(tài)值，消息隊列服務器RabbitMQ Server再次執(zhí)行上述操作。在此過程中，由于消息是經(jīng)過一段的延遲時間后才發(fā)送至重試消息隊列Retry Queue的，在此期間，消息隊列服務器RabbitMQ Server可以對其他的消息進行消費處理操作。

具體地，所述步驟S30包括：

步驟a，在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至所述延遲消息隊列對應的重試消息交換機，并通過所述重試消息交換機將所述消息發(fā)送至所述重試消息隊列。

本實施例中，重試消息交換機Redelivery Exchange與延遲消息隊列Delay Queue建立有綁定關系。當消息隊列服務器RabbitMQ Server調用延遲消息交換機Delay Exchange將該消息發(fā)送至延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue，在歷時該延遲消息隊列Delay Queue對應的預設延遲時間之后，將該消息發(fā)送至與該延遲消息隊列Delay Queue有綁定關系的重試消息交換機Redelivery Exchange，通過該重試消息交換機Redelivery Exchange將該消息發(fā)送至重試消息隊列Retry Queue，供之后消費客戶端RabbitMQ Client獲取并消費該消息。

本實施例提供的方案，當接收到消費客戶端發(fā)送的消息對應的狀態(tài)值為稍后重試時，調用延遲消息交換機將該消息發(fā)送至延遲消息交換機對應的延遲消息隊列，并在歷時該延遲消息隊列對應的預設延遲時間后，將該消息發(fā)送至重試消息隊列，供消費客戶端對重試消息隊列中的該消息進行消費。也即在消息消費失敗時，并不是立即對該消息再次重新進行消費，直至該消息消費成功，而是經(jīng)過一段延遲時間后再對該消息進行消費，在該延遲時間內，可以對其他消息進行消費處理，因此，提高了消息隊列服務器的消息處理效率。同時，還降低了消息隊列服務器的負載，并通過重試消息隊列完成消費客戶端的轉態(tài)機模型。

進一步地，如圖2所示，基于第一實施例提出本發(fā)明數(shù)據(jù)通信方法第二實施例。在第二實施例中，所述步驟S10之前，還包括：

步驟b，將所述消息發(fā)送至所述消費客戶端，以供所述消費客戶端對所述消息進行業(yè)務邏輯處理，并通過回調函數(shù)返回處理結果的狀態(tài)值；

所述步驟S20包括：

步驟S21，當所述狀態(tài)值為稍后重試時，根據(jù)所述消息的消息頭設置的重試次數(shù)，選擇所述消息要發(fā)回的延遲消息交換機，并將所述消息發(fā)回選擇的所述延遲消息交換機；

步驟S22，調用所述延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列。

在本實施例中，當消費客戶端RabbitMQ Client要消費消息隊列服務器RabbitMQ Server中的消息時，消息隊列服務器RabbitMQ Server將消息發(fā)送至消費客戶端RabbitMQ Client，消費客戶端RabbitMQ Client對該消息進行業(yè)務邏輯處理，并在對消息進行業(yè)務邏輯處理完成時，通過回調函數(shù)向消息隊列服務器RabbitMQ Server返回對消息進行業(yè)務邏輯處理結果的狀態(tài)值。當消費失敗時，消費客戶端RabbitMQ Client通過回調函數(shù)向消息隊列服務器RabbitMQ Server返回稍后重試的狀態(tài)值以及該消息。其中，該消息的消息頭中設置有消息的重試次數(shù)。

本實施例中，消息隊列服務器RabbitMQ Server中可配置多個延遲消息交換機Delay Exchange、多個重試消息交換機Redelivery Exchange和多個延遲消息隊列Delay Queue，其中，一個延遲消息交換機Delay Exchange與一個延遲消息隊列Delay Queue具有一一對應關系，一個延遲消息隊列Delay Queue與一個重試消息交換機Redelivery Exchange建立有綁定的一一對應關系。當消息隊列服務器RabbitMQ Server接收到稍后重試的狀態(tài)值以及該消息時，先根據(jù)該消息的消息頭設置的重試次數(shù)，選擇該消息要發(fā)回的延遲交換機Delay Exchange。例如，在該消息的消息頭設置的重試次數(shù)為1時，選擇該消息要發(fā)回的延遲交換機Delay Exchange為Delay Exchange 1。然后，將該消息發(fā)回選擇的延遲消息交換機Delay Exchange，并將該消息發(fā)送至延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue。

進一步地，所述步驟S21包括：

步驟c，當所述狀態(tài)值為稍后重試時，判斷所述消息的消息頭設置的重試次數(shù)是否小于預設的重試次數(shù)閾值；

步驟e，在所述重試次數(shù)小于所述重試次數(shù)閾值時，根據(jù)所述重試次數(shù)選擇所述消息要發(fā)回的延遲交換機。

進一步地，在所述步驟c之后，還包括：

步驟e，在所述重試次數(shù)大于所述重試次數(shù)閾值時，將所述消息發(fā)送至死信消息隊列。

當對消息再次消費時，消息不一定會消費成功，有可能還是消費失敗，為了避免產(chǎn)生對某一個消息一直進行消費的死循環(huán)，本實施例中，預先設置有消息的一個重試次數(shù)閾值，例如，設置該重試次數(shù)閾值為16，該重試次數(shù)閾值可以根據(jù)實際情況進行靈活設置，在此不作限制。當消息隊列服務器RabbitMQ Server接收到稍后重試的狀態(tài)值時，進一步判斷該消息的消息頭設置的重試次數(shù)是否小于預設的重試次數(shù)閾值。在該消息的消息頭設置的重試次數(shù)小于重試次數(shù)閾值時，也即說明該消息的消費次數(shù)還不多，此時，根據(jù)該消息的消息頭設置的重試次數(shù)選擇該消息要發(fā)回的延遲交換機Delay Exchange，將該消息發(fā)回選擇的延遲消息交換機Delay Exchange，并調用延遲消息交換機Delay Exchange將該消息發(fā)送至該延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue。當消息的消息頭設置的重試次數(shù)大于重試次數(shù)閾值時，也即說明該消息的消費次數(shù)已經(jīng)過多，此時，為了避免進入對該消息一直進行消費處理的死循環(huán)，將該消息發(fā)送至死信消息隊列Dead Letter Queue。死信消息隊列Dead Letter Queue會永久保存該消費失敗的消息，后期業(yè)務監(jiān)控可通過提取死信消息隊列Dead Letter Queue中保存的消費失敗的消息進行相關處理操作。

進一步地，消息隊列服務器RabbitMQ Server中可配置多個重試消息隊列Retry Queue，每個重試消息隊列Retry Queue都有對應的重試消息隊列名稱Retry Queue name。并且，消息中攜帶有對應的重試消息隊列名稱Retry Queue name，當消息發(fā)送至重試消息交換機Redelivery Exchange中后，根據(jù)該消息中攜帶的重試消息隊列名稱Retry Queue name，將該消息發(fā)送至該重試消息隊列名稱Retry Queue name對應的重試消息隊列Retry Queue中，供之后消費客戶端RabbitMQ Client獲取并消費該消息。

本實施例提出的方案，在消息的消息頭設置的重試次數(shù)小于預設的重試次數(shù)閾值時，將該消息發(fā)送至選擇的延遲消息交換機，并調用該延遲消息交換機將該消息發(fā)送至對應的延遲消息隊列，對該消息重新進行消費處理，在消息的消息頭設置的重試次數(shù)大于預設的重試次數(shù)閾值時，直接將該消息發(fā)送至死信消息隊列，不再對該消息進行消費處理，避免了進入失敗消費的死循環(huán)過程，從而進一步提高了消息隊列服務器的消息處理效率。

本發(fā)明進一步提供一種數(shù)據(jù)通信裝置。參照圖3，圖3為本發(fā)明數(shù)據(jù)通信裝置第一實施例的功能模塊示意圖。

在本實施例中，所述數(shù)據(jù)通信裝置包括：

接收模塊10，用于接收消費客戶端發(fā)送的消息對應的狀態(tài)值，其中，所述消費客戶端在對消息進行業(yè)務邏輯處理完成時，返回處理結果的狀態(tài)值，所述狀態(tài)值包括成功、稍后重試、失敗丟棄；

消息隊列系統(tǒng)RabbitMQ(Rabbit Message Queue)包括消息隊列服務器RabbitMQ Server和消費客戶端RabbitMQ Client，其中，消息隊列服務器RabbitMQ Server中配置有延遲消息交換機Delay Exchange、重試消息交換機Redelivery Exchange、延遲消息隊列Delay Queue、重試消息隊列Retry Queue、死信消息隊列Dead Letter Queue等。當消費客戶端RabbitMQ Client對消息隊列服務器RabbitMQ Server中的消息進行業(yè)務邏輯處理時，可能會消費成功，也有可能會消費失敗。在對消息進行業(yè)務邏輯處理完成時，消費客戶端RabbitMQ Client向消息隊列服務器RabbitMQ Server返回對消息進行業(yè)務邏輯處理結果的狀態(tài)值。其中，對消息進行業(yè)務邏輯處理結果的狀態(tài)值包括成功、稍后重試、失敗丟棄等等。例如，當消費客戶端RabbitMQ Client消費消息失敗時，消費客戶端RabbitMQ Client將該消息發(fā)送至消息隊列服務器RabbitMQ Server，并向消息隊列服務器RabbitMQ Server返回稍后重試的狀態(tài)值。接收模塊10接收消費客戶端RabbitMQ Client發(fā)送的消息以及對消息進行業(yè)務邏輯處理結果的狀態(tài)值。

發(fā)送模塊20，用于當所述狀態(tài)值為稍后重試時，調用延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列；

本實施例中，延遲消息交換機Delay Exchange與延遲消息隊列Delay Queue具有綁定的對應關系。當接收模塊10接收到消費客戶端RabbitMQ Client發(fā)送的對消息進行業(yè)務邏輯處理結果的狀態(tài)值為稍后重試時，發(fā)送模塊20調用延遲消息交換機Delay Exchange將消息發(fā)送至延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue。其中，延遲消息隊列Delay Queue對應有一個預設延遲時間。在未到達延遲時間時，延遲消息隊列Delay Queue中的消息無法進行提取、投遞等處理，只有當?shù)竭_延遲時間時，才能提取延遲消息隊列Delay Queue中的消息。

處理模塊30，用于在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至重試消息隊列。

當發(fā)送模塊20調用延遲消息交換機Delay Exchange將該消息發(fā)送至延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue，在歷時該延遲消息隊列Delay Queue對應的預設延遲時間之后，處理模塊30將該消息發(fā)送至重試消息隊列Retry Queue。本實施例中，默認訂閱重試消息隊列Retry Queue，當消息發(fā)送至重試消息隊列Retry Queue中之后，消費客戶端RabbitMQ Client即可獲取并消費該消息。若此次該消息還未消費成功，則消費客戶端RabbitMQ Client可繼續(xù)向消息隊列服務器RabbitMQ Server發(fā)送該消息以及稍后重試的狀態(tài)值，發(fā)送模塊20再次執(zhí)行上述操作。在此過程中，由于消息是經(jīng)過一段的延遲時間后才發(fā)送至重試消息隊列Retry Queue的，在此期間，處理模塊30可以對其他的消息進行消費處理操作。

具體地，所述處理模塊30用于：

在歷時所述延遲消息隊列對應的預設延遲時間后，將所述消息發(fā)送至所述延遲消息隊列對應的重試消息交換機，并通過所述重試消息交換機將所述消息發(fā)送至所述重試消息隊列。

本實施例中，重試消息交換機Redelivery Exchange與延遲消息隊列Delay Queue建立有綁定關系。當發(fā)送模塊20調用延遲消息交換機Delay Exchange將該消息發(fā)送至延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue，在歷時該延遲消息隊列Delay Queue對應的預設延遲時間之后，處理模塊30將該消息發(fā)送至與該延遲消息隊列Delay Queue有綁定關系的重試消息交換機Redelivery Exchange，通過該重試消息交換機Redelivery Exchange將該消息發(fā)送至重試消息隊列Retry Queue，供之后消費客戶端RabbitMQ Client獲取并消費該消息。

本實施例提供的方案，當接收模塊10接收到消費客戶端發(fā)送的消息對應的狀態(tài)值為稍后重試時，發(fā)送模塊20調用延遲消息交換機將該消息發(fā)送至延遲消息交換機對應的延遲消息隊列，并在歷時該延遲消息隊列對應的預設延遲時間后，處理模塊30將該消息發(fā)送至重試消息隊列，供消費戶端對重試消息隊列中的該消息進行消費。也即在消息消費失敗時，并不是立即對該消息再次重新進行消費，直至該消息消費成功，而是經(jīng)過一段延遲時間后再對該消息進行消費，在該延遲時間內，可以對其他消息進行消費處理，因此，提高了消息隊列服務器的消息處理效率。同時，還降低了消息隊列服務器的負載，并通過重試消息隊列完成消費客戶端的轉態(tài)機模型。

進一步地，基于第一實施例提出本發(fā)明數(shù)據(jù)通信裝置第二實施例。在第二實施例中，所述發(fā)送模塊20還用于：

將所述消息發(fā)送至所述消費客戶端，以供所述消費客戶端對所述消息進行業(yè)務邏輯處理，并通過回調函數(shù)返回處理結果的狀態(tài)值；

以及當所述狀態(tài)值為稍后重試時，根據(jù)所述消息的消息頭設置的重試次數(shù)，選擇所述消息要發(fā)回的延遲交換機，將所述消息發(fā)回選擇的所述延遲消息交換機，并調用所述延遲消息交換機將所述消息發(fā)送至所述延遲消息交換機對應的延遲消息隊列。

在本實施例中，當消費客戶端RabbitMQ Client要消費消息隊列服務器RabbitMQ Server中的消息時，發(fā)送模塊20將消息發(fā)送至消費客戶端RabbitMQ Client，消費客戶端RabbitMQ Client對該消息進行業(yè)務邏輯處理，并在對消息進行業(yè)務邏輯處理完成時，通過回調函數(shù)向消息隊列服務器RabbitMQ Server返回對消息進行業(yè)務邏輯處理結果的狀態(tài)值。當消費失敗時，消費客戶端RabbitMQ Client通過回調函數(shù)向消息隊列服務器RabbitMQ Server返回稍后重試的狀態(tài)值以及該消息。其中，該消息的消息頭中設置有消息的重試次數(shù)。

本實施例中，消息隊列服務器RabbitMQ Server中可配置多個延遲消息交換機Delay Exchange、多個重試消息交換機Redelivery Exchange和多個延遲消息隊列Delay Queue，其中，一個延遲消息交換機Delay Exchange與一個延遲消息隊列Delay Queue具有一一對應關系，一個延遲消息隊列Delay Queue與一個重試消息交換機Redelivery Exchange建立有綁定的一一對應關系。當接收模塊10接收到稍后重試的狀態(tài)值以及該消息時，發(fā)送模塊20先根據(jù)該消息的消息頭設置的重試次數(shù)，選擇該消息要發(fā)回的延遲交換機Delay Exchange。例如，在該消息的消息頭設置的重試次數(shù)為1時，選擇該消息要發(fā)回的延遲交換機Delay Exchange為Delay Exchange 1。然后，將該消息發(fā)回選擇的延遲消息交換機Delay Exchange，并將該消息發(fā)送至延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue。

進一步地，本實施例中，如圖4所示，所述發(fā)送模塊20包括：

判斷單元21，用于當所述狀態(tài)值為稍后重試時，判斷所述消息的消息頭設置的重試次數(shù)是否小于預設的重試次數(shù)閾值；

選擇單元22，用于在所述重試次數(shù)小于所述重試次數(shù)閾值時，根據(jù)所述重試次數(shù)選擇所述消息要發(fā)回的延遲交換機。

進一步地，所述發(fā)送模塊20還用于：

在所述重試次數(shù)大于所述重試次數(shù)閾值時，將所述消息發(fā)送至死信消息隊列。

當對消息再次消費時，消息不一定會消費成功，有可能還是消費失敗，為了避免產(chǎn)生對某一個消息一直進行消費的死循環(huán)，本實施例中，預先設置有消息的一個重試次數(shù)閾值，例如，設置該重試次數(shù)閾值為16，該重試次數(shù)閾值可以根據(jù)實際情況進行靈活設置，在此不作限制。當接收模塊10接收到稍后重試的狀態(tài)值以及消息時，判斷單元21判斷該消息的消息頭設置的重試次數(shù)是否小于預設的重試次數(shù)閾值。在該消息的消息頭設置的重試次數(shù)小于重試次數(shù)閾值時，也即說明該消息的消費次數(shù)還不多，此時，選擇單元22根據(jù)該消息的消息頭設置的重試次數(shù)選擇該消息要發(fā)回的延遲交換機Delay Exchange，發(fā)送模塊20將該消息發(fā)回選擇的延遲消息交換機Delay Exchange，并調用延遲消息交換機Delay Exchange將該消息發(fā)送至該延遲消息交換機Delay Exchange對應的延遲消息隊列Delay Queue。當消息的消息頭設置的重試次數(shù)大于重試次數(shù)閾值時，也即說明該消息的消費次數(shù)已經(jīng)過多，此時，為了避免進入對該消息一直進行消費處理的死循環(huán)，發(fā)送模塊20將該消息發(fā)送至死信消息隊列Dead Letter Queue。死信消息隊列Dead Letter Queue會永久保存該消費失敗的消息，后期業(yè)務監(jiān)控可通過提取死信消息隊列Dead Letter Queue中保存的消費失敗的消息進行相關處理操作。

進一步地，消息隊列服務器RabbitMQ Server中可配置多個重試消息隊列Retry Queue，每個重試消息隊列Retry Queue都有對應的重試消息隊列名稱Retry Queue name。并且，消息中攜帶有對應的重試消息隊列名稱Retry Queue name，當消息發(fā)送至重試消息交換機Redelivery Exchange中后，根據(jù)該消息中攜帶的重試消息隊列名稱Retry Queue name，將該消息發(fā)送至該重試消息隊列名稱Retry Queue name對應的重試消息隊列Retry Queue中，供之后消費客戶端RabbitMQ Client獲取并消費該消息。

本實施例提出的方案，在消息的消息頭設置的重試次數(shù)小于預設的重試次數(shù)閾值時，發(fā)送模塊20將該消息發(fā)送至選擇的延遲消息交換機，并調用該延遲消息交換機將該消息發(fā)送至對應的延遲消息隊列，對該消息重新進行消費處理，在消息的消息頭設置的重試次數(shù)大于預設的重試次數(shù)閾值時，發(fā)送模塊20直接將該消息發(fā)送至死信消息隊列，不再對該消息進行消費處理，避免了進入失敗消費的死循環(huán)過程，從而進一步提高了消息隊列服務器的消息處理效率。

需要說明的是，在本文中，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。

上述本發(fā)明實施例序號僅僅為了描述，不代表實施例的優(yōu)劣。

以上僅為本發(fā)明的優(yōu)選實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內容所作的等效結構或等效流程變換，或直接或間接運用在其他相關的技術領域，均同理包括在本發(fā)明的專利保護范圍內。