怎么進(jìn)行RabbitMQ消息的可靠投遞

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

mq 提供了兩種方式確認(rèn)消息的可靠投遞

• confirmCallback 確認(rèn)模式

• returnCallback 未投遞到 queue 退回模式

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

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

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

對于消息異常，可以使用以下方法進(jìn)行解決

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

2. 給隊(duì)列綁定死信隊(duì)列，因?yàn)槟J(rèn)的RepublishMessageRecoverer會(huì)發(fā)送nack并且requeue為false。這樣拋出一場是這種方式和上面的結(jié)果一樣都是轉(zhuǎn)發(fā)到了另外一個(gè)隊(duì)列。詳見DeadLetterConsumer

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

4. 給MessageListenerContainer設(shè)置RecoveryCallback

5. 對于方法手動(dòng)捕獲異常，進(jìn)行處理

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

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

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

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

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