RabbitMq面试题+答案

1.为什么使用RabbitMq

三大核心：异步、削峰、解耦
异步：
1.提高响应
2.避免第三方服务带来的影响
解耦：
1.提高系统的可用性和拓展性
削峰：
1.平缓处理突发请求的作用
2.缓存请求

2.RabbitMq如何实现延时队列

1.第一种是使用普通队列和死信队列来实现延时效果。大致是把消息放到普通队列中，设置一个TTL（过期时间），过期后消息被放到死信队列，然后通过监听死信队列来实现。
2.第二种是使用RabbitMq官方提供的delayed插件来实现。
应用场景：
1.订单超时未支付取消订单 等
2.退货后三天不理自动退款 等

3.使用消息队列有什么缺点

1.降低系统的可用性：系统引入外部的依赖越多，越容易挂掉
2.系统的复杂性提高：使用MQ后要确保消息有没有被消费，有没有被丢失，消息传递顺序的问题。
3.消息一致性问题：多系统之间调用的时候，可能会发生数据不一致（脏数据）

4.RabbitMq工作原理

1.发送方/生产者，发送消息的一方
2.broker ：接收消息和分发消息的应用，rabbitMq server 或者 message broker
3.exchange：交换器
4.queue：消息队列
5.消费者/接收方：消费处理消息的地方
6.channel：信道，发送消息的通道
7.binding：exchange和queue之间的虚拟连接，包含routing key
8.routingkey：路由键，是生产者发消息的时候指定的

5.RabbitMq交换机类型

1.direct（普通交换机）：路由键和队列名完全匹配交换机，单播模式。routingkey是完全匹配
2.fanout（扇形交换机）：扇出类型交换机，会将消息发送给所有绑定交换机的队列。routingkey不起效
3.topic（主题交换机）：主题交换机，与direct交换机类似，也是通过routingKey去一对多匹配，区别在于direct是完全匹配，topic是模糊匹配
4.headers（头交换机）：匹配AMQP消息的header 而不是路由键，此外和direct完全一致，但是性能极差。

6.简述RabbitMq的持久化机制

首先消息都是存在内存中的
1.交换机持久化
2.队列持久化
3.消息持久化
通过维护一张ets表来实现，append方式写入文件，RabbitMq启动时会启动两个进程，一个负责持久化消息存储，一个负责非持久化消息存储（当内存不足时才会），首先是先写入buffer缓冲区，再每隔25秒进行一次刷盘，写入文件。

7.简述RabbitMq事务消息机制

1.开启事务
2.发送消息或者消费消息
3.提交事务/或者回滚事务
消费者使用事务：
1.autoAck = false：手动提交事务
2.autoAck = true：自动提交事务，不支持事务，发送完消息就删除
任意一个环节出问题都会抛出IOException。事务都会降低RabbitMq的性能。
一般我们都不使用事务机制去处理消息，而是使用ACK确认机制去处理，因为事务是使用阻塞同步机制，影响性能。

8.RabbitMq的死信队列和延迟队列的原理

死信消息：（前提是有死信队列，否则消息都被删除）
1.消息被消费方否定确认（返回不是ACK），并且requeue属性被设置为false。
2.消息在队列存活的时间超过了设置的TTL时间
3.消息队列的消息数量已经超过了最大值（如果没有死信队列就会删除老的消息，有了就不会删除并且加入死信队列中）
那么改消息就会加入死信队列。

延迟队列原理：死信队列+TTL
把消息放入普通队列，设置TTL过期时间，并且设置有死信队列，消费者去监听死信队列

9.RabbitMq可以直连Queue吗

可以，但是丧失了灵活性。

10.RabbitMq如何保证消息的可靠性

1.使用事务消息
2.使用消息确认机制
发送方确认：
1.channel被设置为confirm模式，则每条消息都会设置一个唯一ID
2.消息投递成功，信道会发送ACK消息给发送方，包含了唯一ID，回调ConfirmCallBack接口
3.如果发生错误，会发送NACK消息给发送方，回调RerunCallBack接口
4.ACK和NACK只触发一次，且只有一次，异步触发，发完可继续发送
消费放确认：
1.声明队列时，指定noack=false（把自动提交改成手动提交），broker会等待消费放返回ACK消息，才会删除消息，否则自动删除
2.broker的ACK是没有超时机制的，一直等，如果连接断开，消息会被重发。

11.如何保证MQ消息消费的有序性

思路：保证生产者生产的消息能够按照顺序的发送到MQ服务器中，同时保证消息从MQ服务器到消费者也是按照顺序的。
方法一：拆分多个queue，每个queue有一个消费者消费消息。使用了队列的先进先出的性质，把同一组需要按照先后顺序的消息放入同一个队列当中，然后使用单线程的消费者去消费队列的消息，使其消费顺序可以保证。
方法二：对于多线程消费，可以使用重试机制，当消费者消费到不满足消费的情况的时候，进行重试。

12.如何处理消息堆积的情况

产生原因：消息堆积的原因往往是生产者生产消息的速率和消费者消费消息的速率相差太大导致的。有可能是消费者消费消息的能力弱了，也有可能是消费者往往复复的消费同一个消息。也有可能数据库挂了，导致消费失败或者消费者宕机了等等。

方案一：

临时扩容，快速处理积压的消息。先修复消费者的问题，确保其恢复消费的速度，然后将现有的消费者停掉。临时创建N倍的queue，然后写一个临时分发数据的消费程序，消费之后不做任何耗时处理，直接均匀临时写入建立好的N倍queue队列中去；接着用N倍的机器来部署consumer，每个consumer消费一个临时队列。等消费消息快消费完的时候恢复原先的部署架构。

方案二

恢复队列中的数据：如果设置了过期时间，消息再queue中积压超过一定的时间会被清理掉，导致数据丢失，实际上队列中没有什么消息积压，而是丢了大量的消息。所以不能说增加消费积压的数据，这种情况使用批量重导的方案进行解决，在流量低峰时期，写一个程序手动查询丢失的那部分数据，然后重新发送到MQ中。

13.如何保证消息队列的高可用

MQ基于主从做高可用性的，有三种模式：单机模式，普通集群模式，镜像集群模式
单机模式：一般没人使用
普通集群模式：普通集群用于提高系统的吞吐量，通过添加节点来扩展消息的队列的吞吐量。也就是多台服务器运行多个MQ实列，其中一个实列存放queue消息，其他的queue同步这个实列的元数据。无高可用性，RabbitMq内部产生大量的数据传输。
镜像集群模式：镜像集群模式是rabbitMq真正的高可用模式。集群中一般会有一个master节点和若干个slave节点，如果master节点由于某种原因导致宕机了，资历最久的slave节点会晋升为master节点。消息是master节点写入的，然后广播到每一个slave节点，消费消息时表面是消费者和slave节点交互，实则是slave节点通过建立tcp连接向slave节点获取数据。在镜像集群部署中，每个queue都包含了所有消息的元数据。