消息队列

消息队列的作用

好处：

异步、解耦、削峰
消息队列（Message Queue，简称MQ）的核心作用可以用一句话概括：
- 作为异步通信的“中间人”，实现系统之间的解耦、流量削峰和异步处理。

缺点：

系统复杂性急剧上升（最大的痛点）：消息丢失风险、消息重复消费、消息顺序性难题
不能立即得到调用结果，时效性差，不确定下游业务执行是否成功：数据一致性问题（分布式事务难题）
系统可用性降低（引入了新的单点故障）：业务安全依赖于消息队列的可靠性
排查和定位问题变得困难

什么时候“不该”用MQ？

业务量很小（QPS < 100）：直接用HTTP同步调用或数据库事务更简单、更可控。
对一致性要求极度严苛（如银行核心账务）：强一致性场景不适合异步消息，除非配合复杂的补偿机制。
团队运维能力不足：MQ集群的监控、告警、故障恢复需要专业能力，否则引入就是给自己“埋雷”。

总结：MQ是“以复杂度换扩展性”的典型工具。在决定引入之前，务必评估团队是否有能力应对上述“副作用”。

常见的消息队列产品

产品	特点	典型场景
RabbitMQ	稳定、功能完善、易用	企业内部系统、任务分发
Kafka	高吞吐、持久化、分布式	日志收集、大数据流处理
RocketMQ	阿里出品、低延迟、金融级可靠	订单、交易等核心链路
Redis Streams	轻量级、依赖Redis	轻量级消息、实时性要求高

RabbitMQ

安装RabbitMQ

RabbitMQ官网下载并安装：Installing RabbitMQ | RabbitMQ

如果下载的是zip无需安装的，得安装下Erlang/OTP环境：Downloads - Erlang/OTP

Erlang/OTP下载的zip无需安装的需要配置环境变量
注意RabbitMQ和Erlang/OTP的版本要适配：我的是 RabbitMQ 4.3.3 + Erlang 27.0 或 26.2.x

启动后端口：

amqp,5672 → AMQP 协议端口（默认 5672）
management,15672 → 管理插件 Web 端口（默认 15672）
clustering,25672 → 集群通信端口（默认 25672）

启动和关闭RabbitMQ

启动 RabbitMQ：AMQP 协议端口（默认 5672）

.\rabbitmq-server.bat

启用管理插件（Web 可视化界面（默认 15672））,启用后，访问：http://localhost:15672

用户名：guest
密码：guest

.\rabbitmq-plugins.bat enable rabbitmq_management

关闭整个 RabbitMQ 服务，包括RabbitMQ和Web 可视化界面

.\rabbitmqctl.bat stop

RabbitMQ整体架构及核心概念

virtual-host：虚拟主机，起到数据隔离的作用
publisher：消息发送者
consumer：消息的消费者
queue：队列，存储消息
exchange：交换机，负责路由消息

RabbitMQ数据隔离

数据隔离操作

在RabbitMQ的控制台完成下列操作：
- 创建用户：新建一个用户testmq
- 创建virtual-host：为testmq用户创建一个virtual host
- 测试：不同virtual host之间的数据隔离现象

这样就可以实现：

不同的项目使用同一个RabbitMQ下不同的virtual-host，实现数据隔离。

快速入门

Spring AMQP是基于AMQP协议定义的一套API规范，提供了模板来发送和接收消息。包含两部分，其中spring-amqp是基础抽象，spring-rabbit是底层的默认实现。

在父工程中引入spring-amqp依赖，这样publisher和consumer服务都可以使用：

<！--AMQP依赖，包含RabbitMQ-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactid>spring-boot-starter-amqp</artifactid>
</dependency>

配置RabbitMQ服务端信息

在每个微服务中引I入MQ服务端信息，这样微服务才能连接到RabbitMQ

spring:
 rabbitmq:
  host: 192.168.150.101 # 主机名
  port: 5672 # 端口
  virtual-host: /testmq # virtual-host虚拟主机名字，一般都是带/开头
  username: testmq # 用户名
  password: 123 # 密码

