RabbitMq消息队列常见问题汇总

1、生产者确认机制

RabbitMq提供了publisher confirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。

消息失败之后如何处理呢？

·回调方法即时重发

·记录日志

·保存到数据库然后定时重发，成功发送后即刻删除表中的数据

2、消息持久化

MQ默认是内存存储消息，开启持久化功能可以确保缓存在MQ中的消息不丢失。

        1.交换机持久化：

@Bean

public DirectExchange simpleExchange(){

        // 三个参数：交换机名称、是否持久化、当没有queue与其绑定时是否自动删除

        return new DirectExchange("simple.direct", true, false);

}

        2.队列持久化

@Bean

public Queue simpleQueue(){

        // 使用QueueBuilder构建队列，durable就是持久化的

        return QueueBulider.durable("simple.queue").build();

}

        3.消息持久化，SpringAMQP中的消息默认是持久的，可以通过MessageProperties中的        DeliveryMode来指定

Message msg = MessageBuilder.withBody(message.getBytes(StandardCharsets.UTF-8)) //消息体

.setDeliverMode(MessageDeliverMode.PERSISTENT) //持久化

.build();

3、消费者确认机制

RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式：

• manual:手动ack,需要在业务代码结束后，调用api发送ack
• auto:自动ack,由spring监测listener代码是否出现异常，没有异常则返回ack;抛出异常则返回nack.
• none:关闭ack,MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除。

我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，设置重试次数，当次数达到了以后，如果消息依然失败，将消息投递到异常交换机，交由人工处理。

RabbitMQ-如何保证消息不丢失

答：我们项目中当时MYSQL和Redis的数据双写一致性就是采用RabbitMQ实现同步的，这里面就要求了消息的高可用性，我们要保证消息的不丢失。主要从三个层面考虑：

第一个是开启生产者确认机制，确保生产者的消息能到达队列，如果报错可以先记录到日志中，再去修复数据。

第二个是开启持久化功能，确保消息未消费前在队列中不会丢失，其中的交换机、队列、消息都要做持久化。

第三个是开启消费者确认机制为auto,由spring确认消息处理成功后完成ack,当然也需要设置一定的重试次数，我们当时设置了3次，如果重试3次还没有收到消息，就将失败后的消息投递到异常交换机，交由人工处理。

RabbitMq重复消费问题如何解决？

什么原因会造成消息的重复消费？

• 网路抖动
• 消费者挂了

如何解决消息的重复消费问题？

这个我们还真的遇到过，是这样的，我们当时消费者是设置了自动确认机制，当服务还没来得及给MQ确认的时候，服务宕机了，导致服务重启之后，又消费了一次消息。这样就重复消费了。

因为我们当时处理的支付（订单|业务唯一标识），它有一个业务的唯一标识，我们在处理消息时，先到数据库查询一下，这个数据是否存在，如果不存在，说明没处理过，这个时候就可以正常处理这个消息了。如果已经存在这个数据了，就说明消息重复消费了，我们就不需要再消费了。

其实这就是个典型的幂等性问题，比如：redis分布式锁、数据库的锁都是可以解决这个问题的。

RabbitMQ中死信交换机？（RabbitMQ延迟队列有了解过吗？）

• 延迟队列：进入队列的消息会被延迟消费的队列
• 场景：超市订单、限时优惠、定时发布

延迟队列 = 死信交换机 + TTL（生存时间）

死信交换机

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

• 消费者使用basic.reject或basic.nack生命消费失败，并且消息的requeue参数设置为false
• 消息是一个过期消息，超时无人消费
• 要投递的队列消息堆积满了，最早的消息可能成为死信

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

@Bean

public Queue ttlQueue(){

        return QueueBuilder.durable("simple.queue") //指定队列名称，并持久化

        .ttl(10000) //设置队列的超时时间，10秒

        .deadLetterExchange("dl.direct") //指定死信交换机

        .build();

}

TTL

TTL,也就是Time-To-live。如果一个队列中的消息TTL结束仍未消费，则会变为死信，ttl超时分为两种情况：

消息所在的队列设置了存活时间

消息本身设置了存活时间

