RabbitMQ 面试题目整理

136.rabbitmq 的使用场景有哪些？

MQ是一个互联网架构中常见的解耦利器。

什么时候不使用MQ？

上游实时关注执行结果

什么时候使用MQ？

1）数据驱动的任务依赖

2）上游不关心多下游执行结果

3）异步返回执行时间长

136.rabbitmq 有哪些重要的角色？

生产者：消息的创建者，负责创建和推送数据到消息服务器

消费者：消息的接收方，用于处理数据和确认消息

代理：就是RabbitMQ本身，用于扮演快递的角色，本身并不生产消息

137.rabbitmq 有哪些重要的组件？

ConnectionFactory(连接管理器)：应用程序与RabbitMQ之间建立连接的管理器

Channel(信道)：消息推送使用的通道

Exchange(交换器)：用于接受、分配消息

Queue(队列)：用于存储生产者的消息

RoutingKey(路由键)：生产者将消息发送给交换器的时候，会指定一个RoutingKey,用来指定这个消息的路由规则，这个RoutingKey需要与交换器类型和绑定键(BindingKey)联合使用才能最终生效。

BindKey(绑定键)：用于把交换器的消息绑定到队列上

138.rabbitmq 中 vhost 的作用是什么？

vhost可以理解为虚拟broker，即mini-RabbitMq server。其内部均还有独立的queue，exchange，和binding等，但最重要的是，其拥有独立的权限系统，可以做到vhost范围的用户控制。当然从rabbitMq的全局角度，vhost可以作为不同的权限隔离手段（一个典型的例子，就是不同的应用可以跑在不同的vhost种）。

139.rabbitmq 的消息是怎么发送的？

首席先客户端必须练接到RabbitMQ服务器才能发布和消费消息，客户端和rabbit server 之间，会创建一个tcp连接，一旦tcp打开并通过了认证，（认证就是你发送给rabbit服务器的用户名和密码），你的客户端和RabbitMq，就创建了一条amqp信道（channel），信道创建在“真实”tcp的虚拟连接，amqp，命令都是通过信道发送出去的，每个信道有唯一的id，不论是发布消息，订阅队列都是通过这个信道完成的。

140.rabbitmq 怎么保证消息的稳定性？

提供了事务功能

通过将channel设置为confirm（确认）模式。

141.rabbitmq 怎么避免消息丢失？

消息持久化 ack确认机制，设置集群镜像模式，消息补偿机制

142.要保证消息持久化成功的条件有哪些？

申明队列必须设置持久化durable 设置为true

消息推送投递模式必须设置持久化，deliveryMode 设置为2（持久）

消息已经到达持久化的交换机器

消息已经到达持久化队列

143.rabbitmq 持久化有什么缺点？

将内存中的消息持久化到硬盘上，即使重启 RabbitMQ，消息也不会丢失。持久化队列和非持久化队列的区别是，持久化队列会被保存在磁盘中，固定并持久的存储，当 Rabbit 服务重启后，该队列会保持原来的状态在RabbitMQ 中被管理，而非持久化队列不会被保存在磁盘中，Rabbit 服务重启后队列就会消失。非持久化比持久化的优势就是，由于非持久化不需要保存在磁盘中，所以使用速度就比持久化队列快。即是非持久化的性能要高于持久化。而持久化的优点就是消息会一直存在，不会随服务的重启或服务器的宕机而消失。使用的时候需要根据实际需求来判断具体如何使用。

144.rabbitmq 有几种广播类型？

3.1 第一种模型(直连)

3.2 第二种模型(work quene)

Work queues，也被称为（Task queues），任务模型。当消息处理比较耗时的时候，可能生产消息的速度会远远大于消息的消费速度。长此以往，消息就会堆积越来越多，无法及时处理。此时就可以使用work 模型：让多个消费者绑定到一个队列，共同消费队列中的消息。队列中的消息一旦消费，就会消失，因此任务是不会被重复执行的。

3.3 第三种模型(fanout)

扇出也称为广播

广播模式下，消息发送流程是这样的：

可以有多个消费者

每个消费者有自己的queue（队列）

每个队列都要绑定到Exchange（交换机）

生产者发送的消息，只能发送到交换机，交换机来决定要发给哪个队列，生产者无法决定。

交换机把消息发送给绑定过的所有队列

队列的消费者都能拿到消息。实现一条消息被多个消费者消费

3.4 第四种模型(Routing)

3.4.1 Routing 之订阅模型-Direct(直连)

在Fanout模式中，一条消息，会被所有订阅的队列都消费。但是，在某些场景下，我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。

