Rabbitmq作為高并發(fā)的消息中間件，本文不在闡述基礎概念。旨在分析與提供解決消息的丟失與重復的解決思路。

RabbitMQ架構流程圖

根據以上架構圖，要明白消息走向的整個流程，生產者發(fā)送消息——》交換機(路由器)——》隊列——》被消費者消費。以上幾個流程任何環(huán)節(jié)出問題都會導致消息的丟失，下面詳細分情況介紹。

一、消息丟失

首要前提是設置了隊列，交換器都是可持久化的，更重要的是設置了消息的手動確認

通過以上兩張源碼截圖可以發(fā)現隊列和交換機默認都是可持久化的，如下設置手動消息確認

1.發(fā)送者發(fā)送失敗(網絡原因等)

1.1 沒有正常發(fā)送到exchange路由器(交換機)

該方法ack參數為false時說明消息沒有被正確發(fā)送到路由器，可將該消息保存本地消息表，使用任務調度器重新發(fā)送

1.2沒有被正確的路由到隊列

進入該方法returnedMessage，則表明未被正確路由到消息隊列，具體原因可以看replyCode和replyText，比如綁定規(guī)則有誤等，可將該消息保存本地消息表，使用任務調度器重新發(fā)送。

至此發(fā)送端的消息丟失已經解決，我們在看下消費端的。

1.3消息在消費端處理業(yè)務時沒有做異常處理就確認，從而使消息被移除隊列導致消息丟失

在此處分兩種情況，一，消息被正確消費則basicAck，從隊列刪除消息。二，消息在處理業(yè)務時發(fā)生異常未被正確消費basicReject，不要重新入隊列，而是本地消息表中記錄，使用任務調度器重新發(fā)送。

二、消息去重

基于業(yè)務邏輯進行去重，不要依賴rabbitmq。在消費端應該有一個本地消息消費表記錄已經被成功消費的消息信息，業(yè)務字段主鍵作為去重標準。

最后，有人會反思用了按照以上方案，用了rabbitmq還用本地消息表，降低了性能，在生產端我們消息失敗表的記錄，重新發(fā)送并且重新消費成功，就可以刪除該條記錄了，該表的記錄不會太大，還有就是消費端的未正常消費的記錄同理操作。去重表最好借助redis保存業(yè)務主鍵快速識別是否已經被消費，在判斷是重復消息時一定要記得basicAck手工確認，避免再次發(fā)送。

總結

以上是生活随笔為你收集整理的rabbitmq如何保证消息不丢失_RabbitMQ的去重与防止消息的丢失的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。