怎么進行RabbitMQ消息的可靠投遞，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

網(wǎng)站建設哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、成都微信小程序、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了寧江免費建站歡迎大家使用！

mq 提供了兩種方式確認消息的可靠投遞

• confirmCallback 確認模式

• returnCallback 未投遞到 queue 退回模式

在使用 RabbitMQ 的時候，作為消息發(fā)送方希望杜絕任何消息丟失或者投遞失敗場景。RabbitMQ 為我們提供了兩個選項用來控制消息的投遞可靠性模式。

rabbitmq 整個消息投遞的路徑為：
producer->rabbitmq broker cluster->exchange->queue->consumer

message 從 producer 到 rabbitmq broker cluster 則會返回一個 confirmCallback 。
message 從 exchange->queue 投遞失敗則會返回一個 returnCallback 。我們將利用這兩個 callback 控制消息的最終一致性和部分糾錯能力。

對于消息異常，可以使用以下方法進行解決

1. 使用RepublishMessageRecoverer這個MessageRecoverer會發(fā)送發(fā)送消息到指定隊列

2. 給隊列綁定死信隊列，因為默認的RepublishMessageRecoverer會發(fā)送nack并且requeue為false。這樣拋出一場是這種方式和上面的結果一樣都是轉發(fā)到了另外一個隊列。詳見DeadLetterConsumer

3. 注冊自己實現(xiàn)的MessageRecoverer

4. 給MessageListenerContainer設置RecoveryCallback

5. 對于方法手動捕獲異常，進行處理

rabbitTemplate的發(fā)送流程是這樣的：  
1 發(fā)送數(shù)據(jù)并返回(不確認rabbitmq服務器已成功接收)  
2 異步的接收從rabbitmq返回的ack確認信息  
3 收到ack后調用confirmCallback函數(shù)  
注意：     在confirmCallback中是沒有原message的，所以無法在這個函數(shù)中調用重發(fā)，confirmCallback只有一個通知的作用。

 最安全的做法是是使用事務，但是這樣效率就會很低，每秒鐘處理的message在幾百條左右。對于高性能的 mq 來說是非常不可取的。

另一種解決方法如下：在rabbitTemplate異步確認的基礎上
1 在本地緩存已發(fā)送的 message
2 通過 confirmCallback 或者被確認的 ack，將被確認的message從本地刪除
3 定時掃描本地的message，如果大于一定時間未被確認，則重發(fā)

這種解決方式也有一定的問題：
想象這種場景，rabbitmq接收到了消息，在發(fā)送ack確認時，網(wǎng)絡斷了，造成客戶端沒有收到ack，重發(fā)消息。（相比于丟失消息，重發(fā)消息要好解決的多，我們可以在consumer端做到冪等）。

關于怎么進行RabbitMQ消息的可靠投遞問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關知識。