本發(fā)明涉及一種消息管理系統(tǒng)及消息管理方法。

背景技術：

消息(Messaging)是現(xiàn)在系統(tǒng)間集成的主要方式，在互聯(lián)網公司內主要使用的開源消息服務產品有RabbitMQ和Kafka，這兩者提供的生產者客戶端都能滿足消息發(fā)送給服務器的功能，同時又有不錯的性能，但是他們提供的客戶端只能連接一個服務器集群。當出現(xiàn)以下情況時，沒有簡便的解決方法：1、當集群性能不能滿足時，擴容不方便，需要生產者應用編寫額外的代碼；2、當集群性能波動或宕機時，服務也將受影響?；ヂ?lián)網應用對服務的性能和可用性都有非常高的要求，當性能不足時需要能快速添加服務器以提升整體性能，系統(tǒng)不穩(wěn)定時需要有降級和故障恢復的手段保證穩(wěn)定性。而RabbitMQ和Kafka提供的客戶端實現(xiàn)顯然沒法滿足這些要求。

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

本發(fā)明要解決的技術問題是為了克服現(xiàn)有技術中開源消息服務產品提供的客戶端只能連接一個服務器集群，導致無法滿足要求的缺陷，提供一種消息管理系統(tǒng)及消息管理方法，本發(fā)明提供了一種連接多個不同消息服務器集群，并將其視為一個邏輯集群的消息生產者客戶端實現(xiàn)方法。

本發(fā)明是通過下述技術方案來解決上述技術問題的：

本發(fā)明提供了一種消息管理系統(tǒng)，其特點在于，包括消息本地持久化模塊、消息服務器資源封裝模塊以及資源管理模塊；

所述消息本地持久化模塊用于保存待發(fā)送的消息，并設置消息的進入和取出順序；

所述消息服務器資源封裝模塊用于封裝不同類型的消息服務器，并將消息服務器抽象成資源，并為消息服務器提供用于發(fā)送消息的統(tǒng)一對外接口；

所述資源管理模塊用于管理封裝好的資源，按照預設策略選擇消息服務器資源進行使用。

較佳地，所述消息本地持久化模塊用于將消息保存到本地的內存映射文件，并設置消息的進入和取出順序為先進先出。

較佳地，所述資源管理模塊包括資源選擇策略單元，用于為消息服務器集群設置所述預設策略，所述預設策略包括隨機選擇、輪詢選擇、按照最小響應時間進行選擇、按照最小壓力進行選擇、按照哈希策略進行選擇中的至少一種。

較佳地，所述資源管理模塊還包括資源檢測單元，用于對所有的消息服務器資源進行心跳檢測，并根據(jù)心跳檢測結果對消息服務器的資源狀態(tài)進行設置。

較佳地，所述資源檢測單元用于當心跳檢測結果為可用時，將被檢測的消息服務器資源的狀態(tài)標記為可用狀態(tài)；當心跳檢測結果為不可用時，將被檢測的消息服務器資源的狀態(tài)標記為不可用狀態(tài)。

較佳地，所述資源檢測單元用于對所有的消息服務器資源定時進行心跳檢測。

本發(fā)明的目的在于還提供了一種消息管理方法，其特點在于，包括以下步驟：

客戶端載入所有已封裝的消息服務器資源，標記所有消息服務器資源的狀態(tài)為可用狀態(tài)；

客戶端啟動心跳檢測線程和本地隊列消費線程；

使用客戶端發(fā)送消息，客戶端將消息保存到本地持久化隊列中；

定時對所有的消息服務器資源進行心跳檢測，當心跳檢測結果為可用時，將被檢測的消息服務器資源的狀態(tài)標記為可用狀態(tài)；當心跳檢測結果為不可用時，將被檢測的消息服務器資源的狀態(tài)標記為不可用狀態(tài)；

本地隊列消費線程獲取持久化的消息，執(zhí)行資源選擇策略獲取可用狀態(tài)的消息服務器資源，然后利用獲取的消息服務器資源執(zhí)行發(fā)送消息的操作。