// 创建消息

Message message = MessageBuilder

        .withBody("hello, ttl message".getBytes(StandardCharsets.UTF_8))

        .setExpiration("5000")

        .build();

// 消息ID，需要封装到CorrelationData中

CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString());

// 发送消息

rabbitTemplate.convertAndSend("ttl.direct", "ttl", message, correlationData);

延迟队列插件

DelayExchange插件，需要安装在RabbitMQ中

RabbitMQ有一个官方的插件社区，地址为：https://www.rabbitmq.com/comunity-plugins.html

DelayExchange的本质还是官方的三种交换机，只是添加了延迟功能，因此使用时只需要声明一个交换机，交换机的类型可以是任意类型，然后设定delayed属性为true即可。

RabbitMQ中死信交换机？（RabbitMQ延迟队列有了解过吗？）

答：我们当时的xx项目有个业务，需要用到延迟队列，其中就是使用RabbitMQ来实现的。

延迟队列就是用到了死信交换机和TTL（消息存活时间）来实现的。

如果消息超时未消费就会变成死信，在RabbitMQ中如果消息成为死信，队列可以绑定一个死信交换机，在死信交换机上可以绑定其他队列，在我们发消息的时候可以按照需求指定TTL的时间，这样就实现了延迟队列的功能了。

我记得RabbitMQ还有一种方式可以实现延迟队列，在RabbitMQ中安装一个死信插件，这样更方便一些，我们只需要在声明交换机的时候，指定这个就是死信交换机，然后在发送消息的时候直接指定超时时间就行了，相当于死信交换机+TTL要省略了一些步骤。

RabbitMQ如果有100万消息堆积在MQ，如何解决（消息堆积怎么解决）

答：当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。

解决消息堆积有三种思路

• 增加更多消费者，提高消费速度
• 在消费者内开启线程池加快消息处理速度
• 扩大队列容积，提高堆积上限，采用惰性队列

1. 在声明队列的时候可以设置属性x-queue-mode属性为lazy，即为惰性队列
2. 基于磁盘存储，消费上限高
3. 性能比较稳定，但基于磁盘存储，受限于IO，时效性会降低

惰性队列

惰性队列的特征如下：

接收到消息后直接存入磁盘而非内存

消费者要消费消息时才会从磁盘中读取并加载到内存

支持数百万条的消息存储

RabbitMQ的高可用机制有了解过吗？

• 在生产环境下，使用集群来保证高可用性
• 普通集群、镜像集群、仲裁队列

普通集群

普通集群，或者叫标准集群（classic cluster），具备下列特征：

• 会在集群的各个节点间共享部分数据，包括：交换机、队列元信息。不包含队列中的消息。
• 当访问集群某节点时，如果队列不在该节点，会从数据所在节点传递到当前节点并返回。
• 队列所在节点宕机，队列中的消息就会丢失。

镜像集群

镜像集群：本质是主从模式，具备下面的特征

• 交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份。
• 创建队列的节点被称为该队列的主节点，备份到的其他节点叫做该队列的镜像节点。
• 一个队列的主节点可能是另一个队列的镜像节点。
• 所有操作都是主节点完成，然后同步给镜像节点。

仲裁队列

仲裁队列：仲裁队列是3.8版本以后才有的新功能，用来替代镜像队列，具备下列特征

• 与镜像队列一样，都是主从模式，支持主从数据同步
• 使用非常简单，没有复杂的配置
• 主从同步基于Raft协议，强一致

RabbitMQ的高可用机制有了解过吗？

在生产环境下，我们当时采用的镜像模式搭建的集群，共有3个节点

镜像队列结构是一主多从（从就是镜像），所有操作都是主节点完成，然后同步给镜像节点

主宕机后，镜像节点会替代成新的主（如果在主从同步完成前，主就已经宕机，可能出现数据丢失）。

这种情况下，我们可以采用仲裁队列，与镜像队列一样，都是主从模式，支持主从数据同步，主从同步基于Raft协议，强一致，并且使用起来也非常简单，不需要额外的配置，在声明队列的时候只要指定这个是仲裁队列即可。