RabbitMQ 常见面试题

1.RabbitMQ的三大核心

1. 流量削峰
2. 代码解耦
3. 异步处理

2.RabbitMQ的五消息模型

1. 简单消息模型 功能：一个生产者P发送消息到队列Q,一个消费者C接收。实现了基本的消息的生产和消费。一对一。
2. 工作队列 功能：一个生产者，多个消费者。写法与基本消息模型类似，只不过原来是一个消费者，现在是多个消费者。多个消费者处理队列中的数据。
3. 发布订阅模型 功能：一个生产者发送的消息会被多个消费者获取。一个生产者、一个交换机、多个队列、多个消费者
4. 路由模式 功能：生产者发送消息到交换机并且要指定路由key，消费者将队列绑定到交换机时需要指定路由key。只有当两个key相匹配时，消息才会发送到对应的消费者队列。即在广播的基础上有了路由的功能
5. 主题订阅模式 功能：生产者P发送消息到交换机X，type=topic，交换机根据绑定队列的routing key的值进行通配符匹配； 符号#：匹配一个或者多个词 lazy.# 可以匹配 lazy.irs或者lazy.irs.cor； 符号：只能匹配一个词 lazy. 可以匹配 lazy.irs或者lazy.cor

3.RabbitMQ如何防止消息丢失

1. RabbitMQ消息丢失的情况 : 第一种：生产者弄丢了数据。生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。 第二种：RabbitMQ 弄丢了数据。MQ还没有持久化自己挂了 第三种：消费端弄丢了数据。刚消费到，还没处理，结果进程挂了，比如重启了。
2. 解决方案针对生产者： 1.使用confirm机制。 2.开启RabbitMQ事务 。针对RabbitMQ ： 1.消息持久化 2.设置集群镜像模式 3.消息补偿机制针对消费者 ：ACK确认机制。

4.RabbitMQ如何保证消息不会重复消费

1. 为什么会出现消息重复？生产时消息重复 由于生产者发送消息给MQ，在MQ确认的时候出现了网络波动，生产者没有收到确认，实际上MQ已经接收到了消息。这时候生产者就会重新发送一遍这条消息。 生产者中如果消息未被确认，或确认失败，我们可以使用消息重试消费时消息重复 消费者消费成功后，再给MQ确认的时候出现了网络波动，MQ没有接收到确认，为了保证消息被消费，MQ就会继续给消费者投递之前的消息。这时候消费者就接收到了两条一样的消息。 由于重复消息是由于网络原因造成的，因此不可避免重复消息。但是我们需要保证消息的幂等性。
2. 如何保证消息幂等性? 让每个消息携带一个全局的唯一ID，即可保证消息的幂等性，具体消费过程为：消费者获取到消息后先根据id去查询redis/db是否存在该消息 如果不存在，则正常消费，消费完毕后写入redis/db 如果存在，则证明消息被消费过，直接丢弃

5.RabbitMQ死信队列和延迟队列分别是什么?

1. 死信队列就是一个普通的交换机，有些队列的消息成为死信后，（比如过期了或者队列满了）这些死信一般情况下是会被 RabbitMQ 清理的。但是你可以配置某个交换机为此队列的死信交换机，该队列的消息成为死信后会被重新发送到此 死信队列。至于怎么处理这个DLX中的死信就是看具体的业务场景了，死信队列中的信息可以被路由到新的队列。

消息成为死信的三种情况?

1.队列长度到达限制，无法加入新的消息
2.消费者拒接消费消息，并且不重回队列。该信息会被清除并进入死信队列
3.原队列存在消息过期设置，消息到达超时时间未被消费

1. 延迟队列，即消息进入队列后不会立即被消费，只有到达指定时间后，才会被消费。

5.RabbitMQ如何解决消息堆积？

消息堆积原因:
1.消息堆积即消息没及时被消费，是生产者生产消息速度快于消费者消费的速度导致的。
2.消费者消费慢可能是因为：本身逻辑耗费时间较长、阻塞了。

1. 预防措施:

生产者:
1.给消息设置年龄，超时就丢弃
2.考虑使用队列最大长度限制
3.减少发布频率

消费者:
增加消费者的处理能力 //优化代码；使用JDK的队列缓存数据，多线程去处理（一般考虑顺序问题，采用单例线程）
建立新的queue，消费者同时订阅新旧queue，采用订阅模式

1. 使用缓存:

生产者端缓存数据，在mq被消费完后再发送到mq，打破发送循环条件。设置合适的qos值（channel.BasicQos()方法：每次从队列拉取的消息数量），当qos值被用光，而新的ack没有被mq接收时，就可以跳出发送循环，去接收新的消息。
消费者主动block接收进程，消费者感受到接收消息过快时主动block，利用block和unblock方法调节接收速率，当接收线程被block时，跳出发送循环。