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端做到冪等）。

 

 

 

 

 

參考文獻：

https://segmentfault.com/a/1190000016041620

https://www.jianshu.com/p/6579e48d18ae

https://github.com/littlersmall/rabbitmq-access/blob/master/src/main/java/com/littlersmall/rabbitmqaccess/MQAccessBuilder.java

https://www.jianshu.com/p/6579e48d18ae