[發明專利]消息發送方法、裝置、計算機設備和存儲介質

有效

• 申請號: 202010740520.1
• 申請日: 2020-07-28
• 公開（公告）號: CN111835467B
• 公開（公告）日: 2022-03-29
• 發明（設計）人: 周航
• 申請（專利權）人: 中國平安財產保險股份有限公司
• 主分類號: H04L1/16
• 分類號: H04L1/16;H04L1/18
• 代理公司: 北京英特普羅知識產權代理有限公司 11015
• 代理人: 程超

本發明提供一種消息發送方法，包括：在預設的消息記錄表中記錄待發送消息的關鍵參數和消息類型；向目標下游業務系統發送待發送消息，待發送消息中攜帶上游系統本次消息發送時間和上游系統前次消息發送時間；當接收到目標下游業務系統返回的消息重發請求，消息重發請求包含下游系統前次消息接收時間時，查找下游系統前次消息接收時間到上游系統本次消息發送時間之間向目標下游業務系統發送的消息，而后判斷查找到消息的消息狀態是否為失敗，若否，則將查找到的消息作為新待發送消息并返回向目標下游業務系統發送待發送消息的步驟，同時將各新待發送消息的歷史發送次數加1。本發明能夠在不影響上游業務系統進程性能的前提下確認消息是否丟失。

技術領域

本發明涉及消息傳輸技術領域，尤其涉及一種消息發送方法、裝置、計算機設備和存儲介質。

背景技術

當兩個關聯系統交互時，為了解耦或是避免消息洪峰，上游業務系統會有很多需要通過MQ(Message Queue，消息隊列)向下游業務系統發送消息的場景，但是系統間通過MQ進行交互并不是100％可靠的，不管是activeMq、rabbitMq或是rocketMq、Kafka，都無法保證消息可以100％發送成功。目前，一般通過下游業務系統向上游業務系統發送回執來確認消息是否發送成功。當接收消息的下游業務系統較多時，較多的回執會影響上游業務系統的進程性能。

此外，當消息發送失敗時，對于上游業務系統就很有必要支持消息重發。傳統方案一般是在捕獲到異常消息后直接重新發送消息，重試多次，如果多次重試均失敗，那么該消息便被丟棄不再重發，等下游業務系統發現問題再通知上游業務系統，上游業務系統再通知人工構造消息，并將人工構造的消息重新發送至下游業務系統，由于此種方案需要人工構造消息，耗時較長且存在人為失誤的情況。對此，現有技術提供了另外一種方案，當某消息經多次重發仍失敗后，將該消息存入緩存系統，再利用定時器，每隔一段時間，定時從緩存系統中取出緩存消息重新進行發送，由于此種方案需要將每條發送失敗消息的完整內容進行緩存，因此存儲成本較高。

發明內容

針對上述現有技術的不足，本發明提供一種消息發送方法、裝置、計算機設備和存儲介質，能夠在不影響上游業務系統進程性能的前提下確認消息是否丟失，同時在消息發送失敗時無需對消息進行緩存，節約存儲成本。

為了實現上述目的，本發明提供一種消息發送方法，包括：

在預設的消息記錄表中記錄待發送消息的關鍵參數和消息類型；

向目標下游業務系統發送所述待發送消息，其中，在所述待發送消息中攜帶上游系統本次消息發送時間和上游系統前次消息發送時間；

當接收到所述目標下游業務系統返回的消息重發請求，所述消息重發請求包含下游系統前次消息接收時間時，查找所述下游系統前次消息接收時間到上游系統本次消息發送時間之間向所述目標下游業務系統發送的消息，而后判斷查找到消息的消息狀態是否為失敗，若否，則將查找到的消息作為新待發送消息并返回所述向目標下游業務系統發送所述待發送消息的步驟，同時將各所述新待發送消息的歷史發送次數加1；

當某新待發送消息的歷史發送次數達到預設的第一重發次數閾值時，將所述新待發送消息的消息狀態設置為失敗，同時丟棄所述新待發送消息；

定時進行任務調度，以從所述消息記錄表中，獲取失敗消息狀態所對應的關鍵參數和消息類型，并根據獲取到的關鍵參數和消息類型，從預設的業務數據庫中查找生成對應目標消息所需的必要參數，而后按照預設的協議規則組裝所述必要參數得到所述目標消息，并向所述目標下游業務系統發送所述目標消息。

在本發明一個實施例中，所述在預設的消息記錄表中記錄待發送消息的關鍵參數和消息類型之前，還包括：

建立所述消息記錄表，以記錄消息的關鍵參數、消息類型、消息狀態、歷史發送次數和發送時間。

在本發明一個實施例中，所述目標消息中攜帶回執請求；