怎么進行RabbitMQ消息的可靠投遞

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

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

• confirmCallback 確認模式

• returnCallback 未投遞到 queue 退回模式

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

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

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

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

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

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

3. 注冊自己實現的MessageRecoverer

4. 給MessageListenerContainer設置RecoveryCallback

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

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

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

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

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

關于怎么進行RabbitMQ消息的可靠投遞問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。