发送消息
Spring AMQP提供了RabbitTemplate工具类，方便我们发送消息。发送消息代码如下：

@Autowired
private RabbitTemplate rabbitTemplate;

@Test
public void testSimpleQueue(){
    // 队列名称
    String queueName = "simple.queue";
    // 消息
    String message ="hello,spring amqp!";
    // 发送消息
    rabbitTemplate.convertAndSend (queueName,message);
}

接收消息
Spring AMQP提供声明式的消息监听，我们只需要通过注解在方法上声明要监听的队列名称，将来Spring AMQP就会把消息传递给当前方法：

@Slf4j
@Component
public class SpringRabbitListener{
    @RabbitListener(queues = "simple.queue")
    public void listenSimpleQueueMessage(String msg) throws InterruptedException {
        log.info("spring消费者接收到消息:["+msg+"]");
    }
}

总结：Spring AMQP如何收发消息?

引入spring-boot-starter-amqp依赖。
配置rabbitmq服务端信息。
利用RabbitTemplate发送消息。
利用@RabbitListener注解声明要监听的队列，监听消息。

交换机和队列指南

总览

交换机类型：

RabbitMQ Tutorials | RabbitMQ

一个知识点：队列里面的信息只能被消费一次，如果有2个接收放从同一个队列消费消息，那么一个消息只能被其中一个消费

直接模式

一个发送方：发送到Queue

一个接收方：从Queue获取

Work Queues模式

一个发送方：发送到Queue

多个接收方：从Queue获取

类似集群的架构监控同一个Queue：例如多个订单模块，监控付款结果的Queue。即是多个一模一样的微服务，代码是一样的，所以监听的也是一样的Queue

默认情况下，RabbitMQ的会将消息依次轮询投递给绑定在队列上的每一个消费者。但这并没有考虑到消费者是否已经处理完消息，可能出现消息堆积。
因此我们需要修改application.yml，设置preFetch值为1，确保同一时刻最多投递给消费者1条消息：

spring:
 rabbitmq:
  listener:
   simple:
    prefetch: 1 # 每次只能获取一条消息，处理完成才能获取下一个消息

Work模型的使用：

多个消费者绑定到一个队列，可以加快消息处理速度。
同一条消息只会被一个消费者处理。
通过设置prefetch来控制消费者预取的消息数量，处理完一条再处理下一条，实现能者多劳。

交换机模式

交换机的作用主要是接收发送者发送的消息，并将消息路由到与其绑定的队列。

常见交换机的类型有以下三种：

Fanout：广播
- Fanout Exchange会将接收到的消息路由到每一个跟其绑定的queue，所以也叫广播模式
- 可以实现一个消息被多个接收放消费，因为是不同的队列
- 一个发送方：发送到交换机
  
  多个接收方：从交换机绑定的Queue获取
- 代码
```
@Test
public void testFanoutQueue() {
    //1.交换机名
    String exchangeName ="hmall.fanout";
    // 2.消息
    String message ="hello,everyone!";
    // 3.发送消息
    rabbitTemplate.convertAndSend(exchangeName, null, message);
}
```
Direct：定向
- Direct Exchange会将接收到的消息根据规则路由到指定的Queue，因此称为定向路由。
  - 每一个Queue都与Exchange设置一个BindingKey。【如果所有的Queue和Exchange的BindingKey都设置一样的，就成了Fanout Exchange】
  - 发布者发送消息时，指定消息的RoutingKey
  - Exchange将消息路由到BindingKey与消息RoutingKey一致的队列
- 描述下Direct交换机与Fanout交换机的差异？
  - Fanout交换机将消息路由给每一个与之绑定的队列
  - Direct交换机根据RoutingKey判断路由给哪个队列
  - 如果多个队列具有相同RoutingKey，则与Fanout功能类似
Topic：话题
- Topic Exchange也是基于RoutingKey做消息路由，但是RoutingKey通常是多个单词的组合，并且以.分割。
- Queue与Exchange指定BindingKey时可以使用通配符:
  - #：代指0个或多个单词
  - *：代指一个单词
- Topic Exchange采用RoutingKey的方式但是利用了通配符的规则