在Direct模型下：

队列与交换机的绑定，不能是任意绑定了，而是要指定一个RoutingKey（路由key）

消息的发送方在向 Exchange发送消息时，也必须指定消息的 RoutingKey。

Exchange不再把消息交给每一个绑定的队列，而是根据消息的Routing Key进行判断，只有队列的Routingkey与消息的 Routing key完全一致，才会接收到消息

3.4.2 Routing 之订阅模型-Topic

Topic类型的Exchange与Direct相比，都是可以根据RoutingKey把消息路由到不同的队列。只不过Topic类型Exchange可以让队列在绑定Routing key 的时候使用通配符！这种模型Routingkey 一般都是由一个或多个单词组成，多个单词之间以”.”分割，例如： item.insert

145.为什么使用rabbitmq,rabbitMq优缺点？

1.解耦（为面向服务的架构（SOA）提供基本的最终一致性实现）

2. 异步提升效率

3. 流量削峰

系统的可用性降低
系统引入的外部依赖越多，系统越容易挂掉，本来只是A系统调用BCD三个系统接口就好

ABCD四个系统不报错整个系统会正常运行。引入了MQ之后，虽然ABCD系统没出错，但MQ挂了以后，整个系统也会崩溃。

系统的复杂性提高

RabbitMq

优点

1.轻量级，部署放便快捷

2.支持灵活的路由配置，可以根据配置的路由规则，让生产者生产出来的消息发送到不同的队列中。

3.兼容性好，RabbitMQ的客户端支持大多数的编程语言

缺点

1.如果有大量的消息堆积在队列中，性能会急剧下降

2.RabbitMQ是用Erlang开发的，在功能拓展和二次开发上不友好

3.对比RocketMQ和kafka，RabbitMQ性能是最差的

RocketMQ

优点

1.功能全，RocketMQ基本具备了消息队列应有的所有功能

2.RocketMQ使用java语言开发，在进行debug源码，扩展功能和二次开发方面都很友好

3.性能高，毫秒级响应，经受过多次双十一的考验

缺点

1.兼容性不好，目前只支持java和c++，但C++尚不成熟

2.社区活跃度一般

kafka

优点

1.可靠性和稳定性很高

2.性能卓越，单机吞吐量高

3.有很好的管理界面Kafka-Manager

4.日志领域非常成熟

缺点

1.消费失败后不能重试

2.由于是异步和批处理，延迟高

3.使用短轮询方式，实时性取决于轮询间隔时间

正在上传…重新上传取消

原文链接：RabbitMQ笔记---对比其他MQ优缺点_求求你，别报错了！的博客-CSDN博客_rabbitmq优缺点

146.RabbitMq交换机的类型（广播类型）？

Rabbitmq提供的交换机类型有fanout、direct、topic、headers四种。在AMQP协议中还提到另外两种类型：System和自定义，本次文章主要介绍一下常用的交换机的特性。

1.fanout

该类型的交换机会将一条消息广播到绑定到该交换机的所有队列上，不论你设置的路由键是什么。

正在上传…重新上传取消

2.direct

该类型的交换机会将绑定的路由键完全匹配的方式路由到指定的队列上。如果路由键不匹配，那么就不会发送到任何队列中去。

正在上传…重新上传取消

3.topic

该种类型的交换机会是对上述fanout和direct类型的交换机的一种扩展。其和direct很类似，但是匹配规则上有所不同。其约定的路由匹配规则有：

routingkey通过符号“.”进行分割，其分割出来的单词就是路由的匹配元素。比如com.aa.tian这种就表示顺序单词com、aa、tian。

符号“*”和“#”分别用来进行模糊匹配，其中“*”用来表示一个单词，“#”用来匹配多个单词。

总结一下就是符号“*”表征一个单词，“#”表征多个单词。

正在上传…重新上传取消

4.headers

该类型的交换器不依赖路由键的匹配规则分发消息，而是根据发送的消息内容的headers属性进行匹配。在绑定队列和交换器时制定一组键值对，当发送消息到交换机的时候，rabbitmq会获取该消息的headers，对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对。如果完全匹配消息就会路由到该队列，否则不会路由到该队列。headers类型的交换机性能会很差，而且也不实用！

147.rabbitmq 怎么实现延迟消息队列？

通过消息过期后进入死信交换器

再交由交换器转发到延迟消费队列，实现延迟功能

使用Rabbit-delayed-message-exchange插件实现延迟功能

148.rabbitmq 集群有什么用？

