it编程 > 前端脚本 > Erlang

25道RabbitMQ面试题含答案(很全)

225人参与 2024-07-28 Erlang

点击下载《25道rabbitmq面试题含答案(很全)》

1. 什么是rabbitmq

rabbitmq是一个开源的消息队列系统,它使用amqp(高级消息队列协议)标准。rabbitmq的主要目标是提供可靠的消息传递,确保消息的可靠性和顺序性,同时提供灵活的路由和消息确认机制。

rabbitmq基于amqp协议工作,它通过消息的发布/订阅模式实现消息的传递。主要包括三个角色:生产者(producer)、交换机(exchange)和队列(queue)。生产者负责生成消息,交换机负责接收生产者的消息并根据指定的规则路由到队列,而队列则负责存储这些消息,等待消费者(consumer)来消费。

2. rabbitmq支持哪些协议?

rabbitmq支持amqp协议,也支持mqtt、stomp等其他协议。

3. 解耦、异步、削峰是什么?

解耦:a 系统发送数据到 bcd 三个系统,通过接口调用发送。如果 e 系统也要这个数据呢?那如果 c 系统现在不需要了呢?a 系统负责人几乎崩溃…a 系统跟其它各种乱七八糟的系统严重耦合, a 系统产生一条比较关键的数据,很多系统都需要 a 系统将这个数据发送过来。如果使用 mq,a系统产生一条数据,发送到 mq 里面去,哪个系统需要数据自己去 mq 里面消费。如果新系统需要数据,直接从 mq 里消费即可;如果某个系统不需要这条数据了,就取消对 mq 消息的消费即可。这样下来,a 系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。

就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用 mq 给它异步化解耦。

异步:a 系统接收一个请求,需要在自己本地写库,还需要在 bcd 三个系统写库,自己本地写库要 3ms,bcd 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求。如果使用 mq,那么 a 系统连续发送 3 条消息到 mq 队列中,假如耗时 5ms,a 系统从接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms。

削峰:减少高峰时期对服务器压力。

4. 消息队列有什么缺点

系统可用性降低

本来系统运行好好的,现在你非要加入个消息队列进去,那消息队列挂了,你的系统不是呵呵了。因此,系统可用性会降低;

系统复杂度提高

加入了消息队列,要多考虑很多方面的问题,比如:一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此,需要考虑的东西更多,复杂性增大。

一致性问题

a 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 bcd 三个系统那里,bd 两个系统写库成功了,结果 c 系统写库失败了,咋整?你这数据就不一致了。

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

5. kafka、activemq、rabbitmq、rocketmq 有什么优缺点?

特性activemqrabbitmqrocketmqkafka
单机吞吐量万级,比rocketmokafka 低一个数量级同activemq10 万级,支撑高吞吐10 万级,高吞吐,一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响————topic 可以达到几百/几千的级别,吞叶量会有较小幅度的下降,这是 rocketmo 的一大优势,在同等机器下,可以支撑大量的 topictopic 从几十到几百个时候,吞吐量会大幅度下降,在同等机器下,kafka 尽量保证 topic 数量不要过多,如果要支撑大规模的 topic,需要增加更多的机器资源
时效性ms级微秒级,这是rabbitmq的一大特点,延迟最低ms级延迟在 ms 级以内
可用性高,基于主从架构实现高可用同activemq非常高,分布式架构非常高,分布式,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
消息可靠性有较低的概率丢失数据基本不丢经过参数优化配置,可以做到 0丢失同 rocketmq
功能支持mq 领域的功能极其完备基于erlang开发,并发能力很强,性能极好延时很低mq 功能较为完善,还是分布式的,扩展性好功能较为简单,主要支持简单的 mo 功能,在大数据领域的实时计算以及日志采集被大规模使用

综上,各种对比之后,有如下建议:

6. mq 有哪些常见问题?如何解决这些问题?

消息的顺序问题

消息有序指的是可以按照消息的发送顺序来消费。假如生产者产生了2 条消息:m1、m2,假定 m1 发送到 s1,m2 发送到 s2,如果要保证 m1 先于 m2 被消费,怎么做?

在这里插入图片描述

解决方案

保证生产者 - mqserver - 消费者是一对一对一的关系

在这里插入图片描述

缺陷

消息的重复问题

7. 什么是rabbitmq

rabbitmq是一款开源的,erlang编写的,消息中间件; 最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦,可以用它来:解耦、异步、削峰。

8. rabbitmq 的使用场景

(1)服务间异步通信

(2)顺序消费

(3)定时任务

(4)请求削峰

9. rabbitmq基本概念

由exchange、queue、routingkey三个才能决定一个从exchange到queue的唯一的线路。

10. rabbitmq的工作模式

simple模式(即最简单的收发模式)

在这里插入图片描述

  1. 消息产生消息,将消息放入队列

  2. 消息的消费者(consumer) 监听 消息队列,如果队列中有消息,就消费掉,消息被拿走后,

