如何用SpringBoot和RabbitMQ實(shí)現(xiàn)消息發(fā)送成功

一、先扔一張圖

說(shuō)明:

SpringBoot

SpringBoot是由Pivotal團(tuán)隊(duì)在2013年開始研發(fā)、2014年4月發(fā)布第一個(gè)版本的全新開源的輕量級(jí)框架。它基于Spring4.0設(shè)計(jì)，不僅繼承了Spring框架原有的優(yōu)秀特性，而且還通過(guò)簡(jiǎn)化配置來(lái)進(jìn)一步簡(jiǎn)化了Spring應(yīng)用的整個(gè)搭建和開發(fā)過(guò)程。另外SpringBoot通過(guò)集成大量的框架使得依賴包的版本沖突，以及引用的不穩(wěn)定性等問(wèn)題得到了很好的解決。

SpringBoot特征

（1）可以創(chuàng)建獨(dú)立的Spring應(yīng)用程序，并且基于其Maven或Gradle插件，可以創(chuàng)建可執(zhí)行的JARs和WARs；

（2）內(nèi)嵌Tomcat或Jetty等Servlet容器；

（3）提供自動(dòng)配置的“starter”項(xiàng)目對(duì)象模型（POMS）以簡(jiǎn)化Maven配置；

（4）盡可能自動(dòng)配置Spring容器；

（5）提供準(zhǔn)備好的特性，如指標(biāo)、健康檢查和外部化配置；

（6）絕對(duì)沒(méi)有代碼生成，不需要XML配置。

MQ全稱為Message Queue, 消息隊(duì)列(MQ)是一種應(yīng)用程序?qū)?yīng)用程序的通信方法。應(yīng)用程序通過(guò)讀寫出入隊(duì)列的消息(針對(duì)應(yīng)用程序的數(shù)據(jù))來(lái)通信，而無(wú)需專用連接來(lái)鏈接它們。消息傳遞指的是程序之間通過(guò)在消息中發(fā)送數(shù)據(jù)進(jìn)行通信，而不是通過(guò)直接調(diào)用彼此來(lái)通信，直接調(diào)用通常是用于諸如遠(yuǎn)程過(guò)程調(diào)用的技術(shù)。排隊(duì)指的是應(yīng)用程序通過(guò) 隊(duì)列來(lái)通信。隊(duì)列的使用除去了接收和發(fā)送應(yīng)用程序同時(shí)執(zhí)行的要求。其中較為成熟的MQ產(chǎn)品有IBM WEBSPHERE MQ等等。

二、實(shí)現(xiàn)思路

1. 簡(jiǎn)略介紹163郵箱授權(quán)碼的獲取

2. 編寫發(fā)送郵件工具類

3. 編寫RabbitMQ配置文件

4. 生產(chǎn)者發(fā)起調(diào)用

5. 消費(fèi)者發(fā)送郵件

6. 定時(shí)任務(wù)定時(shí)拉取投遞失敗的消息, 重新投遞

7. 各種異常情況的測(cè)試驗(yàn)證

8. 拓展: 使用動(dòng)態(tài)代理實(shí)現(xiàn)消費(fèi)端冪等性驗(yàn)證和消息確認(rèn)(ack)

三、項(xiàng)目介紹

1. springboot版本2.1.5.RELEASE, 舊版本可能有些配置屬性不能使用, 需要以代碼形式進(jìn)行配置

2. RabbitMQ版本3.7.15

3. MailUtil: 發(fā)送郵件工具類

4. RabbitConfig: rabbitmq相關(guān)配置

5. TestServiceImpl: 生產(chǎn)者, 發(fā)送消息

6. MailConsumer: 消費(fèi)者, 消費(fèi)消息, 發(fā)送郵件

7. ResendMsg: 定時(shí)任務(wù), 重新投遞發(fā)送失敗的消息

四、代碼實(shí)現(xiàn)

1. 163郵箱授權(quán)碼的獲取, 如圖:

   
   

   該授權(quán)碼就是配置文件spring.mail.password需要的密碼
   

2.pom

3.rabbitmq、郵箱配置

說(shuō)明: password即授權(quán)碼, username和from要一致

