springboot + rabbitmq 用了訊息確認機制,感覺掉坑裡了

程式設計師小富發表於2020-07-01

本文收錄在個人部落格:www.chengxy-nds.top,技術資源共享,一起進步

最近部門號召大夥多組織一些技術分享會,說是要活躍公司的技術氛圍,但早就看穿一切的我知道,這 T M 就是為了刷KPI。不過,話說回來這的確是件好事,與其開那些沒味的扯皮會,多做技術交流還是很有助於個人成長的。

於是乎我主動報名參加了分享,咳咳咳~ ,真的不是為了那點KPI,就是想和大夥一起學習學習!

在這裡插入圖片描述

這次我分享的是 springboot + rabbitmq 如何實現訊息確認機制,以及在實際開發中的一點踩坑經驗,其實整體的內容比較簡單,有時候事情就是這麼神奇,越是簡單的東西就越容易出錯。

可以看到使用了 RabbitMQ 以後,我們的業務鏈路明顯變長了,雖然做到了系統間的解耦,但可能造成訊息丟失的場景也增加了。例如:

  • 訊息生產者 - > rabbitmq伺服器(訊息傳送失敗)

  • rabbitmq伺服器自身故障導致訊息丟失

  • 訊息消費者 - > rabbitmq服務(消費訊息失敗)

在這裡插入圖片描述
所以說能不使用中介軟體就儘量不要用,如果為了用而用只會徒增煩惱。開啟訊息確認機制以後,儘管很大程度上保證了訊息的準確送達,但由於頻繁的確認互動,rabbitmq 整體效率變低,吞吐量下降嚴重,不是非常重要的訊息真心不建議你用訊息確認機制。


下邊我們先來實現springboot + rabbitmq訊息確認機制,再對遇到的問題做具體分析。

一、準備環境

1、引入 rabbitmq 依賴包

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

2、修改 application.properties 配置

配置中需要開啟 傳送端消費端 的訊息確認。

spring.rabbitmq.host=127.0.0.1
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

# 傳送者開啟 confirm 確認機制
spring.rabbitmq.publisher-confirms=true
# 傳送者開啟 return 確認機制
spring.rabbitmq.publisher-returns=true
####################################################
# 設定消費端手動 ack
spring.rabbitmq.listener.simple.acknowledge-mode=manual
# 是否支援重試
spring.rabbitmq.listener.simple.retry.enabled=true

3、定義 Exchange 和 Queue

定義交換機 confirmTestExchange 和佇列 confirm_test_queue ,並將佇列繫結在交換機上。

@Configuration
public class QueueConfig {

    @Bean(name = "confirmTestQueue")
    public Queue confirmTestQueue() {
        return new Queue("confirm_test_queue", true, false, false);
    }

    @Bean(name = "confirmTestExchange")
    public FanoutExchange confirmTestExchange() {
        return new FanoutExchange("confirmTestExchange");
    }

    @Bean
    public Binding confirmTestFanoutExchangeAndQueue(
            @Qualifier("confirmTestExchange") FanoutExchange confirmTestExchange,
            @Qualifier("confirmTestQueue") Queue confirmTestQueue) {
        return BindingBuilder.bind(confirmTestQueue).to(confirmTestExchange);
    }
}

rabbitmq 的訊息確認分為兩部分:傳送訊息確認 和 訊息接收確認。

在這裡插入圖片描述

二、訊息傳送確認

傳送訊息確認:用來確認生產者 producer 將訊息傳送到 brokerbroker 上的交換機 exchange 再投遞給佇列 queue的過程中,訊息是否成功投遞。

訊息從 producerrabbitmq broker有一個 confirmCallback 確認模式。

訊息從 exchangequeue 投遞失敗有一個 returnCallback 退回模式。

我們可以利用這兩個Callback來確保消的100%送達。

1、 ConfirmCallback確認模式

訊息只要被 rabbitmq broker 接收到就會觸發 confirmCallback 回撥 。

@Slf4j
@Component
public class ConfirmCallbackService implements RabbitTemplate.ConfirmCallback {

    @Override
    public void confirm(CorrelationData correlationData, boolean ack, String cause) {

        if (!ack) {
            log.error("訊息傳送異常!");
        } else {
            log.info("傳送者爸爸已經收到確認,correlationData={} ,ack={}, cause={}", correlationData.getId(), ack, cause);
        }
    }
}