自动从队列中删除(隐患:消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失,这里可以设置成手动的ack,但如果设置成手动ack,处理完后要及时发送ack消息给队列,否则会造成内存溢出)。

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

在这里插入图片描述

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

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

在这里插入图片描述

  1. 每个消费者监听自己的队列;

  2. 生产者将消息发给broker,由交换机将消息转发到绑定此交换机的每个队列,每个绑定交换机的队列都将接收到消息。

routing路由模式

在这里插入图片描述

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

  2. 根据业务功能定义路由字符串

  3. 从系统的代码逻辑中获取对应的功能字符串,将消息任务扔到对应的队列中。

  4. 业务场景:error 通知;exception;错误通知的功能;传统意义的错误通知;客户通知;利用key路由,可以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;

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

在这里插入图片描述

  1. 星号井号代表通配符

  2. 星号代表多个单词,井号代表一个单词

  3. 路由功能添加模糊匹配

  4. 消息产生者产生消息,把消息交给交换机

  5. 交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费

(看来就是routing查询的一种模糊匹配,就类似sql的模糊查询方式)

11. 如何保证rabbitmq消息的顺序性?

拆分多个 queue(消息队列),每个 queue(消息队列) 一个 consumer(消费者),就是多一些 queue(消息队列)而已,确实是麻烦点;或者就一个 queue (消息队列)但是对应一个 consumer(消费者),然后这个 consumer(消费者)内部用内存队列做排队,然后分发给底层不同的 worker 来处理。

12. 消息如何分发?

若该队列至少有一个消费者订阅,消息将以循环(round-robin)的方式发送给消费者。每条消息只会分发给一个订阅的消费者(前提是消费者能够正常处理消息并进行确认)。通过路由可实现多消费的功能。

13. 消息怎么路由?

消息提供方->路由->一至多个队列消息发布到交换器时,消息将拥有一个路由键(routing key),在消息创建时设定。通过队列路由键,可以把队列绑定到交换器上。消息到达交换器后, rabbitmq 会将消息的路由键与队列的路由键进行匹配(针对不同的交换器有不同的路由规则);

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

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

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

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

14. 消息基于什么传输?

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

15. 如何保证消息不被重复消费?或者说,如何保证消息消费时的幂等性?

比如:在写入消息队列的数据做唯一标示,消费消息时,根据唯一标识判断是否消费过;假设你有个系统,消费一条消息就往数据库里插入一条数据,要是你一个消息重复两次,你不就插入了两条,这数据不就错了?但是你要是消费到第二次的时候,自己判断一下是否已经消费过了,若是就直接扔了,这样不就保留了一条数据,从而保证了数据的正确性

16. 如何确保消息正确地发送至 rabbitmq? 如何确保消息接收方消费了消息?

发送方确认模式

接收方确认机制

下面罗列几种特殊情况

17. 如何保证rabbitmq消息的可靠传输?

消息不可靠的情况可能是消息丢失,劫持等原因;

丢失又分为:生产者丢失消息、消息列表丢失消息、消费者丢失消息;

  1. 生产者丢失消息

    从生产者弄丢数据这个角度来看,rabbitmq提供transaction和confirm模式来确保生产者不丢消息;transaction机制就是说:发送消息前,开启事务(channel.txselect()),然后发送消息,如果发送过程中出现什么异常,事务就会回滚(channel.txrollback()),如果发送成功则提交事务(channel.txcommit())。然而,这种方式有个缺点:吞吐量下降;

    confirm模式用的居多:一旦channel进入confirm模式,所有在该信道上发布的消息都将会被指派一个唯一的id(从1开始),一旦消息被投递到所有匹配的队列之后;rabbitmq就会发送一个ack给生产者(包含消息的唯一id),这就使得生产者知道消息已经正确到达目的队列了;

    如果rabbitmq没能处理该消息,则会发送一个nack消息给你,你可以进行重试操作。

  2. 消息队列丢数据:消息持久化。

    处理消息队列丢数据的情况,一般是开启持久化磁盘的配置。

    这个持久化配置可以和confirm机制配合使用,你可以在消息持久化磁盘后,再给生产者发送一个ack信号。

    这样,如果消息持久化磁盘之前,rabbitmq阵亡了,那么生产者收不到ack信号,生产者会自动重发。

    那么如何持久化呢?这里顺便说一下吧,其实也很容易,就下面两步

    • 将queue的持久化标识durable设置为true,则代表是一个持久的队列

    • 发送消息的时候将deliverymode=2,这样设置以后,即使rabbitmq挂了,重启后也能恢复数据

  3. 消费者丢失消息:

    消费者丢数据一般是因为采用了自动确认消息模式,改为手动确认消息即可!

    消费者在收到消息之后,处理消息之前,会自动回复rabbitmq已收到消息;如果这时处理消息失败,就会丢失该消息;

    解决方案:处理消息成功后,手动回复确认消息。