4.表結(jié)構(gòu)

說(shuō)明: exchange routing_key字段是在定時(shí)任務(wù)重新投遞消息時(shí)需要用到的

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回調(diào)必須設(shè)置mandatory=true, 否則Exchange沒(méi)有找到Queue就會(huì)丟棄掉消息, 而不會(huì)觸發(fā)回調(diào)
        rabbitTemplate.setMandatory(true);
        // 消息是否從Exchange路由到Queue, 注意: 這是一個(gè)失敗回調(diào), 只有消息從Exchange路由到Queue失敗才會(huì)回調(diào)這個(gè)方法
        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生產(chǎn)消息

8.MailConsumer消費(fèi)消息, 發(fā)送郵件

說(shuō)明: 其實(shí)就完成了3件事: 1.保證消費(fèi)冪等性, 2.發(fā)送郵件, 3.更新消息狀態(tài), 手動(dòng)ack

9.ResendMsg定時(shí)任務(wù)重新投遞發(fā)送失敗的消息

五、基本測(cè)試

OK, 目前為止, 代碼準(zhǔn)備就緒, 現(xiàn)在進(jìn)行正常流程的測(cè)試

1. 發(fā)送請(qǐng)求:

   
   

1. 后臺(tái)日志:

1. 數(shù)據(jù)庫(kù)消息記錄:

   
   

2. 狀態(tài)為3, 表明已消費(fèi), 消息重試次數(shù)為0, 表明一次投遞就成功了
   

3. 查看郵箱

   
   

發(fā)送成功

六、各種異常情況測(cè)試

步驟一羅列了很多關(guān)于RabbitMQ的知識(shí)點(diǎn), 很重要, 很核心, 而本文也涉及到了這些知識(shí)點(diǎn)的實(shí)現(xiàn), 接下來(lái)就通過(guò)異常測(cè)試進(jìn)行驗(yàn)證(這些驗(yàn)證都是圍繞本文開頭扔的那張流程圖展開的, 很重要, 所以, 再貼一遍)

1. 驗(yàn)證消息發(fā)送到Exchange失敗情況下的回調(diào), 對(duì)應(yīng)上圖P -> X

如何驗(yàn)證? 可以隨便指定一個(gè)不存在的交換機(jī)名稱, 請(qǐng)求接口, 看是否會(huì)觸發(fā)回調(diào)

發(fā)送失敗, 原因: reply-code=404, reply-text=NOT_FOUND - no exchange 'mail.exchangeabcd' in vhost '/', 該回調(diào)能夠保證消息正確發(fā)送到Exchange, 測(cè)試完成

1. 驗(yàn)證消息從Exchange路由到Queue失敗情況下的回調(diào), 對(duì)應(yīng)上圖X -> Q

同理, 修改一下路由鍵為不存在的即可, 路由失敗, 觸發(fā)回調(diào)

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

1. 驗(yàn)證在手動(dòng)ack模式下, 消費(fèi)端必須進(jìn)行手動(dòng)確認(rèn)(ack), 否則消息會(huì)一直保存在隊(duì)列中, 直到被消費(fèi), 對(duì)應(yīng)上圖Q -> C

將消費(fèi)端代碼channel.basicAck(tag, false);// 消費(fèi)確認(rèn)注釋掉, 查看控制臺(tái)和rabbitmq管控臺(tái)

可以看到, 雖然消息確實(shí)被消費(fèi)了, 但是由于是手動(dòng)確認(rèn)模式, 而最后又沒(méi)手動(dòng)確認(rèn), 所以, 消息仍被rabbitmq保存, 所以, 手動(dòng)ack能夠保證消息一定被消費(fèi), 但一定要記得basicAck

1. 驗(yàn)證消費(fèi)端冪等性

接著上一步, 去掉注釋, 重啟服務(wù)器, 由于有一條未被ack的消息, 所以重啟后監(jiān)聽到消息, 進(jìn)行消費(fèi), 但是由于消費(fèi)前會(huì)判斷該消息的狀態(tài)是否未被消費(fèi), 發(fā)現(xiàn)status=3, 即已消費(fèi), 所以, 直接return, 這樣就保證了消費(fèi)端的冪等性, 即使由于網(wǎng)絡(luò)等原因投遞成功而未觸發(fā)回調(diào), 從而多次投遞, 也不會(huì)重復(fù)消費(fèi)進(jìn)而發(fā)生業(yè)務(wù)異常