實現介面 ConfirmCallback ,重寫其confirm()方法,方法內有三個引數correlationDataackcause

  • correlationData:物件內部只有一個 id 屬性,用來表示當前訊息的唯一性。
  • ack:訊息投遞到broker 的狀態,true表示成功。
  • cause:表示投遞失敗的原因。

但訊息被 broker 接收到只能表示已經到達 MQ伺服器,並不能保證訊息一定會被投遞到目標 queue 裡。所以接下來需要用到 returnCallback

2、 ReturnCallback 退回模式

如果訊息未能投遞到目標 queue 裡將觸發回撥 returnCallback ,一旦向 queue 投遞訊息未成功,這裡一般會記錄下當前訊息的詳細投遞資料,方便後續做重發或者補償等操作。

@Slf4j
@Component
public class ReturnCallbackService implements RabbitTemplate.ReturnCallback {

    @Override
    public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {
        log.info("returnedMessage ===> replyCode={} ,replyText={} ,exchange={} ,routingKey={}", replyCode, replyText, exchange, routingKey);
    }
}

實現介面ReturnCallback,重寫 returnedMessage() 方法,方法有五個引數message(訊息體)、replyCode(響應code)、replyText(響應內容)、exchange(交換機)、routingKey(佇列)。

下邊是具體的訊息傳送,在rabbitTemplate中設定 ConfirmReturn 回撥,我們透過setDeliveryMode()對訊息做持久化處理,為了後續測試建立一個 CorrelationData物件,新增一個id10000000000

@Autowired
    private RabbitTemplate rabbitTemplate;

    @Autowired
    private ConfirmCallbackService confirmCallbackService;

    @Autowired
    private ReturnCallbackService returnCallbackService;

    public void sendMessage(String exchange, String routingKey, Object msg) {

        /**
         * 確保訊息傳送失敗後可以重新返回到佇列中
         * 注意:yml需要配置 publisher-returns: true
         */
        rabbitTemplate.setMandatory(true);

        /**
         * 消費者確認收到訊息後,手動ack回執回撥處理
         */
        rabbitTemplate.setConfirmCallback(confirmCallbackService);

        /**
         * 訊息投遞到佇列失敗回撥處理
         */
        rabbitTemplate.setReturnCallback(returnCallbackService);

        /**
         * 傳送訊息
         */
        rabbitTemplate.convertAndSend(exchange, routingKey, msg,
                message -> {
                    message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
                    return message;
                },
                new CorrelationData(UUID.randomUUID().toString()));
    }

三、訊息接收確認

訊息接收確認要比訊息傳送確認簡單一點,因為只有一個訊息回執(ack)的過程。使用@RabbitHandler註解標註的方法要增加 channel(通道)、message 兩個引數。

@Slf4j
@Component
@RabbitListener(queues = "confirm_test_queue")
public class ReceiverMessage1 {

    @RabbitHandler
    public void processHandler(String msg, Channel channel, Message message) throws IOException {

        try {
            log.info("小富收到訊息:{}", msg);

            //TODO 具體業務

            channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);

        }  catch (Exception e) {

            if (message.getMessageProperties().getRedelivered()) {

                log.error("訊息已重複處理失敗,拒絕再次接收...");

                channel.basicReject(message.getMessageProperties().getDeliveryTag(), false); // 拒絕訊息
            } else {

                log.error("訊息即將再次返回佇列處理...");

                channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true); 
            }
        }
    }
}

消費訊息有三種回執方法,我們來分析一下每種方法的含義。

1、basicAck

basicAck:表示成功確認,使用此回執方法後,訊息會被rabbitmq broker 刪除。

void basicAck(long deliveryTag, boolean multiple) 

deliveryTag:表示訊息投遞序號,每次消費訊息或者訊息重新投遞後,deliveryTag都會增加。手動訊息確認模式下,我們可以對指定deliveryTag的訊息進行acknackreject等操作。

multiple:是否批次確認,值為 true 則會一次性 ack所有小於當前訊息 deliveryTag 的訊息。