18. 为什么不应该对所有的 message 都使用持久化机制?

19. rabbitmq 的集群如何保证高可用的?

  1. 单机模式,就是 demo 级别的,一般就是你本地启动了玩玩儿的,没人生产用单机模式。

  2. 普通集群模式:

    意思就是在多台机器上启动多个 rabbitmq 实例,每个机器启动一个。

    你创建的 queue,只会放在一个 rabbitmq 实例上,但是每个实例都同步 queue 的元数据(元数据可以认为是 queue 的一些配置信息,通过元数据,可以找到 queue 所在实例)。你消费的时候,实际上如果连接到了另外一个实例,那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的,就是说让集群中多个节点来服务某个 queue 的读写操作。

  3. 镜像集群模式:

    这种模式,才是所谓的 rabbitmq 的高可用模式。跟普通集群模式不一样的是,在镜像集群模式下,你创建的 queue,无论元数据还是 queue 里的消息都会存在于多个实例上,就是说,每个 rabbitmq 节点都有这个 queue 的一个完整镜像,包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候,都会自动把消息同步到多个实例的 queue 上。rabbitmq 有很好的管理控制台,就是在后台新增一个策略,这个策略是镜像集群模式的策略,指定的时候是可以要求数据同步到所有节点的,也可以要求同步到指定数量的节点,再次创建 queue 的时候,应用这个策略,就会自动将数据同步到其他的节点上去了。

    这样的好处在于,你任何一个机器宕机了,没事儿,其它机器(节点)还包含了这个 queue的完整数据,别的 consumer 都可以到其它节点上去消费数据。坏处在于,第一,这个性能开销也太大了吧,消息需要同步到所有机器上,导致网络带宽压力和消耗很重!rabbitmq一个 queue 的数据都是放在一个节点里的,镜像集群下,也是每个节点都放这个 queue 的完整数据。

20. 如何处理消息的顺序问题?

rabbitmq通过单一的生产者和单一的消费者可以保证消息的顺序。如果需要多个消费者处理消息,则可以通过设置公平分发策略或使用“autorecknowledge”模式来保证消息的处理顺序。

21. 如何处理高并发场景下的性能问题?

rabbitmq通过提供集群功能来处理高并发场景下的性能问题。通过将多个节点组成一个集群,可以实现负载均衡和分发,提高系统的整体处理能力。同时,还可以通过调整各种参数来优化性能,如调整消息的持久化设置、调整交换机和队列的匹配规则等。

22. 如何实现消息的优先级处理?

rabbitmq支持消息的优先级处理。可以通过设置消息的优先级字段来实现,优先级高的消息会优先被消费者消费。此外,还可以通过使用优先级队列来实现更细粒度的优先级控制。

23. 如何在rabbitmq中实现延迟队列?

rabbitmq通过插件支持延迟队列的实现。延迟队列是指将消息放入队列中等待一段时间后再进行处理。要实现延迟队列,可以使用rabbitmq的插件“rabbitmq_delayed_message_exchange”,它提供了一个延迟交换器(delayed message exchange),可以将消息路由到指定的队列中等待指定的延迟时间。

24. 如何在rabbitmq中实现优先级队列?

rabbitmq通过插件支持优先级队列的实现。优先级队列是指根据消息的优先级进行排序和处理的队列。要实现优先级队列,可以使用rabbitmq的插件“rabbitmq_priority_queue”,它提供了一个优先级队列交换机(priority queue exchange),可以将具有不同优先级的消息路由到不同的队列中。

25. 如何在rabbitmq中实现死信队列?

rabbitmq通过插件支持死信队列的实现。死信队列是指当消息无法被成功消费或处理时,将其放入指定的死信队列中。要实现死信队列,可以使用rabbitmq的插件“rabbitmq_dead_letter_exchange”,它提供了一个死信交换机(dead letter exchange),可以将无法被处理的消息路由到指定的死信队列中。
itmq通过插件支持优先级队列的实现。优先级队列是指根据消息的优先级进行排序和处理的队列。要实现优先级队列,可以使用rabbitmq的插件“rabbitmq_priority_queue”,它提供了一个优先级队列交换机(priority queue exchange),可以将具有不同优先级的消息路由到不同的队列中。

点击下载《25道rabbitmq面试题含答案(很全)》

(0)
打赏 微信扫一扫 微信扫一扫

您想发表意见!!点此发布评论

推荐阅读

RabbitMQ 消息丢失的场景,如何保证消息不丢失?

07-28

RabbitMQ详解与实战(绝对足够惊喜)

07-28

【RabbitMQ】【Docker】基于docker-compose构建rabbitmq容器

07-28

rabbit启动:Error when reading /var/lib/rabbitmq/.erlang.cookie: eacces auth.erl

07-28

RabbitMQ 安装分享

07-28

Ruby langchainrb gem and custom configuration for the model setup

07-28

猜你喜欢

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论