1. 驗(yàn)證消費(fèi)端發(fā)生異常消息也不會(huì)丟失

很顯然, 消費(fèi)端代碼可能發(fā)生異常, 如果不做處理, 業(yè)務(wù)沒(méi)正確執(zhí)行, 消息卻不見(jiàn)了, 給我們感覺(jué)就是消息丟失了, 由于我們消費(fèi)端代碼做了異常捕獲, 業(yè)務(wù)異常時(shí), 會(huì)觸發(fā): channel.basicNack(tag, false, true);, 這樣會(huì)告訴rabbitmq該消息消費(fèi)失敗, 需要重新入隊(duì), 可以重新投遞到其他正常的消費(fèi)端進(jìn)行消費(fèi), 從而保證消息不被丟失

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

可以看到, 由于channel.basicNack(tag, false, true), 未被ack的消息(unacked)會(huì)重新入隊(duì)并被消費(fèi), 這樣就保證了消息不會(huì)走丟

1. 驗(yàn)證定時(shí)任務(wù)的消息重投

實(shí)際應(yīng)用場(chǎng)景中, 可能由于網(wǎng)絡(luò)原因, 或者消息未被持久化MQ就宕機(jī)了, 使得投遞確認(rèn)的回調(diào)方法ConfirmCallback沒(méi)有被執(zhí)行, 從而導(dǎo)致數(shù)據(jù)庫(kù)該消息狀態(tài)一直是投遞中的狀態(tài), 此時(shí)就需要進(jìn)行消息重投, 即使也許消息已經(jīng)被消費(fèi)了

定時(shí)任務(wù)只是保證消息100%投遞成功, 而多次投遞的消費(fèi)冪等性需要消費(fèi)端自己保證

我們可以將回調(diào)和消費(fèi)成功后更新消息狀態(tài)的代碼注釋掉, 開啟定時(shí)任務(wù), 查看是否重投

可以看到, 消息會(huì)重投3次, 超過(guò)3次放棄, 將消息狀態(tài)置為投遞失敗狀態(tài), 出現(xiàn)這種非正常情況, 就需要人工介入排查原因

七、拓展: 使用動(dòng)態(tài)代理實(shí)現(xiàn)消費(fèi)端冪等性驗(yàn)證和消費(fèi)確認(rèn)(ack)

不知道大家發(fā)現(xiàn)沒(méi)有, 在MailConsumer中, 真正的業(yè)務(wù)邏輯其實(shí)只是發(fā)送郵件mailUtil.send(mail)而已, 但我們又不得不在調(diào)用send方法之前校驗(yàn)消費(fèi)冪等性, 發(fā)送后, 還要更新消息狀態(tài)為"已消費(fèi)"狀態(tài), 并手動(dòng)ack, 實(shí)際項(xiàng)目中, 可能還有很多生產(chǎn)者-消費(fèi)者的應(yīng)用場(chǎng)景, 如記錄日志, 發(fā)送短信等等, 都需要rabbitmq, 如果每次都寫這些重復(fù)的公用代碼, 沒(méi)必要, 也難以維護(hù), 所以, 我們可以將公共代碼抽離出來(lái), 讓核心業(yè)務(wù)邏輯只關(guān)心自己的實(shí)現(xiàn), 而不用做其他操作, 其實(shí)就是AOP

為達(dá)到這個(gè)目的, 有很多方法, 可以用spring aop, 可以用攔截器, 可以用靜態(tài)代理, 也可以用動(dòng)態(tài)代理, 在這里, 我用的是動(dòng)態(tài)代理

目錄結(jié)構(gòu)如下:

核心代碼就是代理的實(shí)現(xiàn), 這里就不把所有代碼貼出來(lái)了, 只是提供一個(gè)思路, 我們要盡可能地把代碼寫的更簡(jiǎn)潔更優(yōu)雅