本發(fā)明的積極進步效果在于：本發(fā)明不需要服務器端支持就可以實現(xiàn)消息服務器集群，并且可以支持同時使用不同類型的消息服務器，只需要通過簡單的代碼或配置就可以提高應用的吞吐量，保證互聯(lián)網應用的穩(wěn)定性。

附圖說明

圖1為本發(fā)明的較佳實施例的消息管理系統(tǒng)的模塊示意圖。

圖2為本發(fā)明的較佳實施例的消息管理方法的流程圖。

具體實施方式

下面通過實施例的方式進一步說明本發(fā)明，但并不因此將本發(fā)明限制在所述的實施例范圍之中。

如圖1所示，本發(fā)明的消息管理系統(tǒng)包括消息本地持久化模塊1、消息服務器資源封裝模塊2以及資源管理模塊3。

其中，所述消息本地持久化模塊1用于保存待發(fā)送的消息，并設置消息的進入和取出順序，從而保證消息取出的順序符合消息進入的順序；

具體地，所述消息本地持久化模塊1會將消息保存到本地的內存映射文件，并實現(xiàn)隊列接口，保證消息的進入取出順序為先進先出。

所述消息服務器資源封裝模塊2用于封裝不同類型的消息服務器，并將消息服務器抽象成資源，并為消息服務器提供用于發(fā)送消息的統(tǒng)一對外接口；同時還通過暴露消息路由參數(shù)，實現(xiàn)消息路由功能：RabbitMQ的路由使用routing key(一種消息路由)，Kafka的路由使用partition key(一種消息路由)。

所述資源管理模塊3用于管理封裝好的資源，按照預設策略選擇消息服務器資源進行使用。所述資源管理模塊3為已封裝的消息服務器資源提供客戶端集群功能，維護消息服務器的狀態(tài)列表，為客戶端請求選擇可用的消息服務器資源。

所述資源管理模塊3包括資源選擇策略單元31和資源檢測單元32，所述資源選擇策略單元31用于為消息服務器集群設置預設策略(即資源選擇策略)，所述預設策略包括隨機選擇、輪詢選擇、按照最小響應時間進行選擇、按照最小壓力進行選擇、按照哈希策略進行選擇中的至少一種；所述資源檢測單元32用于對所有的消息服務器資源定時進行心跳檢測，并根據(jù)心跳檢測結果對消息服務器的資源狀態(tài)進行設置，當心跳檢測結果為可用時，將被檢測的消息服務器資源的狀態(tài)標記為可用狀態(tài)；當心跳檢測結果為不可用時，將被檢測的消息服務器資源的狀態(tài)標記為不可用狀態(tài)。

如圖2所示，本發(fā)明的消息管理方法利用上述的消息管理系統(tǒng)實現(xiàn)，包括以下步驟：

步驟101、客戶端載入所有已封裝的消息服務器資源，標記所有消息服務器資源的狀態(tài)為可用狀態(tài)；

步驟102、客戶端啟動心跳檢測線程和本地隊列消費線程；

步驟103、使用客戶端發(fā)送消息，客戶端將消息保存到本地持久化隊列中；

步驟104、定時對所有的消息服務器資源進行心跳檢測，當心跳檢測結果為可用時，將被檢測的消息服務器資源的狀態(tài)標記為可用狀態(tài)；當心跳檢測結果為不可用時，將被檢測的消息服務器資源的狀態(tài)標記為不可用狀態(tài)；如果心跳檢測結果是未知狀態(tài)，則會在某次消息發(fā)送時，嘗試使用被檢測的消息服務器資源；

步驟105、本地隊列消費線程獲取持久化的消息，執(zhí)行資源選擇策略獲取可用狀態(tài)的消息服務器資源，然后利用獲取的消息服務器資源執(zhí)行發(fā)送消息的操作；

發(fā)送成功時，直接返回；發(fā)送失敗時，則將獲取的消息服務器資源標記為不可用狀態(tài)，退出消息服務器資源選擇。

雖然以上描述了本發(fā)明的具體實施方式，但是本領域的技術人員應當理解，這些僅是舉例說明，本發(fā)明的保護范圍是由所附權利要求書限定的。本領域的技術人員在不背離本發(fā)明的原理和實質的前提下，可以對這些實施方式做出多種變更或修改，但這些變更和修改均落入本發(fā)明的保護范圍。