RabbitMQ面试题总结

文章目录

1、什么是rabbitmq？

答：
采用AMQP高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦。

2、为什么要使用rabbitmq？

答：
1、在分布式系统下具备异步,削峰,负载均衡等一系列高级功能；

2、拥有持久化的机制，进程消息，队列中的信息也可以保存下来。

3、实现消费者和生产者之间的解耦。

4、对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作。

5、可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单。

3、使用rabbitmq的场景。

答：

• 异步处理 - 相比于传统的串行、并行方式，提高了系统吞吐量。
• 应用解耦 - 系统间通过消息通信，不用关心其他系统的处理。
• 流量削锋 - 可以通过消息队列长度控制请求量；可以缓解短时间内的高并发请求。
• 日志处理 - 解决大量日志传输。
• 消息通讯 - 消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。

4、如何确保消息正确地发送至RabbitMQ？如何确保消息接收方消费了消息？

答：

发送方确认模式

1.将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。

2.一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一 ID）。

3.如果 RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（notacknowledged，未确认）消息。发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。

接收方确认机制

接收方消息确认机制

消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；

下面罗列几种特殊情况

如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。

（可能存在消息重复消费的隐患，需要去重）如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。

5.如何避免消息重复投递或重复消费？

答：

在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；

在消息消费时，要求消息体中必须要有一个 bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID 等）作为去重的依据，避免同一条消息被重复消费。

6、消息基于什么传输？

答：

由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制

7、消息如何分发？

答：

若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。

通过路由可实现多消费的功能

8、消息怎么路由？

答：

消息提供方->路由->一至多个队列

消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。

通过队列路由键，可以把队列绑定到交换器上。

消息到达交换器后，RabbitMQ 会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）；

常用的交换器主要分为一下三种

1.fanout：如果交换器收到消息，将会广播到所有绑定的队列上

2.direct：如果路由键完全匹配，消息就被投递到相应的队列

3.topic：可以使来自不同源头的消息能够到达同一个队列。 使用topic交换器时，可以使用通配符

9、如何确保消息不丢失？

答：

消息持久化，当然前提是队列必须持久化

RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。

一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。

10、使用RabbitMQ有什么好处？

答：

1、服务间高度解耦
2、异步通信性能高
3、流量削峰

11、mq的缺点

答：

系统可用性降低

系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人 ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。

系统复杂性提高硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。

一致性问题

A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的。

12、你们公司生产环境用的是什么消息中间件？

答：

这个首先你可以说下你们公司选用的是什么消息中间件，比如用的是RabbitMQ，然后可以初步给一些你对不同MQ中间件技术的选型分析。

举个例子：比如说ActiveMQ是老牌的消息中间件，国内很多公司过去运用的还是非常广泛的，功能很强大。

但是问题在于没法确认ActiveMQ可以支撑互联网公司的高并发、高负载以及高吞吐的复杂场景，在国内互联网公司落地较少。而且使用较多的是一些传统企业，用ActiveMQ做异步调用和系统解耦。

然后你可以说说RabbitMQ，他的好处在于可以支撑高并发、高吞吐、性能很高，同时有非常完善便捷的后台管理界面可以使用。

另外，他还支持集群化、高可用部署架构、消息高可靠支持，功能较为完善。

而且经过调研，国内各大互联网公司落地大规模RabbitMQ集群支撑自身业务的case较多，国内各种中小型互联网公司使用RabbitMQ的实践也比较多。

除此之外，RabbitMQ的开源社区很活跃，较高频率的迭代版本，来修复发现的bug以及进行各种优化，因此综合考虑过后，公司采取了RabbitMQ。

但是RabbitMQ也有一点缺陷，就是他自身是基于erlang语言开发的，所以导致较为难以分析里面的源码，也较难进行深层次的源码定制和改造，毕竟需要较为扎实的erlang语言功底才可以。

然后可以聊聊RocketMQ，是阿里开源的，经过阿里的生产环境的超高并发、高吞吐的考验，性能卓越，同时还支持分布式事务等特殊场景。

而且RocketMQ是基于Java语言开发的，适合深入阅读源码，有需要可以站在源码层面解决线上生产问题，包括源码的二次开发和改造。

另外就是Kafka。Kafka提供的消息中间件的功能明显较少一些，相对上述几款MQ中间件要少很多。

但是Kafka的优势在于专为超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景来设计。

因此Kafka在大数据领域中配合实时计算技术（比如Spark Streaming、Storm、Flink）使用的较多。但是在传统的MQ中间件使用场景中较少采用。

13、Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？

答：
综上，各种对比之后，有如下建议：

一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；

后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的Java工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；

不过现在确实越来越多的公司会去用RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ已捐给Apache，但GitHub上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用RocketMQ，否则回去老老实实用RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ是很好的选择。

如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

14、消息的顺序问题

消息有序指的是可以按照消息的发送顺序来消费。

假如生产者产生了2条消息：M1、M2，假定 M1 发送到S1，M2 发送到S2，如果要保证 M1先于M2被消费，怎么做？

解决方案：

1. 保证生产者-MQServer-消费者是一对一对一的关系：
   
   缺陷：
   并行度就会成为消息系统的瓶颈（吞吐量不够）

更多的异常处理，比如：只要消费端出现问题，就会导致整个处理流程阻塞，我们不得不花费更多的精力来解决阻塞的问题。 （2）通过合理的设计或者将问题分解来规避。

不关注乱序的应用实际大量存在