代码生成队列和交换机

SpringAMQP提供了几个类，用来声明队列、交换机及其绑定关系：

Queue：用于声明队列，可以用工厂类QueueBuilder构建
Exchange：用于声明交换机，可以用工厂类ExchangeBuilder构建
Binding：用于声明队列和交换机的绑定关系，可以用工厂类BindingBuilder构建

SpringAMQP还提供了基于@RabbitListener注解来声明队列和交换机的方式：

@RabbitListener(bindings =@QueueBinding(value =@Queue(name ="direct.queue1"),exchange = 		      @Exchange(name="itcast.direct", type = ExchangeTypes.DIRECT),
key ={"red", "blu"}))
public void listenDirectQueuel(String msg){
	System.out.println("消费者1接收到Direct消息：["+msg+"]"）；
}

消息转换器

发送的不是String，而是一个java对象时：

Spring对消息对象的处理是由org.springframework.amqp.support.converter.MessageConverter来处理的。而默认实现是SimpleMessageConverter，基于JDK的ObjectOutputStream完成序列化。
存在下列问题：

JDK的序列化有安全风险
JDK序列化的消息太大
JDK序列化的消息可读性差

建议采用JSON序列化代替默认的JDK序列化，要做两件事情：
在publisher和consumer中都要引入jackson依赖：

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
</dependency>

在publisher和consumer中都要配置MessageConverter:

@Bean
public MessageConverter messageConverter(){
	return newJackson2JsonMessageConverter();
}

发送：

@Test
publicvoid testSendobject(){
    //1.准备消息
    Map<String, Object> msg = new HashMap<>(2);
    msg.put("name", "Jack");
    msg.put("age"，21)；
    //2.发送消息
    rabbitTemplate.convertAndSend("object.queue",msg);
}

接收：

@RabbitListener(queues ="object.queue")
public void listenObjectQueue(Map<String,Object>msg){
	log.info（"消费者监听到 object.queue的消息：【{}】"，msg）
}

RabbitMQ高级

发送者的可靠性
- 网不好，没发出去等情况
MQ的可靠性
- MQ自己把数据搞丢了，或者宕机了
消费者的可靠性
- 消费者宕机了
- 消费者取了数据，但是没消费就宕机了
延迟消息

发送者的可靠性

发送者重连

发送者重连：有的时候由于网络波动，可能会出现发送者连接MQ失败的情况。通过配置我们可以开启连接失败后的重连机制：

spring:
 rabbitmq:
  connection-timeout: 1s #设置MQ的连接超时时间
  template:
   retry:
    enabled: true #开启超时重试机制
    initial-intervat: 1000ms #失败后的初始等待时间
    multiplier: 1 #失败后下次的等待时长倍数，下次等待时长 = initial-interval * multiplier
    max-attempts: 3 #最大重试次数

注意：

当网络不稳定的时候，利用重试机制可以有效提高消息发送的成功率。不过Spring AMQP提供的重试机制是阻塞式的重试，也就是说多次重试等待的过程中，当前线程是被阻塞的，会影响业务性能。
如果对于业务性能有要求，建议禁用重试机制。如果一定要使用，请合理配置等待时长和重试次数，当然也可以考虑使用异步线程来执行发送消息的代码。

当重试机制（Retry）耗尽后，如果消息仍然发送失败，对于业务系统来说，这次发送操作就是“失败的”。但是，“发送失败”并不等同于“消息丢失”。在工程实践中，针对重试耗尽的情况，有成熟的应对策略。下面我为你详细拆解：

本地重试 + 捕获异常（最简单）。如果重试机制是阻塞式的，也可以不重试，直接捕获异常

在调用发送消息的代码块里，用 try-catch 捕获重试耗尽后的异常，然后进行降级处理。

try {
    rabbitTemplate.convertAndSend("exchange", "key", message);
} catch (AmqpException e) {
    // 1. 记录错误日志（非常重要！）
    log.error("消息最终发送失败，内容：{}", message, e);
    // 2. 降级方案：存入本地缓存或数据库（作为“待补发”记录）
    saveToLocalQueue(message);
    // 3. 或者直接通知用户：系统繁忙，请稍后重试
}

失败回调（ReturnCallback / ConfirmCallback）—— RabbitMQ 特有
- RabbitMQ 提供了更精细的回调机制，当消息到达不了队列（路由失败）或写入磁盘失败时，会回调指定的方法，让你有机会将消息写入“死信队列”或“失败日志表”。
保存本地“补发任务表”（最可靠）。这是金融、订单类系统的标准做法：
1. 发送消息时，先在业务数据库中插入一条 message_task（状态为 待发送）。
2. 尝试发送消息。
3. 如果重试全部失败（抛出异常），不删除那条 待发送 记录。
4. 启动一个定时任务（Job），每隔 5 分钟扫描数据库里“待发送”且超过重试时间的记录，重新发送。
5. 直到发送成功，才将该记录标记为 已发送。

发送者确认

Spring AMQP提供了Publisher Confirm和Publisher Return两种确认机制。开启确机制认后，当发送者发送消息给MQ后，MQ会返回确认结果给发送者。返回的结果有以下几种情况：

消息投递到了MQ，但是路由失败。此时会通过Publisher Return返回路由异常原因，然后返回ACK，告知投递成功。
临时消息投递到了MQ，并且入队成功，返回ACK，告知投递成功。
持久消息投递到了MQ，并且入队完成持久化，返回ACK，告知投递成功。
其它情况都会返回NACK，告知投递失败。

SpringAMQP实现发送者确认

注意：不建议开启，影响效率

在publisher这个微服务的application.yml中添加配置：

spring:
 rabbitmq:
  publisher-confirm-type: correlated #开启publisher confirm机制，并设置confirm类型
  publisher-returns: true #开启publisher return机制
  
  
# 配置说明：
# 这里publisher-confirm-type有三种模式可选：
#  none：关闭confirm机制
#  simple：同步阻塞等待MQ的回执消息
#  correlated：MQ异步回调方式返回回执消息

每个RabbitTemplate只能配置一个ReturnCallback，因此需要在项目启动过程中配置：

@Slf4j
@AllArgsConstructor
@Configuration
public class MqConfig {
    private final RabbitTemplate rabbitTemplate;
    @PostConstruct
    public void init(){
        rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
            @override
            public voidreturnedMessage(ReturnedMessage returned) {
                log.error("触发returncallback,");
                log.debug("exchange:[}",returned.getExchange());
                log.debug("routingKey:[}",returned.getRoutingKey());
                log.debug("message:{}",returned.getMessage());
                log.debug("replyCode:{}",returned.getReplyCode());
                log.debug("replyText::{}",returned.getReplyText());
           }
       });
    }
}

