[發明專利]消息處理系統、方法、裝置、電子設備和存儲介質

在審

• 申請號: 202110296839.4
• 申請日: 2021-03-19
• 公開（公告）號: CN113064736A
• 公開（公告）日: 2021-07-02
• 發明（設計）人: 李寶銀
• 申請（專利權）人: 北京房江湖科技有限公司
• 主分類號: G06F9/54
• 分類號: G06F9/54
• 代理公司: 北京思源智匯知識產權代理有限公司 11657
• 代理人: 毛麗琴

本公開實施例公開了一種消息處理系統、方法、裝置、電子設備和存儲介質。該消息處理系統中：系統側軟件開發工具包，被配置成：響應于系統節點的消息處理結果指示消息發送失敗或消息消費失敗，將系統節點發送失敗或消費失敗的消息作為失敗消息，從系統節點獲取失敗消息；向服務側軟件開發工具包發送失敗消息；服務側軟件開發工具包，被配置成：將從系統側軟件開發工具包獲得的失敗消息寫入守護服務；守護服務，被配置成：存儲失敗消息；通過超文本傳輸協議對失敗消息進行重試。本公開實施例可以減小消息處理過程受損的情況發生，減少了業務系統對消息處理的投入，可以提升系統穩定性。

技術領域

本公開涉及數據處理領域，尤其是一種消息處理系統、方法、裝置、電子設備和存儲介質。

背景技術

現有技術中，消息隊列(MQ，Message Queue)已經逐漸成為分布式應用場景、內部通信的核心技術，其具有低耦合、可靠投遞、廣播、流量控制、最終一致性等特點。

通常，消息從生產到消費，中間需要經過消息隊列。其中，從生產到消費的任意系統節點都可能會發生故障。現有的解決方案主要有以下兩種：

第一種，基于日志補償的解決方案。該方案在故障期間不會做額外處理，只是將發送失敗的消息以日志形式存儲好，當消息隊列恢復時，再自動重新發送，通過分析之前存儲的日志，將之前處理失敗的消息重新發送給消息隊列處理。

第二種，基于消息表定時對比與補償的解決方案。該方案在生產端與消費端分別設計一張表，用來存儲發送或消費的每一條消息，然后定時將生產端與消費端的消息表進行對比，對不一致的消息進行補償。

可見，目前的解決方案在消息隊列故障期間導致的消息消費失敗、消息發送失敗等情形下，無法對消息進行處理，業務受損時長、程度難以控制，故障排除后，消息每秒查詢率(QPS，Queries-per-second)驟增，沖擊系統穩定性。

發明內容

本公開實施例提供一種消息處理系統、方法、裝置、電子設備和存儲介質，可以在消息發送失敗或消息消費失敗的情況下，通過守護服務對失敗消息進行重試，減小了消息處理過程受損的情況發生，減少了業務系統對消息處理的投入，可以提升系統穩定性。

根據本公開實施例的一個方面，提供的一種消息處理方法，包括：系統節點端和守護服務端，所述系統節點端包括系統節點和接入所述系統節點的系統側軟件開發工具包，所述守護服務端包括守護服務和供所述守護服務使用的服務側軟件開發工具包，其中：

所述系統側軟件開發工具包，被配置成：響應于所述系統節點的消息處理結果指示消息發送失敗或消息消費失敗，將所述系統節點發送失敗或消費失敗的消息作為失敗消息，從所述系統節點獲取所述失敗消息；向所述服務側軟件開發工具包發送所述失敗消息；

所述服務側軟件開發工具包，被配置成：將從所述系統側軟件開發工具包獲得的所述失敗消息寫入所述守護服務；

所述守護服務，被配置成：存儲所述失敗消息；通過超文本傳輸協議對所述失敗消息進行重試。

可選地，在本公開任一實施例的系統中，所述系統節點端包括消息生產節點端，所述消息生產節點端包括消息生產節點和接入所述消息生產節點的生產側軟件開發工具包；所述生產側軟件開發工具包，被配置成：針對所述消息生產節點每次發送消息的消息發送結果進行檢測，確定所述消息發送結果是否指示消息發送失敗；

和/或

所述系統節點端包括消息消費節點端，所述消息消費節點端包括消息消費節點和接入所述消息消費節點的消費側軟件開發工具包；所述消費側軟件開發工具包，被配置成：針對所述消息消費節點每次消費消息的消息消費結果進行檢測，確定所述消息消費結果是否指示消息消費失敗。

可選地，在本公開任一實施例的系統中，所述系統還包括消息數據庫；以及