队列无序并不意味着消息无序 所以从业务层面来保证消息的顺序而不仅仅是依赖于消息系统，是一种更合理的方式

15、RabbitMQ基本概念

答：

Broker：简单来说就是消息队列服务器实体

Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列

Queue：消息队列载体，每个消息都会被投入到一个或多个队列

Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来

Routing Key： 路由关键字，exchange根据这个关键字进行消息投递

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

Producer： 消息生产者，就是投递消息的程序

Consumer：消息消费者，就是接受消息的程序

Channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。

16.RabbitMQ的工作模式

一.simple模式（即最简单的收发模式）

1. 消息产生消息，将消息放入队列
2. 消息的消费者(consumer) 监听 消息队列,如果队列中有消息,就消费掉,消息被拿走后,自动从队列中删除(隐患 消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失，这里可以设置成手动的ack,但如果设置成手动ack，处理完后要及时发送ack消息给队列，否则会造成内存溢出)。

二.work工作模式(资源的竞争)

3. 消息产生者将消息放入队列消费者可以有多个,消费者1,消费者2同时监听同一个队列,消息被消费。
4. C1 C2共同争抢当前的消息队列内容,谁先拿到谁负责消费消息(隐患：高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关(syncronize) 保证一条消息只能被一个消费者使用)。

三.publish/subscribe发布订阅(共享资源)

5. 每个消费者监听自己的队列；
6. 生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队列都将接收到消息。

四.routing路由模式

8. 消息生产者将消息发送给交换机按照路由判断,路由是字符串(info) 当前产生的消息携带路由字符(对象的方法),交换机根据路由的key,只能匹配上路由key对应的消息队列,对应的消费者才能消费消息；

9. 根据业务功能定义路由字符串；
10. 从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中。

五.topic 主题模式(路由模式的一种)

12. 星号井号代表通配符
13. 星号代表多个单词,井号代表一个单词
14. 路由功能添加模糊匹配
15. 消息产生者产生消息,把消息交给交换机
16. 交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费（在我的理解看来就是routing查询的一种模糊匹配，就类似sql的模糊查询方式）

17、如何保证RabbitMQ消息的顺序性？

答：

拆分多个queue(消息队列)，每个queue(消息队列) 一个consumer(消费者)，就是多一些queue(消息队列)而已，确实是麻烦点；

或者就一个queue (消息队列)但是对应一个consumer(消费者)，然后这个consumer(消费者)内部用内存队列做排队，然后分发给底层不同的worker来处理。

RabbitMQ可能出现数据错乱问题

这是MQ面试必问的问题之一。第一看看你了解不了解顺序这个事，第二看看你有没有办法保证消息是有序的。这是生成环境中常见的问题。

mysql的binlog同步。你再mysql里增删改3条binlog。接着这三条binlog发送到MQ里面。到消费出来依次执行。起码要保证人家是按照顺序来的吧。不然本来是增加、修改、删除。你愣是给更改了顺序，换成了删除、修改、增加。这就乱了。

如何保证消息的顺序性

搞3个Queue，每个消费者就消费其中的一个Queue。把需要保证顺序的数据发到1个Queue里去。

18、如何解决消息积压

如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百分消息持续积压几个小时，说说怎么解决。

这些问法，本质上都是针对场景，都是说可能你的消息端出来问题，不消费了。或者消费的及其慢。接着就坑爹了。可能你的消息队列集群的磁盘都快满了。都没人消费，这个时候怎么办？或者是积压了几个小时，怎么办？或者是积压时间太长了，导致比如RabbitMQ设置了过期时间后就没了。其实这事，线上挺常见的，一般不出，一出就是大case。举个例子，消费端每次消费之后要写mysql，结果mysql挂了，消费端不动了，或者是消费端出了什么叉子，导致消费速度灰常慢。

快速处理积压的消息

（1）大量消息在MQ里积压几个小时，还没解决

几千万条数据在MQ里，积压了七八个小时。这个时候就是恢复consumer的问题。让它恢复消费速度，然后傻傻地等待几个小时消费完毕。这个肯定不能再面试的时候说。1个消费者1秒时1000条，1秒3个消费者是3000条。1分钟是18万条。1个小时是1000多万条。如果积压了上万条数据，即使消费者恢复了，也大概需要1个多小时才能恢复过来。

原来3个消费者1个小时。现在30个消费者，需要10分钟搞定。

一般情况下，这个时候只能做临时扩容了。具体操作步骤和思路如下：

一般情况下，这个时候只能做临时扩容了。具体操作步骤和思路如下：

① 先修改consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。

    ② 新建1个topic，partition是原来的10倍，临时建立好原来10倍或者20倍的Queue。

    ③ 然后写一个临时的分发数据的consumer程序，这个程序部署上去，消费积压的数据。消费之后，不做耗时的处理。直接均匀轮训写入临时建立好的10倍数量的Queue。

    ④ 接着征用10倍的机器来部署consume。每一批consumer消费1个临时的queue。

    ⑤ 这种做法，相当于将queue资源和consume资源扩大10倍，以10倍的速度来消费数据。

    ⑥ 等快速消费完积压数据之后，恢复原来的部署架构，重新用原先的consumer来消费消息。

19.过期失效了怎么办

过期失效就是TTL。如果消息在Queue中积压超过一定的时间就会被RabbitMQ给清理掉。这个数据就没了。这就不是数据积压MQ中了，而是大量的数据会直接搞丢。

写个临时的程序，一点一点查出来，然后再灌入MQ中，把白天丢失的数据补回来。

死信交换机和死信队列