发送消息，指定消息ID、消息ConfirmCallback

@Test
void testPublisherConfirm() throws InterruptedException {
    // 1.创建CorrelationData
    CorrelationData cd = new CorrelationData();
    // 2.给Future添加ConfirmCallback
    cd.getFuture().addCallback(newListenableFutureCallback<CorrelationData.Confirm>(){
        @override
        public void onFailure(Throwable ex){
            // 2.1.Future发生异常时的处理逻辑，基本不会触发
            log.error("handle message ack fail", ex);
        }
        @override
        public void onSuccess(CorrelationData.Confirm result) {
            // 2.2.Future接收到回执的处理逻辑，参数中的result就是回执内容
            if(result.isAck()) {//result.isAck()，boolean类型，true代表ack回执，false代表nack回执
            	log.debug("发送消息成功，收到ack!");
            } else {//result.getReason()，String类型，返回nack时的异常描述
            	log.error("发送消息失败，收到nack，reason:[}",result.getReason());
            }
        }
    });
    // 3.发送消息
    rabbitTemplate.convertAndSend("hmall.direct","red1","hello",cd);
}

ReturnCallback和ConfirmCallback的区别：

ConfirmCallback 负责“消息有没有到达交换机（Exchange）”
ReturnCallback 负责“消息从交换机路由到队列（Queue）失败了”

