[發明專利]隊列消息一致性的實現方法、裝置、設備及存儲介質

有效

• 申請號: 201711181692.4
• 申請日: 2017-11-23
• 公開（公告）號: CN108009027B
• 公開（公告）日: 2019-09-20
• 發明（設計）人: 吳金霖
• 申請（專利權）人: 北京百度網訊科技有限公司
• 主分類號: G06F9/54
• 分類號: G06F9/54
• 代理公司: 北京鴻德海業知識產權代理事務所(普通合伙) 11412
• 代理人: 袁媛

本發明公開了隊列消息一致性的實現方法、裝置、設備及存儲介質，其中方法包括：消息發送方開啟數據庫事務及消息事務，并創建消息，進行數據庫事務及消息事務提交，提交成功，將消息發送給消息接收方，消息的頭部攜帶有消息的UUID以及replyTo的隊列地址；消息接收方接收到消息后，開啟消息事務及數據庫事務，將消息的UUID保存到數據庫中，并在執行業務邏輯成功后分別提交數據庫事務及消息事務，提交成功，根據replyTo的隊列地址，向消息發送方返回針對消息的消費成功確認消息。本發明所述方案提供了一個完整的隊列消息一致性的框架模型，從而提升了系統性能等。

【技術領域】

本發明涉及業務處理技術，特別涉及隊列消息一致性的實現方法、裝置、設備及存儲介質。

【背景技術】

在業務系統中，兩個服務間通常會使用消息中間件來進行通信，如ActiveMQ、RabbittMQ等。消息通常包括隊列消息(Queue)和訂閱消息(Topic)兩種，本發明中主要關注隊列消息。

在實際應用中，消息發送方通常會執行寫數據庫和發送消息的操作，消息接收方接收到消息后對消息進行處理，需要確保消息在發送方和接收方的一致性，即雙方正確發送和消費了消息，并根據消息正確處理了業務邏輯等。

要確保一致性，消息發送方寫數據庫和發送消息的操作均要成功，消息接收方接收到消息后要保證業務正確運行，消息要保證不丟失，消息接收方一定能夠接收到消息，接收方對同一個消息只能消費一次等。上述過程中的任何一個環節出現問題都會導致不一致。

目前業界僅存在一些針對單個環節的解決方案，而沒有一個完整的解決方案，從而影響了系統性能。

【發明內容】

有鑒于此，本發明提供了隊列消息一致性的實現方法、裝置、設備及存儲介質。

具體技術方案如下：

一種隊列消息一致性的實現方法，包括：

消息發送方開啟數據庫事務及消息事務，并創建消息；

所述消息發送方進行數據庫事務及消息事務提交，提交成功，將所述消息發送給消息接收方，所述消息的頭部攜帶有所述消息的通用唯一識別碼UUID以及回復replyTo的隊列地址，以便所述消息接收方接收到所述消息后，開啟消息事務及數據庫事務，將所述消息的UUID保存到數據庫中，并在執行業務邏輯成功后分別提交數據庫事務及消息事務，提交成功，根據所述replyTo的隊列地址，向所述消息發送方返回針對所述消息的消費成功確認消息。

根據本發明一優選實施例，該方法進一步包括：

所述消息發送方創建消息之后，執行保存消息到數據庫的操作，待數據庫事務提交成功后，將所述消息真正地保存到數據庫中；

所述消息發送方執行發送消息的操作，待消息事務提交成功后，將所述消息真正地發送給所述消息接收方。

根據本發明一優選實施例，該方法進一步包括：

所述消息發送方執行發送消息的操作之后，執行業務邏輯，執行成功，提交數據庫事務；

若在數據庫事務提交成功之前的操作出現異常，則所述消息發送方觸發消息事務回滾及數據庫事務回滾；

若在數據庫事務提交成功后，消息事務提交異常，則所述消息發送方觸發消息事務回滾。

根據本發明一優選實施例，該方法進一步包括：

所述消息發送方執行保存消息到數據庫的操作之后，將所述消息的狀態設置為已發送待確認RUNNING狀態；

若消息事務提交異常，則所述消息發送方將數據庫中保存的所述消息的狀態修改為未發送WAITING狀態；