前一篇文章，寫了消息發送確認的一些內容
就是消息發送成功或失敗的時候,都會調用confirmListener 或者returnListener.
如果消息發送成功,就不考慮了.當消息發送失敗時,怎么處理這個消息呢.
1.自動重發
2.系統預警人工處理等
以上操作,都需要知道是哪條消息,具體什么內容發送失敗了,才能進行后續處理.
在returnListener中,參數是有消息內容,exchange,routingKey 這些內容的.
但是在confirmListener中,卻是什么都沒有,只有個correlationData,而我們打印出的correlationData都是null
看來問題的關鍵就在這個correlationData上了, CorrelationData類只有一個屬性ID, 很明顯,我們在發送消息時,將消息和correlationData的ID做一個綁定,就可以根據id拿到消息. 然后進行重發,報警等操作了.
到發送消息的類里面, 發現AmqpTemplate 里面竟然沒有和CorrelationData相關的方法,沒辦法把CorrelationData.id和消息進行綁定..
找到方法后,下面就非常簡單了.
上面的代碼,message中,也可以setCorrelationId為自己指定的id,這樣方便confirm和return一起處理.
上面將msgId和message關系保存后, 在confirmListener或者returnListener中,就可以根據msgId獲取message進行對於操作.
上面的思路看起來解決了失敗后消息處理的問題.但是實際上卻是不可靠的
3.如果進行confirm的時候,或者return的時候, 失敗了怎么辦?
4.msgId和message的關系要保存多久?
但是上面的思路已經抓到了問題的重點,即msgId和message做綁定.
針對3,4兩個問題,只需要變通下即可解決
方案如下:
發送消息前,綁定並保存msgId和message的關系
當confirm或return回調時,根據ack類別等,分別處理. 例如return或者ack=false則說明有問題,報警, 如果ack=true則刪除關系
(因為return在confirm前,所以一條消息在return后又ack=true的情況也是按return處理)
定時檢查這個綁定關系列表,如果發現一些已經超時(自己設定的超時時間)未被處理(即未return和confirm),則手動處理這些消息.
至此,發送消息基本已經沒問題了.
需要注意如果是自動重發的話,消費端需要做冪等或去重處理.
————————————————
版權聲明：本文為CSDN博主「北京-小北」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq315737546/article/details/66475103