說明:
SpringBoot
SpringBoot是由Pivotal團隊在2013年開始研發(fā)、2014年4月發(fā)布第一個版本的全新開源的輕量級框架。它基于Spring4.0設計，不僅繼承了Spring框架原有的優(yōu)秀特性，而且還通過簡化配置來進一步簡化了Spring應用的整個搭建和開發(fā)過程。另外SpringBoot通過集成大量的框架使得依賴包的版本沖突，以及引用的不穩(wěn)定性等問題得到了很好的解決。
SpringBoot特征
（1）可以創(chuàng)建獨立的Spring應用程序，并且基于其Maven或Gradle插件，可以創(chuàng)建可執(zhí)行的JARs和WARs；
（2）內嵌Tomcat或Jetty等Servlet容器；
（3）提供自動配置的“starter”項目對象模型（POMS）以簡化Maven配置；
（4）盡可能自動配置Spring容器；
（5）提供準備好的特性，如指標、健康檢查和外部化配置；
（6）絕對沒有代碼生成，不需要XML配置。
MQ全稱為Message Queue, 消息隊列(MQ)是一種應用程序對應用程序的通信方法。應用程序通過讀寫出入隊列的消息(針對應用程序的數據)來通信，而無需專用連接來鏈接它們。消息傳遞指的是程序之間通過在消息中發(fā)送數據進行通信，而不是通過直接調用彼此來通信，直接調用通常是用于諸如遠程過程調用的技術。排隊指的是應用程序通過 隊列來通信。隊列的使用除去了接收和發(fā)送應用程序同時執(zhí)行的要求。其中較為成熟的MQ產品有IBM WEBSPHERE MQ等等。
簡略介紹163郵箱授權碼的獲取
編寫發(fā)送郵件工具類
編寫RabbitMQ配置文件
生產者發(fā)起調用
消費者發(fā)送郵件
定時任務定時拉取投遞失敗的消息, 重新投遞
各種異常情況的測試驗證
拓展: 使用動態(tài)代理實現(xiàn)消費端冪等性驗證和消息確認(ack)
springboot版本2.1.5.RELEASE, 舊版本可能有些配置屬性不能使用, 需要以代碼形式進行配置
RabbitMQ版本3.7.15
MailUtil: 發(fā)送郵件工具類
RabbitConfig: rabbitmq相關配置
TestServiceImpl: 生產者, 發(fā)送消息
MailConsumer: 消費者, 消費消息, 發(fā)送郵件
ResendMsg: 定時任務, 重新投遞發(fā)送失敗的消息
163郵箱授權碼的獲取, 如圖:
該授權碼就是配置文件spring.mail.password需要的密碼
2.pom
3.rabbitmq、郵箱配置
說明:
password即授權碼,username和from要一致
4.表結構
說明: exchange routing_key字段是在定時任務重新投遞消息時需要用到的
5.MailUtil
6.RabbitConfig
重慶分公司
重慶分公司
@Configuration@Slf4jpublic class RabbitConfig {
@Autowired
private CachingConnectionFactory connectionFactory;
@Autowired
private MsgLogService msgLogService;
@Bean
public RabbitTemplate rabbitTemplate() {
RabbitTemplate rabbitTemplate = new RabbitTemplate(connectionFactory);
rabbitTemplate.setMessageConverter(converter());
// 消息是否成功發(fā)送到Exchange
rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
if (ack) {
log.info("消息成功發(fā)送到Exchange");
String msgId = correlationData.getId();
msgLogService.updateStatus(msgId, Constant.MsgLogStatus.DELIVER_SUCCESS);
} else {
log.info("消息發(fā)送到Exchange失敗, {}, cause: {}", correlationData, cause);
}
});
// 觸發(fā)setReturnCallback回調必須設置mandatory=true, 否則Exchange沒有找到Queue就會丟棄掉消息, 而不會觸發(fā)回調
rabbitTemplate.setMandatory(true);
// 消息是否從Exchange路由到Queue, 注意: 這是一個失敗回調, 只有消息從Exchange路由到Queue失敗才會回調這個方法
rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
log.info("消息從Exchange路由到Queue失敗: exchange: {}, route: {}, replyCode: {}, replyText: {}, message: {}", exchange, routingKey, replyCode, replyText, message);
});
return rabbitTemplate;
}
@Bean
public Jackson2JsonMessageConverter converter() {
return new Jackson2JsonMessageConverter();
}
// 發(fā)送郵件
public static final String MAIL_QUEUE_NAME = "mail.queue";
public static final String MAIL_EXCHANGE_NAME = "mail.exchange";
public static final String MAIL_ROUTING_KEY_NAME = "mail.routing.key";
@Bean
public Queue mailQueue() {
return new Queue(MAIL_QUEUE_NAME, true);
}
@Bean
public DirectExchange mailExchange() {
return new DirectExchange(MAIL_EXCHANGE_NAME, true, false);
}
@Bean
public Binding mailBinding() {
return BindingBuilder.bind(mailQueue()).to(mailExchange()).with(MAIL_ROUTING_KEY_NAME);
}}7.TestServiceImpl生產消息
8.MailConsumer消費消息, 發(fā)送郵件
說明: 其實就完成了3件事: 1.保證消費冪等性, 2.發(fā)送郵件, 3.更新消息狀態(tài), 手動ack
9.ResendMsg定時任務重新投遞發(fā)送失敗的消息
OK, 目前為止, 代碼準備就緒, 現(xiàn)在進行正常流程的測試
發(fā)送請求:
后臺日志:
數據庫消息記錄:
狀態(tài)為3, 表明已消費, 消息重試次數為0, 表明一次投遞就成功了
查看郵箱
發(fā)送成功
步驟一羅列了很多關于RabbitMQ的知識點, 很重要, 很核心, 而本文也涉及到了這些知識點的實現(xiàn), 接下來就通過異常測試進行驗證(這些驗證都是圍繞本文開頭扔的那張流程圖展開的, 很重要, 所以, 再貼一遍)
驗證消息發(fā)送到Exchange失敗情況下的回調, 對應上圖P -> X
如何驗證? 可以隨便指定一個不存在的交換機名稱, 請求接口, 看是否會觸發(fā)回調
發(fā)送失敗, 原因:reply-code=404, reply-text=NOT_FOUND - no exchange 'mail.exchangeabcd' in vhost '/', 該回調能夠保證消息正確發(fā)送到Exchange, 測試完成
驗證消息從Exchange路由到Queue失敗情況下的回調, 對應上圖X -> Q
同理, 修改一下路由鍵為不存在的即可, 路由失敗, 觸發(fā)回調
發(fā)送失敗, 原因:route: mail.routing.keyabcd, replyCode: 312, replyText: NO_ROUTE
驗證在手動ack模式下, 消費端必須進行手動確認(ack), 否則消息會一直保存在隊列中, 直到被消費, 對應上圖Q -> C
將消費端代碼channel.basicAck(tag, false);// 消費確認注釋掉, 查看控制臺和rabbitmq管控臺
可以看到, 雖然消息確實被消費了, 但是由于是手動確認模式, 而最后又沒手動確認, 所以, 消息仍被rabbitmq保存, 所以, 手動ack能夠保證消息一定被消費, 但一定要記得basicAck
驗證消費端冪等性
接著上一步, 去掉注釋, 重啟服務器, 由于有一條未被ack的消息, 所以重啟后監(jiān)聽到消息, 進行消費, 但是由于消費前會判斷該消息的狀態(tài)是否未被消費, 發(fā)現(xiàn)status=3, 即已消費, 所以, 直接return, 這樣就保證了消費端的冪等性, 即使由于網絡等原因投遞成功而未觸發(fā)回調, 從而多次投遞, 也不會重復消費進而發(fā)生業(yè)務異常
驗證消費端發(fā)生異常消息也不會丟失
很顯然, 消費端代碼可能發(fā)生異常, 如果不做處理, 業(yè)務沒正確執(zhí)行, 消息卻不見了, 給我們感覺就是消息丟失了, 由于我們消費端代碼做了異常捕獲, 業(yè)務異常時, 會觸發(fā):channel.basicNack(tag, false, true);, 這樣會告訴rabbitmq該消息消費失敗, 需要重新入隊, 可以重新投遞到其他正常的消費端進行消費, 從而保證消息不被丟失
測試: send方法直接返回false即可(這里跟拋出異常一個意思)
可以看到, 由于channel.basicNack(tag, false, true), 未被ack的消息(unacked)會重新入隊并被消費, 這樣就保證了消息不會走丟
驗證定時任務的消息重投
實際應用場景中, 可能由于網絡原因, 或者消息未被持久化MQ就宕機了, 使得投遞確認的回調方法ConfirmCallback沒有被執(zhí)行, 從而導致數據庫該消息狀態(tài)一直是投遞中的狀態(tài), 此時就需要進行消息重投, 即使也許消息已經被消費了
定時任務只是保證消息100%投遞成功, 而多次投遞的消費冪等性需要消費端自己保證
我們可以將回調和消費成功后更新消息狀態(tài)的代碼注釋掉, 開啟定時任務, 查看是否重投
可以看到, 消息會重投3次, 超過3次放棄, 將消息狀態(tài)置為投遞失敗狀態(tài), 出現(xiàn)這種非正常情況, 就需要人工介入排查原因
不知道大家發(fā)現(xiàn)沒有, 在MailConsumer中, 真正的業(yè)務邏輯其實只是發(fā)送郵件mailUtil.send(mail)而已, 但我們又不得不在調用send方法之前校驗消費冪等性, 發(fā)送后, 還要更新消息狀態(tài)為"已消費"狀態(tài), 并手動ack, 實際項目中, 可能還有很多生產者-消費者的應用場景, 如記錄日志, 發(fā)送短信等等, 都需要rabbitmq, 如果每次都寫這些重復的公用代碼, 沒必要, 也難以維護, 所以, 我們可以將公共代碼抽離出來, 讓核心業(yè)務邏輯只關心自己的實現(xiàn), 而不用做其他操作, 其實就是AOP
為達到這個目的, 有很多方法, 可以用spring aop, 可以用攔截器, 可以用靜態(tài)代理, 也可以用動態(tài)代理, 在這里, 我用的是動態(tài)代理
目錄結構如下:
核心代碼就是代理的實現(xiàn), 這里就不把所有代碼貼出來了, 只是提供一個思路, 我們要盡可能地把代碼寫的更簡潔更優(yōu)雅
創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網絡助力業(yè)務部署。公司持有工信部辦法的idc、isp許可證， 機房獨有T級流量清洗系統(tǒng)配攻擊溯源，準確進行流量調度，確保服務器高可用性。佳節(jié)活動現(xiàn)已開啟，新人活動云服務器買多久送多久。
