RabbitMQ面试题及原理

RabbitMQ使用场景：

异步发送（验证码、短信、邮件…）MYSQL和Redis, ES之间的数据同步分布式事务削峰填谷 1. 消息可靠性（不丢失）

消息丢失场景：

RabbitMQ-如何保证消息不丟失？

开启生产者确认机制，确保生产者的消息能到达队列开启持久化功能，确保消息未消费前在队列中不会丢失开启消费者确认机制为auto，由spring确认消息处理成功后完成ack开启消费者失败重试机制，多次重试失败后将消息投递到异常交换机，交由人工处理 1.1 生产者确认

防止在传输过程中消息丢失（生产者导致消息丢失）

1.2 消息持久化

保证MQ宕机后消息不丢失

1.3 消费者确认

防止消费者宕机后未处理导致消息丢失（消费者导致消息丢失）

2. 解决消息重复消费

消息重复消费场景：

网络抖动消费者挂了 解决方案（适用于任何消息中间件）：每条消息设置一个唯一的标识id幂等方案：【分布式锁、数据库锁（悲观锁、乐观锁）】

在处理消息时，先到数据库查询一下，这个数据是否存在，如果不存在，说明没有处理过，这个时候就可以正常处理这个消息了。如果己经存在这个数据了，就说明消息重复消费了，就不需要再消费了。

3. 死信交换机（延迟队列）

延迟队列=死信交换机＋TTL（生存时间） 使用场景：

延迟队列：进入队列的消息会被延迟消费的队列场景：超时订单（购票、下单）、限时优惠、定时发布 3.1 死信交换机

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

消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false消息是一个过期消息，超时无人消费要投递的队列消息堆积满了，最早的消息可能成为死信 如果该队列配置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，简称DLX）。 3.2 TTL

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

消息所在的队列设置了存活时间消息本身设置了存活时间（以最短延迟时间为准） 3.3 延迟队列插件

DelayExchange插件，需要安装在尽abbitMQ中 RabbitMQ有一个官方的插件社区，地址为: .rabbitmq /community-plugins.html

4. 解决消息堆积

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

增加更多消费者，提高消费速度在消费者内开启线程池加快消息处理速度（因为是利用cpu，所以考虑硬件）扩大队列容积，提高堆积上限 4.1 惰性队列

特征：

接收到消息后直接存入磁盘而非内存消费者要消费消息时才会从磁盘中读取并加载到内存支持数百万条的消息存储 实现：在声明队列的时候可以设置属性x-queue-mode为lazy，即为惰性队列基于磁盘存储，消息上限高性能比较稳定，但基于磁盘存储，受限于磁盘I0，时效性会降低 5. 高可用机制（集群）

在生产环境下，使用集群来保证高可用性：

普通集群镜像集群仲裁队列 5.1 普通集群

节点宕机导致消息丢失，无法保证高可用

5.2 镜像集群

解决普通集群节点宕机导致消息丢失的问题，从而保证高可用 局限性：镜像节点未来得及从主节点同步数据，主节点就挂掉

5.3 仲裁队列

主从同步基于Raft协议保证强 一致性，代替镜像集群