SpringBoot+RabbitMQ，保證消息100%投遞成功並被消費（實例）

來源：https://www.jianshu.com/p/dca01aad6bc8

一、先扔一張圖

說明:

本文涵蓋了關於RabbitMQ很多方面的知識點, 如:

1、消息發送確認機制
2、消費確認機制
3、消息的重新投遞
4、消費冪等性, 等等

這些都是圍繞上面那張整體流程圖展開的, 所以有必要先貼出來, 見圖知意

二、實現思路

1、簡略介紹163郵箱授權碼的獲取
2、編寫發送郵件工具類
3、編寫RabbitMQ配置文件
4、生產者發起調用

三、項目介紹

1、 springboot版本 2.1.5.RELEASE, 舊版本可能有些配置屬性不能使用, 需要以代碼形式進行配置
2、 RabbitMQ版本 3.7.15
3、 MailUtil: 發送郵件工具類
4、 RabbitConfig: rabbitmq相關配置
5、 TestServiceImpl: 生產者, 發送消息
6、 MailConsumer: 消費者, 消費消息, 發送郵件
7、 ResendMsg: 定時任務, 重新投遞發送失敗的消息

說明: 上面是核心代碼, MsgLogServicemapper xml等均未貼出, 完整代碼可以參考我的GitHub, 歡迎fork, https://github.com/wangzaiplus/springboot/tree/wxw

四、代碼實現

1、163郵箱授權碼的獲取, 如圖:

該授權碼就是配置文件 spring.mail.password需要的密碼

說明: exchange routing_key字段是在定時任務重新投遞消息時需要用到的

5、 MailUtil

6、 RabbitConfig

7、 TestServiceImpl生產消息

8、 MailConsumer消費消息, 發送郵件

說明: 其實就完成了3件事: 1.保證消費冪等性, 2.發送郵件, 3.更新消息狀態, 手動ack

9、 ResendMsg定時任務重新投遞發送失敗的消息

說明: 每一條消息都和 exchange routingKey綁定, 所有消息重投共用這一個定時任務即可

五、基本測試

OK, 目前為止, 代碼準備就緒, 現在進行正常流程的測試

1、發送請求:

2、後臺日誌:

3、數據庫消息記錄:

狀態為3, 表明已消費, 消息重試次數為0, 表明一次投遞就成功了

4、查看郵箱

發送成功

六、各種異常情況測試

步驟一羅列了很多關於RabbitMQ的知識點, 很重要, 很核心, 而本文也涉及到了這些知識點的實現, 接下來就通過異常測試進行驗證(這些驗證都是圍繞本文開頭扔的那張流程圖展開的, 很重要, 所以, 再貼一遍)。

1、驗證發送失敗情況

驗證消息發送到Exchange失敗情況下的回調, 對應上圖 P->X

如何驗證? 可以隨便指定一個不存在的交換機名稱, 請求接口, 看是否會觸發回調

發送失敗, 原因:

reply-code=404,reply-text=NOT_FOUND-noexchange'mail.exchangeabcd'invhost'/', 該回調能夠保證消息正確發送到Exchange, 測試完成

2、驗證消息Exchange路由到Queue失敗

驗證消息從Exchange路由到Queue失敗情況下的回調, 對應上圖 X->Q

同理, 修改一下路由鍵為不存在的即可, 路由失敗, 觸發回調

發送失敗, 原因: route:mail.routing.keyabcd,replyCode:312,replyText:NO_ROUTE

3、手動ack模式

驗證在手動ack模式下, 消費端必須進行手動確認(ack), 否則消息會一直保存在隊列中, 直到被消費, 對應上圖 Q->C

將消費端代碼 channel.basicAck(tag,false);// 消費確認註釋掉, 查看控制檯和rabbitmq管控臺

可以看到, 雖然消息確實被消費了, 但是由於是手動確認模式, 而最後又沒手動確認, 所以, 消息仍被rabbitmq保存, 所以, 手動ack能夠保證消息一定被消費, 但一定要記得 basicAck。

4、驗證消費端冪等性

接著上一步, 去掉註釋, 重啟服務器, 由於有一條未被ack的消息, 所以重啟後監聽到消息, 進行消費, 但是由於消費前會判斷該消息的狀態是否未被消費, 發現 status=3, 即已消費, 所以, 直接 return, 這樣就保證了消費端的冪等性, 即使由於網絡等原因投遞成功而未觸發回調, 從而多次投遞, 也不會重複消費進而發生業務異常

5、驗證消費端發生異常消息也不會丟失

很顯然, 消費端代碼可能發生異常, 如果不做處理, 業務沒正確執行, 消息卻不見了, 給我們感覺就是消息丟失了, 由於我們消費端代碼做了異常捕獲, 業務異常時, 會觸發: channel.basicNack(tag,false,true);, 這樣會告訴rabbitmq該消息消費失敗, 需要重新入隊, 可以重新投遞到其他正常的消費端進行消費, 從而保證消息不被丟失

測試: send方法直接返回false即可(這裡跟拋出異常一個意思)

可以看到, 由於 channel.basicNack(tag,false,true), 未被ack的消息(unacked)會重新入隊並被消費, 這樣就保證了消息不會走丟

6、驗證定時任務的消息重投

實際應用場景中, 可能由於網絡原因, 或者消息未被持久化MQ就宕機了, 使得投遞確認的回調方法 ConfirmCallback沒有被執行, 從而導致數據庫該消息狀態一直是 投遞中的狀態, 此時就需要進行消息重投, 即使也許消息已經被消費了

定時任務只是保證消息100%投遞成功, 而多次投遞的消費冪等性需要消費端自己保證

我們可以將回調和消費成功後更新消息狀態的代碼註釋掉, 開啟定時任務, 查看是否重投

可以看到, 消息會重投3次, 超過3次放棄, 將消息狀態置為投遞失敗狀態, 出現這種非正常情況, 就需要人工介入排查原因。

七、拓展: 使用動態代理實現消費端冪等性驗證和消費確認(ack)

不知道大家發現沒有, 在 MailConsumer中, 真正的業務邏輯其實只是發送郵件 mailUtil.send(mail)而已, 但我們又不得不在調用 send方法之前校驗消費冪等性, 發送後, 還要更新消息狀態為"已消費"狀態, 並手動ack, 實際項目中, 可能還有很多生產者-消費者的應用場景, 如記錄日誌, 發送短信等等, 都需要rabbitmq, 如果每次都寫這些重複的公用代碼, 沒必要, 也難以維護, 所以, 我們可以將公共代碼抽離出來, 讓核心業務邏輯只關心自己的實現, 而不用做其他操作, 其實就是AOP

為達到這個目的, 有很多方法, 可以用spring aop, 可以用攔截器, 可以用靜態代理, 也可以用動態代理, 在這裡, 我用的是動態代理

目錄結構如下:

核心代碼就是代理的實現, 這裡就不把所有代碼貼出來了, 只是提供一個思路, 我們要儘可能地把代碼寫的更簡潔更優雅

八、總結

發送郵件其實很簡單, 但深究起來其實有很多需要注意和完善的點, 一個看似很小的知識點, 也可以引申出很多問題, 甚至涉及到方方面面, 這些都需要自己踩坑, 當然我這代碼肯定還有很多不完善和需要優化的點, 希望小夥伴多多提意見和建議。

我的代碼都是經過自測驗證過的, 圖也都是一點一點自己畫的或認真截的, 希望小夥伴能學到一點東西, 路過的點個贊或點個關注唄, 謝謝

閱讀更多 程序員BUG 的文章

關鍵字: 消費 網易郵箱 XML