对比维度	ConfirmCallback	ReturnCallback
检测范围	生产者 → 交换机（Exchange）	交换机（Exchange） → 队列（Queue）
触发条件	消息被 Broker 接收后（无论路由成功/失败）	仅当路由失败（无匹配队列）时触发
核心作用	保证消息成功到达 MQ 服务端	保证消息成功到达目标队列
配置依赖	必须开启 `publisher-confirm-type`	必须开启 `publisher-returns`
是否为异常	可能是正常 `ack`，也可能是异常 `nack`	代表路由异常

MQ的可靠性

数据持久化

在默认情况下，RabbitMQ会将接收到的信息保存在内存中以降低消息收发的延迟。这样会导致两个问题：

一旦MQ宕机，内存中的消息会丢失
内存空间有限，当消费者故障或处理过慢时，会导致消息积压，引发MQ阻塞

RabbitMQ实现数据持久化包括3个方面：

交换机持久化
队列持久化
消息持久化

默认情况下，他们三个都是默认持久化的。

被动持久化策略：发送的消息类型是非持久化的，只有在消息队列满了后会被迫写入磁盘。这种策略由于磁盘读写瓶颈导致消息队列堵塞。为了解决这个问题才有了同步持久化策略，不会导致消息队列阻塞。

同步持久化策略：发送的消息类型是持久化的，来一条就直接持久化一条

Lazy Queue

从RabbitMQ的3.6.0版本开始，就增加了Lazy Queue的概念，也就是惰性队列。惰性队列的特征如下：

接收到消息后直接存入磁盘，不再存储到内存
消费者要消费消息时才会从磁盘中读取并加载到内存（可以提前缓存部分消息到内存，最多2048条）

在3.12版本后，所有队列都是Lazy Queue模式，无法更改。

要设置一个队列为惰性队列，只需要在声明队列时，指定x-queue-mode属性为lazy即可：

控制台

代码

@Bean
public Queue lazyQueue() {
	return QueueBuilder.durable("lazy.queue")
			.lazy()//开启Lazy模式
            .build();
}

// 或者

@RabbitListener(queuesToDeclare=@Queue(
			name = "lazy.queue",
			durable ="true",
			arguments = @Argument(name = "x-queue-mode", value ="lazy")
))
public void listenLazyQueue(String msg){
	log.info("接收到lazy.queue的消息:{}",msg);
}

Lazy Queue性能会好一点，推荐使用Lazy Queue。

消费者的可靠性

消费者确认机制

消费者确认机制（Consumer Acknowledgement）是为了确认消费者是否成功处理消息。当消费者处理消息结束后，应该向RabbitMQ发送一个回执，告知RabbitMQ自己消息处理状态：

ack：成功处理消息，RabbitMQ从队列中删除该消息
nack：消息处理失败，RabbitMQ需要再次投递消息
reject：消息处理失败并拒绝该消息，RabbitMQ从队列中删除该消息

Spring AMQP已经实现了消息确认功能。并允许我们通过配置文件选择ACK处理方式，有三种方式：

none：不处理。即消息投递给消费者后立刻ack，消息会立刻从MQ删除。非常不安全，不建议使用
manual：手动模式。需要自己在业务代码中调用api，发送ack或reject，存在业务入侵，但更灵活
auto：自动模式（推荐使用）。Spring AMQP利用AOP对我们的消息处理逻辑做了环绕增强，当业务正常执行时则自动返回ack。当业务出现异常时，根据异常判断返回不同结果：
- 如果是业务异常，会自动返回nack
- 如果是消息处理或校验异常，自动返回reject

spring:
 rabbitmq:
  listener:
   simple:
    prefetch: 1
    acknowledge-mode: none #none，关闭ack; manual，手动ack; auto：自动ack

失败重试机制

Spring AMQP提供了消费者失败重试机制，在消费者出现异常时利用本地重试，而不是无限的requeue到mq。我们可以通过在application.yaml文件中添加配置来开启重试机制：

