共計 983 個字符，預計需要花費 3 分鐘才能閱讀完成。

這篇“mq 消息丟失問題如何解決”文章的知識點大部分人都不太理解，所以丸趣 TV 小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“mq 消息丟失問題如何解決”文章吧。

1. 生產者存放消息的過程中丟失消息

解決辦法:

(1) 事務機制:(同步方式，不推薦)

對于 RabbitMQ 消息隊列來說，生產者發送數據之前開啟 RabbitMQ 的事務機制 channel.txselect，如果消息沒有進隊列，則生產者受到異常報錯，并進行回滾 channel.txRollback，然后重試發送消息。如果收到了消息，則可以提交事務 channel.txCommit。這是同步操作，會影響性能。

(2) 異步機制:

confirm 模式來解決同步機制的性能問題。每次生產者發送的消息都會分配一個唯一的 id，如果寫入到了 RabbitMQ 隊列中，則 RabbitMQ 會回傳一個 ack 消息，說明這個消息接收成功。如果 RabbitMQ 沒能處理這個消息，則回調 nack 接口。說明需要重試發送消息。

也可以自定義超時時間 + 消息 id 來實現超時等待后重試機制。但可能出現的問題是調用 ack 接口時失敗了，所以會出現消息被發送兩次的問題，這個時候就需要保證消費者消費消息的冪等性。

事務模式和 confirm 模式的區別：

事務機制是同步的，提交事務后悔被阻塞直到提交事務完成后。

confirm 模式異步接收通知，但可能接收不到通知。需要考慮接收不到通知的場景。

2. 消息隊列消息丟失

解決辦法：

(1) 創建 Queue 時, 將其設置為持久化

(2) 發送消息的時候將消息的 deliveryMode 設置為 2(將消息持久化 1: 非持久化,2: 持久化)

(3) 開啟生產者 confirm` 模式，可以重試發送消息。

3. 消費者丟失消息

解決辦法：

關閉 RabbitMQ 的自動 ack，每次生產者將消息寫入消息隊列后，就自動回傳一個 ack 給生產者。

消費者處理完消息再主動 ack，告訴消息隊列我處理完了。

4. 總結

(1) 開啟生產者消息手動確認機制

(2) 開啟消息持久化，隊列持久化，交換機持久化 (默認開啟)

(3) 開啟消費者消息手動確認機制

以上就是關于“mq 消息丟失問題如何解決”這篇文章的內容，相信大家都有了一定的了解，希望丸趣 TV 小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注丸趣 TV 行業資訊頻道。