舉個例子: 假設我先傳送三條訊息deliveryTag分別是5、6、7,可它們都沒有被確認,當我發第四條訊息此時deliveryTag為8,multiple設定為 true,會將5、6、7、8的訊息全部進行確認。

2、basicNack

basicNack :表示失敗確認,一般在消費訊息業務異常時用到此方法,可以將訊息重新投遞入佇列。

void basicNack(long deliveryTag, boolean multiple, boolean requeue)

deliveryTag:表示訊息投遞序號。

multiple:是否批次確認。

requeue:值為 true 訊息將重新入佇列。

3、basicReject

basicReject:拒絕訊息,與basicNack區別在於不能進行批次操作,其他用法很相似。

void basicReject(long deliveryTag, boolean requeue)

deliveryTag:表示訊息投遞序號。

requeue:值為 true 訊息將重新入佇列。

四、測試

傳送訊息測試一下訊息確認機制是否生效,從執行結果上看傳送者發訊息後成功回撥,消費端成功的消費了訊息。
在這裡插入圖片描述
用抓包工具Wireshark 觀察一下rabbitmq amqp協議互動的變化,也多了 ack 的過程。
在這裡插入圖片描述

五、踩坑日誌

1、不訊息確認

這是一個非常沒技術含量的坑,但卻是非常容易犯錯的地方。

開啟訊息確認機制,消費訊息別忘了channel.basicAck,否則訊息會一直存在,導致重複消費。
在這裡插入圖片描述

2、訊息無限投遞

在我最開始接觸訊息確認機制的時候,消費端程式碼就像下邊這樣寫的,思路很簡單:處理完業務邏輯後確認訊息, int a = 1 / 0 發生異常後將訊息重新投入佇列。

@RabbitHandler
    public void processHandler(String msg, Channel channel, Message message) throws IOException {

        try {
            log.info("消費者 2 號收到:{}", msg);

            int a = 1 / 0;

            channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);

        } catch (Exception e) {

            channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
        }
    }

但是有個問題是,業務程式碼一旦出現 bug 99.9%的情況是不會自動修復,一條訊息會被無限投遞進佇列,消費端無限執行,導致了死迴圈。

在這裡插入圖片描述

本地的CPU被瞬間打滿了,大家可以想象一下當時在生產環境導致服務當機,我是有多慌。

在這裡插入圖片描述
而且rabbitmq management 只有一條未被確認的訊息。

在這裡插入圖片描述

經過測試分析發現,當訊息重新投遞到訊息佇列時,這條訊息不會回到佇列尾部,仍是在佇列頭部。

消費者會立刻消費這條訊息,業務處理再丟擲異常,訊息再重新入隊,如此反覆進行。導致訊息佇列處理出現阻塞,導致正常訊息也無法執行。

而我們當時的解決方案是,先將訊息進行應答,此時訊息佇列會刪除該條訊息,同時我們再次傳送該訊息到訊息佇列,異常訊息就放在了訊息佇列尾部,這樣既保證訊息不會丟失,又保證了正常業務的進行。

channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
// 重新傳送訊息到隊尾
channel.basicPublish(message.getMessageProperties().getReceivedExchange(),
                    message.getMessageProperties().getReceivedRoutingKey(), MessageProperties.PERSISTENT_TEXT_PLAIN,
                    JSON.toJSONBytes(msg));

但這種方法並沒有解決根本問題,錯誤訊息還是會時不時報錯,後面最佳化設定了訊息重試次數,達到了重試上限以後,手動確認,佇列刪除此訊息,並將訊息持久化入MySQL並推送報警,進行人工處理和定時任務做補償。

3、重複消費

如何保證 MQ 的消費是冪等性,這個需要根據具體業務而定,可以藉助MySQL、或者redis 將訊息持久化,透過再訊息中的唯一性屬性校驗。

demoGitHub 地址 github.com/chengxy-nds/Springboot-...


原創不易,燃燒秀髮輸出內容,如果有一丟丟收穫,點個贊鼓勵一下吧!

整理了幾百本各類技術電子書,送給小夥伴們。關注公號回覆【666】自行領取。和一些小夥伴們建了一個技術交流群,一起探討技術、分享技術資料,旨在共同學習進步,如果感興趣就掃碼加入我們吧!

本作品採用《CC 協議》,轉載必須註明作者和本文連結

相關文章