spring:
 rabbitmq:
  listener:
   simple:
    prefetch: 1
    acknowledge-mode: auto #none，关闭ack; manual，手动ack; auto：自动ack
    retry:
     enabled: true #开启消费者失败重试
     initial-interval: 1000ms #初始的失败等待时长为1秒
     multiplier: 1 #下次失败的等待时长倍数，下次等待时长=multiplier*last-interval
     max-attempts: 3 #最大重试次数
     stateless: true #true无状态；false有状态。如果业务中包含事务，这里改为false

失败消息处理策略

在开启重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecoverer接口来处理，它包含三种不同的实现：

RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式
ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队
RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机

业务幂等性

当消费者消费成功后，再回复ack时直接宕机或者MQ宕机，导致没同步ack，服务器重启后，MQ再次发来已经消费的消息，这时候消费者重复执行，需要保证业务逻辑不会错误，这就是保持业务幂等性。

幂等是一个数学概念，用函数表达式来描述是这样的：f(x）=f(f(x))。在程序开发中，则是指同一个业务，执行一次或多次对业务状态的影响是一致的。

幂等

查询业务，例如根据d查询商品
删除业务，例如根据id删除商品

非幂等

用户下单业务，需要扣减库存
用户退款业务，需要恢复余额

唯一消息id

方案一，是给每个消息都设置一个唯一id，利用id区分是否是重复消息：

每一条消息都生成一个唯一的id，与消息一起投递给消费者。
消费者接收到消息后处理自己的业务，业务处理成功后将消息ID保存到数据库
如果下次又收到相同消息，去数据库查询判断是否存在，存在则为重复消息放弃处理。

业务判断

方案二，是结合业务逻辑，基于业务本身做判断。以我们的余额支付业务为例：

标记订单为已支付之前先判断是否已支付

延迟消息

延迟消息：发送者发送消息时指定一个时间，消费者不会立刻收到消息，而是在指定时间之后才收到消息。

延迟任务：设置在一定时间之后才执行的任务

这是一个兜底方案：假如消息一直发送不过来，或者一直接受不到，可以搞一个延迟消息

例子：客户提交订单后，扣库存，这时候等待玩家支付，因为种种原因，支付结果一直没发送过来。
- 这种情况下，可以在提交订单后发送一个延迟消息到延迟队列，比如30分钟后（例如30分钟未支付默认失败）执行，延迟消息执行就是去主动查看支付状态，然后处理逻辑。

实现延迟的方式

死信交换机

当一个队列中的消息满足下列情况之一时，就会成为死信（dead letter）：

消费者使用basic.reject或basic.nack声明消费失败，并且消息的requeue参数设置为false
消息是一个过期消息（达到了队列或消息本身设置的过期时间），超时无人消费（这个可以模拟延迟消息）
要投递的队列消息堆积满了，最早的消息可能成为死信

如果队列通过dead-letter-exchange属性指定了一个交换机，那么该队列中的死信就会投递到这个交换机中。这个交换机称为死信交换机（Dead Letter Exchange，简称DLX）。

通过死信交换机机制来实现延迟消息：

延迟消息插件

推荐使用

这个插件可以将普通交换机改造为支持延迟消息功能的交换机，当消息投递到交换机后可以暂存一定时间，到期后再投递到队列。

参考：MQ入门-02.初识MQ-同步调用优缺点_哔哩哔哩_bilibili

posted @ 2026-07-22 16:31 deyang 阅读(3) 评论(0) 收藏举报

刷新页面返回顶部

消息队列

消息队列

消息队列的作用

常见的消息队列产品

RabbitMQ

安装RabbitMQ

启动和关闭RabbitMQ

RabbitMQ整体架构及核心概念

RabbitMQ数据隔离

快速入门

交换机和队列指南

总览

直接模式

Work Queues模式

交换机模式

代码生成队列和交换机

消息转换器

RabbitMQ高级

发送者的可靠性

发送者重连

发送者确认

MQ的可靠性

数据持久化

Lazy Queue

消费者的可靠性

消费者确认机制

失败重试机制

失败消息处理策略

业务幂等性

唯一消息id

业务判断

延迟消息

延迟消息

实现延迟的方式

死信交换机

延迟消息插件

公告