前言
3.9、延遲佇列 - 重要
3.9.1、延遲佇列概念
- 這個玩意兒要表達的意思其實已經見過了,就是死信佇列中說的TTL訊息過期,但是文字表達得換一下
- 所謂的延遲佇列:就是用來存放需要在指定時間內被處理的元素的佇列,其內部是有序的
- 使用場景:
- 1、支付時,訂單在30分鐘以內未支付則自動取消支付
- 2、退款,使用者發起退款,在3天以後商家還未處理,那官方便介入其中進行處理
- ..........
- 玩延遲佇列需要具備的條件:
- 1、具備死信佇列知識
- 2、具備TTL知識
- 然後將這二者結合,加一些東西,上好的烹飪就做好了
- 實現如下的邏輯
- P:生產者
- X:正常交換機
- Y:死信交換機
- QA、QB:正常佇列
- QD:死信佇列
- XA、XB:正常交換機、正常佇列的routing key
- YD:死信交換機、死信佇列的routing key
3.9.2、整合SpringBoot
3.9.2.1、依賴
<dependencies>
<!--rabbitmq的依賴-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.amqp</groupId>
<artifactId>spring-rabbit-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
3.9.2.2、yml檔案配置
# RabbitMQ的配置
spring:
rabbitmq:
host: 自己伺服器ip
port: 5672
username: admin
password: admin
# 要是有Vhost也可以進行配置
3.9.2.4、RabbitMQ配置
package cn.zixieqing.config;
import org.springframework.amqp.core.*;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.HashMap;
@Configuration
public class MqConfig {
/**
* 正常交換機名稱
*/
private static final String TTL_NORMAL_EXCHANGE = "X";
/**
* 死信交換機名稱
*/
private static final String TTL_DEAD_LETTER_EXCHANGE = "Y";
/**
* 正常佇列名稱
*/
private static final String TTL_NORMAL_QUEUE_A = "QA";
private static final String TTL_NORMAL_QUEUE_B = "QB";
/**
* 死信佇列名稱
*/
private static final String TTL_DEAD_LETTER_QUEUE_D = "QD";
/**
* 正常交換機 和 正常佇列A的routing key
*/
private static final String TTL_NORMAL_EXCHANGE_BIND_QUEUE_A = "XA";
/**
* 正常交換機 和 正常佇列B的routing key
*/
private static final String TTL_NORMAL_EXCHANGE_BIND_QUEUE_B = "XB";
/**
* 正常佇列 和 死信交換機 及 死信交換機 與 死信佇列的routing key
*/
private static final String TTL_NORMAL_QUEUE_AND_DEAD_LETTER_EXCHANGE_AND_DEAD_LETTER_QUEUE_BIND = "YD";
/**
* 宣告正常交換機
*/
@Bean("xExchange")
public DirectExchange xExchange() {
// 直接建立是什麼型別的交換機 加上 交換機名字就可以了
return new DirectExchange(TTL_NORMAL_EXCHANGE);
}
/**
* 宣告死信交換機
*/
@Bean("yExchange")
public DirectExchange yExchange() {
return new DirectExchange(TTL_DEAD_LETTER_EXCHANGE);
}
/**
* 宣告正常佇列QA 並 繫結死信互動機Y
*/
@Bean("queueA")
public Queue queueA() {
// initialCapacity 這裡的map大小值:(存的元素個數 / 負載因子0.75) + 1
HashMap<String, Object> params = new HashMap<>(5);
params.put("x-dead-letter-exchange", TTL_DEAD_LETTER_EXCHANGE);
params.put("x-dead-letter-routing-key", TTL_NORMAL_QUEUE_AND_DEAD_LETTER_EXCHANGE_AND_DEAD_LETTER_QUEUE_BIND);
params.put("x-message-ttl", 10 * 1000);
// 構建佇列 並 傳入相應的引數
return QueueBuilder.durable(TTL_NORMAL_QUEUE_A)
.withArguments(params)
.build();
}
/**
* X正常交換機 和 QA正常佇列繫結
*/
@Bean
public Binding xChangeBindingQueueA(@Qualifier("queueA") Queue queueA,
@Qualifier("xExchange") DirectExchange xExchange) {
return BindingBuilder.bind(queueA)
.to(xExchange)
.with(TTL_NORMAL_EXCHANGE_BIND_QUEUE_A);
}
/**
* 宣告正常佇列QB 並 繫結死信交換機Y
*/
@Bean("queueB")
public Queue queueB() {
/*
initialCapacity map初始值:(存的元素個數 / 負載因子0.75) + 1
*/
HashMap<String, Object> params = new HashMap<>(5);
params.put("x-dead-letter-exchange", TTL_DEAD_LETTER_EXCHANGE);
params.put("x-dead-letter-routing-key", TTL_NORMAL_QUEUE_AND_DEAD_LETTER_EXCHANGE_AND_DEAD_LETTER_QUEUE_BIND);
params.put("x-message-ttl", 40 * 1000);
// 構建佇列 並 傳入相應的引數
return QueueBuilder.durable(TTL_NORMAL_QUEUE_B)
.withArguments(params)
.build();
}
/**
* X正常交換機 和 QB正常佇列繫結
*/
@Bean
public Binding xChangeBindingQueueB(@Qualifier("queueB") Queue queueB,
@Qualifier("xExchange") DirectExchange xExchange) {
return BindingBuilder.bind(queueB)
.to(xExchange)
.with(TTL_NORMAL_EXCHANGE_BIND_QUEUE_B);
}
/**
* 宣告死信佇列D
*/
@Bean("queueD")
public Queue queueD() {
return new Queue(TTL_DEAD_LETTER_QUEUE_D);
}
/**
* 死信交換機 和 私信佇列進行繫結
*/
@Bean
public Binding yExchangeBindingQueueD(@Qualifier("queueD") Queue queueD,
@Qualifier("yExchange") DirectExchange yExchange) {
return BindingBuilder.bind(queueD)
.to(yExchange)
.with(TTL_NORMAL_QUEUE_AND_DEAD_LETTER_EXCHANGE_AND_DEAD_LETTER_QUEUE_BIND);
}
}
3.9.2.5、生產者
新加一個依賴
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.75</version>
</dependency>
生產者虛擬碼
package cn.zixieqing.controller;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.Date;
@RestController
@RequestMapping("sendMsg")
public class MqProducerController {
/**
* 這個玩意兒是Spring提供的
*/
@Autowired
private RabbitTemplate rabbitTemplate;
@GetMapping("{message}")
public void sendMsg(@PathVariable String message) {
System.out.println( new Date() + ":接收到了訊息===>" + message);
// 傳送訊息
rabbitTemplate.convertAndSend("X","XA","這條訊息是來著TTL為10s的===>" + message);
rabbitTemplate.convertAndSend("X","XB","這條訊息是來著TTL為40s的===>" + message);
}
}
3.9.2.6、消費者
package cn.zixieqing.consumer;
import com.rabbitmq.client.Channel;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
import java.nio.charset.StandardCharsets;
import java.util.Date;
@Component
public class DeadLetterQueueConsumer {
@RabbitListener(queues = "QD")
public void receiveMsg(Message message,Channel Channel) {
System.out.println( new Date() + "接收到了訊息===>" +
new String( message.getBody(), StandardCharsets.UTF_8));
}
}
- 但是:這種延遲佇列有缺點
- 當有很多請求,而延遲時間也都不一樣時,那麼就要寫N多的這種程式碼了
3.9.3、RabbitMQ外掛實現延遲佇列
- 外掛下載地址:https://www.rabbitmq.com/community-plugins.html
- github地址:https://github.com/rabbitmq/rabbitmq-delayed-message-exchange
- 進入如下的目錄中
cd /usr/lib/rabbitmq/lib/rabbitmq_server-3.9.15/plugins # 版本號改成自己的
- 把下載的外掛上傳進去
- 啟動外掛
rabbitmq-plugins enable rabbitmq_delayed_message_exchange
- 重啟rabbitMQ
systemctl restart rabbitmq-server
- 然後去web管理介面看exchange,就發現交換機型別多了一個
3.9.3.1、編寫配置
- 使用這種外掛的方式,那麼延遲設定就是在exchange交換機這一方進行設定,和以前在queue佇列中進行延遲設定不一樣
原來的延遲佇列設定
使外掛之後的延遲設定
- 使用外掛,實現下面的邏輯圖
package cn.zixieqing.config;
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.CustomExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.HashMap;
@Configuration
public class DelayedExchanegConfig {
/**
* 交換機名字
*/
private static final String EXCHANGE_NAME = "delayed.exchange";
/**
* 佇列名字
*/
private static final String QUEUE_NAME = "delayed.queue";
/**
* 繫結鍵值
*/
private static final String EXCHANGE_BINDING_QUEUE_ROUTING_KEY = "delayed.routingkey";
/**
* 宣告交換機 - 目前這種交換機是沒有的,這是外掛的,因此:選擇自定義交換機
*/
@Bean
public CustomExchange delayedExchange() {
HashMap<String, Object> params = new HashMap<>(3);
// 延遲型別
params.put("x-delayed-type", "direct");
/*
引數1、交換機名字
引數2、交換機型別 - 外掛的那個型別
引數3、交換機是否持久化
引數4、交換機是否自動刪除
引數5、交換機的其他配置
*/
return new CustomExchange(EXCHANGE_NAME, "x-delayed-message", true, false, params);
}
/**
* 宣告佇列
*/
@Bean
public Queue delayedQueue() {
return new Queue(QUEUE_NAME);
}
/**
* 交換機 和 佇列 進行繫結
*/
public Binding exchangeBindingQueue(@Qualifier("delayedExchange") CustomExchange delayedExchange,
@Qualifier("delayedQueue") Queue delayedQueue) {
return BindingBuilder
.bind(delayedQueue)
.to(delayedExchange)
.with(EXCHANGE_BINDING_QUEUE_ROUTING_KEY)
// noargs()就是構建的意思 和 build()一樣
.noargs();
}
}
3.9.3.2、生產者
package cn.zixieqing.controller;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.Date;
@RestController
@RequestMapping("sendMsg")
public class DelatedQueueController {
@Autowired
private RabbitTemplate rabbitTemplate;
@GetMapping("/{message}/{ttl}")
public void getMesg(@PathVariable String message, @PathVariable int ttl) {
System.out.println(new Date() + "接收到了訊息===>" + message + "===>失效時間為:" + ttl);
// 傳送訊息
rabbitTemplate.convertAndSend("delayed.exchange", "delayed.routingkey", data->{
// 設定失效時間
data.getMessageProperties().setDelay(10 * 1000);
return data;
});
}
}
3.9.3.3、消費者
package cn.zixieqing.consumer;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
import java.nio.charset.StandardCharsets;
import java.util.Date;
@Component
public class DelayedQueueConsumer {
@RabbitListener(queues = "delayed.queue")
public void receiveMessage(Message message) {
System.out.println("消費者正在消費訊息......");
String msg = new String(message.getBody(), StandardCharsets.UTF_8);
System.out.println(new Date() + "消費了訊息===>" + message);
}
}
- 傳送兩次訊息,然後把傳的TTL弄成不一樣的,那麼:TTL值小的訊息就會先被消費,然後到了指定時間之後,TTL長的訊息再消費
3.10、釋出確認 - 續
3.10.1、ConfirmCallback() 和 ReturnCallback()
- 正常的流程應該是下面的樣子
- 但是:如果交換機出問題了呢,總之就是交換機沒有接收到生產者釋出的訊息( 如:發訊息時,交換機名字搞錯了 ),那訊息就直接丟了嗎?
- 同理:要是佇列出問題了呢,總之也就是交換機沒有成功地把訊息推到佇列中( 如:routing key搞錯了 ),咋辦?
- 而要解決這種問題,就需要使用標題中使用的兩個回撥,從而:讓架構模式變成如下的樣子
ConfirmCallback() 和 ReturnCallback()的配置
- 在yml檔案中新增如下內容
spring:
rabbitmq:
# 釋出確認型別
publisher-confirm-type: correlated
# 佇列未收到訊息時,觸發returnCallback回撥
publisher-returns: true
- 編寫ConfirmCallback 和 returnCallback回撥介面( 虛擬碼 ) - 注意點:這兩個介面是RabbitTemplate的內部類( 故而:就有大文章 )
@Component
public class PublisherConfirmAndReturnConfig implements RabbitTemplate.ConfirmCallback ,RabbitTemplate.ReturnCallback {
@Autowired
private RabbitTemplate rabbitTemplate;
/**
初始化方法
目的:因為ConfirmCallback 和 ReturnCallback這兩個介面是RabbitTemplate的內部類
因此:想要讓當前編寫的PublisherConfirmAndReturnConfig能夠訪問到這兩個介面
那麼:就需要把當前類PublisherConfirmAndReturnConfig的confirmCallback 和 returnCallback注入到RabbitTemplate中去( init的作用 )
*/
@PostConstruct
public void init(){
rabbitTemplate.setConfirmCallback(this);
rabbitTemplate.setReturnCallback(this);
}
/**
引數1、傳送訊息的ID - correlationData.getID() 和 訊息的相關資訊
引數2、是否成功傳送訊息給exchange true成功;false失敗
引數3、失敗原因
*/
@Override
public void confirm(CorrelationData correlationData, boolean ack, String cause) {
if(ack){
System.out.println("訊息已經送達到Exchange");
}else{
System.out.println("訊息沒有送達到Exchange");
}
}
/**
引數1、訊息 new String(message.getBody())
引數2、訊息退回的狀態碼
引數3、訊息退回的原因
引數4、交換機名字
引數5、路由鍵
*/
@Override
public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {
System.out.println("訊息沒有送達到Queue");
}
}
- 生產者呼叫的方法是:rabbitTemplate.convertAndSend(String exchange, String routingKey, Object message, CorrelationData correlationData)
- 多了一個CorrelationData 引數,這個引數攜帶的就是訊息相關資訊
3.11、備份交換機
- 這個玩意兒也是為了解決前面釋出確認中佇列出問題的方案
- 注意:這種方式優先順序比前面的 ReturnCallback回退策略要高( 演示:跳過 - 可以採用將這二者都配置好,然後進行測試,結果是備份交換機的方式會優先執行,而前面的回退策略的方式並不會執行 )
- 採用備份交換機時的架構圖
上圖架構的虛擬碼配置編寫
package cn.zixieqing.config;
import org.springframework.amqp.core.*;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class AlternateExchangeConfig {
/**
* 正常交換機名字
*/
private static final String NORMAL_EXCHANGE_NAME = "normal_exchange";
/**
* 正常佇列
*/
private static final String NORMAL_QUEUE_NAME = "normal_queue";
/**
* 備份交換機名字
*/
private static final String ALTERNATE_EXCHANGE_NAME = "alternate_exchange";
/**
* 備份佇列名字
*/
private static final String ALTERNATE_QUEUE_NAME = "alternate_queue";
/**
* 用於警告的佇列名字
*/
private static final String WARNING_QUEUE_NAME = "warning_queue";
/**
* 宣告正常交換機 但是:需要做一件事情 - 訊息沒投遞到正常佇列時,需要讓其走備份交換機
*/
@Bean
public DirectExchange confirmExchange() {
return ExchangeBuilder
.directExchange(NORMAL_EXCHANGE_NAME)
.durable(true)
// 繫結備份交換機
.withArgument("alternate-exchange", ALTERNATE_EXCHANGE_NAME)
.build();
}
/**
* 宣告確認佇列
*/
@Bean
public Queue confirmQueue() {
return new Queue(NORMAL_QUEUE_NAME);
}
/**
* 確認交換機( 正常交換機 ) 和 確認佇列進行繫結
*/
@Bean
public Binding confirmExchangeBindingConfirmQueue(@Qualifier("confirmExchange") DirectExchange confirmExchange,
@Qualifier("confirmQueue") Queue confirmQueue) {
return BindingBuilder
.bind(confirmQueue)
.to(confirmExchange)
.with("routingkey");
}
/**
* 宣告備份交換機
*/
@Bean
public FanoutExchange alternateExchange() {
return new FanoutExchange(ALTERNATE_EXCHANGE_NAME);
}
/**
* 宣告備份佇列
*/
@Bean
public Queue alternateQueue() {
return QueueBuilder
.durable(ALTERNATE_QUEUE_NAME)
.build();
}
/**
* 宣告警告佇列
*/
@Bean
public Queue warningQueue() {
return new Queue(WARNING_QUEUE_NAME);
}
/**
* 備份交換機 和 備份佇列進行繫結
*/
@Bean
public Binding alternateExchangeBindingAlternateQueue(@Qualifier("alternateQueue") Queue alternateQueue,
@Qualifier("alternateExchange") FanoutExchange alternateExchange) {
return BindingBuilder
.bind(alternateQueue)
.to(alternateExchange);
}
/**
* 備份交換機 和 警告佇列進行繫結
*/
@Bean
public Binding alternateExchangeBindingWarningQueue(@Qualifier("warningQueue") Queue warningQueue,
@Qualifier("alternateExchange") FanoutExchange alternateExchange) {
return BindingBuilder
.bind(warningQueue)
.to(alternateExchange);
}
}
- 後續的操作就是差不多的,生產者傳送訊息,消費者消費訊息,然後裡面再做一些業務的細節處理就可以了
3.12、優先順序佇列
- 這就是為了讓MQ佇列中的某個 / 某些訊息能夠優先被消費
- 使用場景:搞內幕,讓某個人 / 某些人一定能夠搶到什麼商品
-
想要實現優先順序佇列,需要滿足如下條件:
-
1、佇列本身設定優先順序( 在宣告佇列時進行引數配置 )
-
/** * 基礎型配置 */ Map<String, Object> params = new HashMap(); params.put("x-max-priority", 10); // 預設區間:(0, 255) 但是若用這個區間,則會浪費CPU和記憶體消耗,因此:改為(0, 10)即可 channel.queueDeclare("hello", true, false, false, params); /** * SpringBoot中的配置 */ @Bean public Queue alternateQueue() { // 空間大小: ( map儲存的元素個數 / 0.75 ) + 1 HashMap<String, Object> params = new HashMap<>(3); params.put("x-max-priority", 10); return QueueBuilder .durable(ALTERNATE_QUEUE_NAME).withArguments(params) .build(); }
-
-
2、讓訊息有優先順序
-
/** * 基礎型配置 - 生產者呼叫basicPublisher()時配置的訊息properties */ AMQP.BasicProperties properties = new AMQP.BasicProperties() .builder() .priority(5) .build(); /** * SpringBoot中的配置 */ // 傳送訊息 rabbitTemplate.convertAndSend("normal.exchange", "normal.routingkey", data->{ // 訊息設定優先順序 - 注意:這個數值不能比前面佇列設定的那個優先順序數值大,即:這裡的訊息優先順序範圍就是前面佇列中設定的(0, 10) data.getMessageProperties().setPriority(5); return data; });
-
-
-
注意點:設定了優先順序之後,需要做到如下條件:
- 需要讓訊息全部都發到佇列之後,才可以進行消費,原因:訊息進入了佇列,是會重新根據優先順序大小進行排隊,從而讓優先順序數值越大越在前面
3.13、惰性佇列
- 這玩意兒指的就是讓訊息存放在磁碟中
- 正常情況下是如下的樣子
- 但是:如果此時傳送的訊息是成千上萬條,並且消費者出故障了( 下線、當機、維護從而關閉 ),那麼這些成千上萬的訊息就會堆積在MQ中,怎麼辦?就需要像下面這麼搞
設定惰性佇列的配置
/**
* 基礎型配置
*/
Map<String, Object> params = new HashMap();
params.put("x-queue-mode", "lazy");
channel.queueDeclare("hello", true, false, false, params);
/**
* SpringBoot中的配置
*/
@Bean
public Queue alternateQueue() {
// 空間大小: ( map儲存的元素個數 / 0.75 ) + 1
HashMap<String, Object> params = new HashMap<>(3);
params.put("x-queue-mode", "lazy");
return QueueBuilder
.durable(ALQUEUE_NAME).withArguments(params)
.build();
}
- 經過如上配置之後,那麼記憶體中記錄的就是指向磁碟的引用地址,而真實的資料是在磁碟中,下一次消費者恢復之後,就可以從磁碟中讀取出來,然後再發給消費者( 缺點:得先讀取,然後傳送,這效能很慢,但是:處理場景就是消費者掛彩了,不再消費訊息時儲存資料的情景 )