高可用：某个服务器出现问题，整个RabbitMq还可以继续使用

高容量：集群可以承担更多的消息量

149.rabbitmq 节点的类型有哪些？

磁盘节点：消息会存储到磁盘

内存节点：消息都存储在内存中，重启服务器消息丢失，性能高于磁盘类型

150.rabbitmq 集群搭建需要注意哪些问题？

各节点直接使用“--link”连接，此属性不能忽略

各个节点使用的erlang cookie，值必须相同，此值相当于“秘钥”的功能，用于各个节点的认证。

整个集群必须包含一个磁盘节点

151.rabbitmq 每个节点是其他节点的完整拷贝吗？为什么？

不是，原因有一下两个：

存储空间的考虑:如果每个节点都拥有所有队列的完全拷贝

这样新增节点不但没有新增存储空间，反而增加了很多冗余数据

性能的考虑：如果每条消息都需要完整的拷贝到每个集群节点

那新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。

150.rabbitmq 集群中唯一一个磁盘节点崩溃了会发生什么情况？

如果唯一磁盘磁盘节点崩溃了，不能进行一下操作:

不能创建队列，

不能创建交换机，

不能创建绑定，

不能添加用户，

不能更改权限，

唯一的磁盘节点崩溃了，集群是可以保持运行的，但还是你不能更改任何东西

152.rabbitmq 对集群节点停止顺序有要求吗？

Rabbit 对集群的停止有顺序要求的

应该先关闭内存节点，在关闭磁盘节点，如果顺序相反的话，可能会造成消息的丢失

153.rabbitmq 死信队列？

154.如何保证消息确定消息发送成功，并且被消费成功?

解析：这里不用背，这里的问法会有很多中，这道题中问了两部分

第一部分是确保发送成功，还可以被问成：消息发送失败了怎么办，或者如何保证消息可靠传输

第二部分是确保消费成功，还可以被问成：消息消费时，发生异常了，消息已经被消费了，怎么办等

首先，需要确保消息被发送成功，rabbitmq中提供了事物和confirm的机制，事物的话，就类似于数据库的事物，开启，执行，提交，如果过程中发生任何异常，就会触发回滚机制，我们可以在回滚中加入一些逻辑处理，重新发送或者日志记录，同时配置生产者确认的机制，就是在消息发送之后，该消息会被指定唯一的ID，如果有消息成功被交换机转发到队列之后，mq会给生产者发送ack确认，如果没有队列接收消息，那么会发送错误回执消息给生产者，生产者可以尝试重试发送，或者日志记录。通过这些可以看出，mq会增加一些保障性措施，必然会导致性能有一些下降，如果要保证消息的严格一致性，那么可以配置这些，如果消息不重要，或者允许有丢失的情况，那么可以不用配置，这样的话能提升mq的性能。

其次就是，消息确保发送成功之后，还要确保消息被消费成功，因为在消费者端，如果消息消费时发生异常，又没有做一些处理，那么消息就会丢失，这种情况，可以采取两种方式解决

第一种就是消费端配置手动ACK确认机制，消息被消费完成的时候，手动确认告诉mq消费成功，mq才会删除消息，如果消息被接收了，但是mq没有收到ack确认，那么消息在mq中会变为unacked状态，我们可以通过项目日志或者mq面板监控，当消费者断开连接之后，消息会重新回到队列中，消费者重新连接之后，会再次收到消息。

第二种就是可以结合数据库解决，生产者端发送成功之后，可以在数据库中存储发送的消息和发送时间，并标记状态为未消费状态，消费者端消费完成之后，标记mysql中数据的状态为已经消费。消费者端通过定时任务去数据库跑批检索超时未被消费的消息并重新发送，这种方式可以很好的解决消费失败的问题，但是增加了生产者和消费者之间的耦合度，以及会造成消息重复消费的问题，我们可以在保证消息发送成功的基础上，将上述逻辑放在消费者端，生产者正常发送消息，消费者在收到消息之后，存储到myqsl中，标记状态为未消费，同时ack通知mq确认，然后再消费消息，消息消费成功之后，改变mysql状态为已消费，消费端同时配置定时任务跑批检索数据库，定时重新执行超时未消费的消息。

以上的解决办法都是需要根据实际的业务需求来的，如果消息需要保证强一致性，不能出现任何差错，那么就需要按照前面说的添加对应的配置

我们项目中的mq主要用于数据同步使用的，mysql数据发生变化之后，需要同步到es索引库以及静态化页面中，这里我们配置了生产者确认模式，和消费者手动ack确认机制。