RabbitMQ 常见面试题

导读:本篇文章讲解 RabbitMQ 常见面试题,希望对大家有帮助,欢迎收藏,转发!站点地址:www.bmabk.com

RabbitMQ 常见面试题

1.为什么要用消息队列? (消息队列的应用场景?)
2.各种消息队列产品的比较?
3.消息队列的优点和缺点?
4.如何保证消息队列的高可用?
5.如何保证消息不丢失?
6.如何保证消息不被重复消费?(如何保证消息消费的幂等性)
7.如何保证消息消费的顺序性?
8.大量消息堆积处理怎么处理?
9.消息过期怎么处理?

1.为什么要用消息队列? (消息队列的应用场景?)

面试官心里分析

考察面试者是否知道为什么要用消息队列?
消息队列在项目中解决的是什么样的问题?

消息队列的本质

  • 消息队列一种“先进先出”的数据结构

    在这里插入图片描述

  • 常见应用场景:解耦、异步、削峰

解耦
系统的耦合性越高,容错性就越低。以电商应用为例,用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出了故障或者因为升级等原因暂时不可用,都会造成下单操作异常,影响用户使用体验。

在这里插入图片描述

使用消息队列解耦合,系统的耦合性就会提高了。比如物流系统发生故障,需要几分钟才能修复,在这段时间内,物流系统要处理的数据被缓存到消息队列中,用户的下单操作正常完成。当物流系统恢复后,补充处理存在消息队列中的订单消息即可,终端系统给感知不到物流系统发生过几分钟故障

在这里插入图片描述

异步
A系统接收一个请求,需要在自己本地写库,还需要在B、C、D三个系统写库,自己本地写库要3ms,B、C、D三个系统分别写库要300ms、450ms、200ms。最终请求总时是3 + 300 + 450 + 200 = 953ms,接近1s,用户非常不好,一般互联网类的企业,对于用户直接的操作,一般要求是每个请求必须在200ms内完成,对用户几乎是无感知的,如果用户通过浏览器发起请求,等待个1s,这几乎是不可接受的。

在这里插入图片描述

如果使用MQ,那么A系统连续发送3条消息到MQ队列中,假如耗时5ms,A系统从接收一个请求到返回响应给用户,总时长是3 + 5 = 8ms,对于用户而言,相应速度大大提升了,改善了用户的体验

在这里插入图片描述

流量削峰

应用系统如果遇到系统请求流量的瞬间猛增,有可能会将系统压垮。有了消息队列可以将大量请求缓存起来,分散到很长一段时间处理,这样可以大大提到系统的稳定性和用户体验。

在这里插入图片描述

一般情况,为了保证系统的稳定性,如果系统负载超过阈值,就会阻止用户请求。这会影响用户体验,而如果使用消息队列将请求缓存起来,等待系统处理完毕后通知用户下单完毕,这样比不能下单体验要好。

在这里插入图片描述

流量削峰的经济考量

业务系统正常时段的QPS如果是1000,流量最高峰是10000,为了应对流量高峰配置高性能的服务器显然不划算,这时可以使用消息队列对峰值流量削峰。

小结

为什么要用消息队列

  • 解耦
  • 异步
  • 削峰

2.各种消息队列产品的比较?

面试官心里分析

考察面试者是否对市面上的MQ产品做过调研?
在选择MQ时是否根据不同MQ的产品特点做过对比和取舍?

几种MQ的对比

在这里插入图片描述

小结

  • ActiveMQ,早期使用的较多,没经过大规模吞吐量场景的验证,社区也不是很活跃,但是现在确实大家用的不多了,不推荐
  • RabbitMQ,开发语言erlang阻止了大量的Java工程师去深入研究和掌控它,对公司而言,几乎处于不可控状态,但是RabbitMQ是开源的,比较稳定的支持,活跃度也高,如不考虑二次开发,最求性能和稳定性,推荐使用。
  • RocketMQ,开发语言是Java,在阿里内部经受过高并发业务的考验,稳定性和性能均不错,考虑后期可能二次开发,推荐使用。
  • Kafka,大数据领域的实时计算,日志采集等场景,用Kafka是业内标准的,社区活跃度很高,推荐使用。大数据领域日志采集等业务推荐使用。

3.消息队列的优点和缺点?

面试官心里分析

考察面试者在项目中引入一个新的技术后,是否思考过该技术对项目带来的有点和弊端,而不仅仅是停留在机械的使用。

优点:

  • 解耦
  • 异步
  • 削峰

缺点:

  • 系统可用性降低
  • 系统复杂度提高
  • 一致性问题

系统可用性降低

系统引入的外部依赖越多,系统稳定性越差。一旦MQ宕机,就会对业务造成影响。

Q:

​ 如何保证MQ的高可用?

系统复杂度提高

MQ的加入大大增加了系统的复杂度,以前系统间是同步的远程调用,现在是通过MQ进行异步调用。

Q:

  • 消息丢失怎么办
  • 重复消息怎么处理
  • 如何保证消息传递的顺序性?

一致性问题

A系统处理完业务,通过MQ给B、C、D三个系统发消息数据,如果B系统、C系统处理成功,D系统处理失败。

Q:

​ 如何保证消息数据处理的一致性?

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

面试官心里分析

项目引入了MQ导致系统的可用性降低,面试官想知道的是面试者针对可用性较低问题的思考和解决思路。
回答此问题时,面试者只需针对自己使用过的一两个MQ产品的高可用方案回答即可。

RabbitMQ高可用-普通集群

  1. 在多台机器上分别启动RabbitMQ实例。

  2. 多个实例之间可以相互通信。

  3. 创建的Queue只会放在一个RabbitMQ上,其他实例都同步元数据

  4. 消费的时候,如果连接的没有Queue,那么当前实例会从queue所在实例拉取数据。

特点:

  1. 没有真正做到高可用
  2. 有数据拉取的开销和单实例的瓶颈问题

在这里插入图片描述

RabbitMQ高可用-镜像集群

  1. 在多台机器上分别启动RabbitMQ实例。
  2. 多个实例之间可以相互通信
  3. 每次生产者写消息到queue的时候,都会自动把消息同步到多个实例的queue上。每个RabbitMQ节点上都有Queue的消息数据和元数据。
  4. 某一个节点宕机,其他节点依然保存完整数据,不影响客户端消费
    在这里插入图片描述

RocketMQ 高可用-双主双从

  1. 生产者通过NameServer发现Broker
  2. 生产者发送队列消息到2个Broker主节点
  3. Broker主节点分别和各自从节点同步数据
  4. 消费者从主或从节点订阅消息

RabbitMQ 常见面试题

小结

MQ的高可用如何保证?

  • RabbitMQ : 镜像集群
  • RocketMQ: 双主双从

5.如何保证消息不丢失?

面试官心里分析

  1. 考察面试者是否清楚消息丢失的原因?
  2. 如何保证消息不丢失?

消息丢失的原因

情况一:消息生产者没有成功发送到MQ Broker
情况二:消息发送给MQ Broker后,Broker宕机导致内存中的消息数据丢失
情况三:消费者消费到了消息,但是没有处理完毕就出现异常导致丢失。

在这里插入图片描述

确保消息不丢失方案

  1. 消息发送者发送给MQ Broker后,MQ Broker给生产者确认收到
  2. MQ收到消息后进行消息持久化
  3. 消费者收到消息处理完毕后手动进行ack确认
  4. MQ收到消费者ack确认后删除持久化的消息

在这里插入图片描述

小结

  • 消息丢失的原因:
    发送方、MQ、消费方都有可能导致消息丢失
  • 如何保证消息不丢失
    1. 发送方可靠发送
    2. MQ进行消息持久化
    3. 消费方消费完毕进行ACK确认,MQ收到消费方的ACK确认再删除本地消息

6.如何保证消息不被重复消费?(如何保证消息消费的幂等性)

面试官心里分析

消息的重复消费和保证幂等性会经常被连着问,当出现了重复消息后,为了保证系统数据的正常性,就必须要保证幂等性。针对该问题,面试官实际想要考察的是:

  1. 面试者对重复消息产生的原因的思考
  2. 面试者对保证消息幂等性的方案

重复消息产生的原因

消息重复的根本原因是网络不可达

  • 发送时消息重复

当一条消息已被成功发送到服务端,此时出现了网络闪断,导致服务端对客户端应答失败。如果此时生产者意识到消息发送失败并尝试再次发送消息,消费者后续会收到两条内容相容的消息

在这里插入图片描述

  • 消费时消息重复

消息消费的场景下,消息已投递到消费者并完成业务处理,当消费方给MQ服务端反馈应答的时候网络闪断。为了保证消息至少消费一次,MQ服务端将在网络恢复后再次尝试投递之前已被消费方处理过的消息,此时消费者就会收到两条内容相同的消息

在这里插入图片描述

消息幂等性

  1. 消息发送者发送消息时携带一个全局唯一的消息id
  2. 消费者获取消费后先根据id在redis/db中查询是否存在消费记录
  3. 如果没有消费过就正常消费,消费完毕后写入redis/db
  4. 如果消息消费过就直接舍弃

小结

  • MQ消息的重复问题和幂等性保证?
    1. 消息重复原因
      • 网络不可达,不可避免
    2. 幂等性
      • 消息携带全局ID,消费方接到消息时先查在处理,根据全局ID判断如果是重复消息直接丢弃

7.如何保证消息消费的顺序性?

面试官心理分析

  1. 考察消费者是否理解什么是消息顺序消费?
  2. 考察消费者是否思考过确保消息顺序消费的方案?

消息的顺序性消费

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

例如:一笔订单产生了3条消息。分别是订单创建、订单付款、订单完成。

消费时,要按照顺序依次消费才有意义。
与此同时多笔订单之间又是可以并行消费的。

模型一:M1、M2按照先后顺序发送到2台Server,被2个消费者分别消费

  1. 不能保证消息的顺序到达MQ
  2. 不能保证消息的顺序消费

不能保证

在这里插入图片描述

模型二:M1、M2按照先后顺序发送到1台Servier,被2个消费者分别消费

  1. 可以保证消息的顺序到达MQ。
  2. 消费方如果出现网络延迟问题,不能严格保证消息的顺序消费。

不能保证

在这里插入图片描述

模型三:M1、M2按照先后顺序发送到1台Server,被2个消费者分别消费

  1. 可以保证消息的顺序到达MQ。
  2. M1消费完毕并成功应答后,MQServer在发送M2

实现复杂,不推荐

在这里插入图片描述

模型四:生产者:MQ Server:消费者=1:1:1

  1. 可以保证消息顺序到达MQ
  2. 可以保证消息顺序消费

全局的顺序消费不常见!

  1. 吞吐量下降
  2. 容错性降低

在这里插入图片描述

模型五:局部顺序消费

  1. 生产者根据消息ID将同一组消息发送到一个Queue中。
  2. 多个消费者同时获取Queue中的消息进行消费。
  3. MQ使用分段锁保证单个Queue中的有序消费

在这里插入图片描述

小结

  • 什么是消息的顺序消费?

    1. 消费方按照消息发送的顺序进行消费,分为全局顺序消息和局部顺序消息
    2. 常见的是局部顺序消息
  • 如何保证消息的顺序消费?

    1. 全局顺序消息,生产者:MQ:消费者 = 1:1:1

    2. 局部顺序消息:

      2.1 生产者将同一组消息发送到单个队列

      2.2 多个消费者并行对消息进行消费

      2.3 Queue通过分段锁保证消息消费的顺序性

8.大量消息堆积处理怎么处理?

面试官心理分析

1.考察面试者是否清楚消息堆积的原因?

2.针对消息堆积如何进行处理?

消息堆积的原因

消费方出现了故障导致消息没有正常消费:

  1. 网络故障
  2. 消费方处理消息后没有给MQ Server正常应答

在这里插入图片描述

消息堆积的处理方案

  1. 检查并修复消费方的正常消费速度
  2. 将堆积消息转存到容量更大的MQ集群
  3. 增加多个消费者节点并行消费堆积消息
  4. 消费完毕后,恢复原始架构

在这里插入图片描述

小结

  • 消息堆积的原因?
    1. 消费方消费出现故障
  • 如何处理堆积消息?
    1. 将堆积消息分发到更大容量的MQ集群
    2. 增加消费方节点并行消费

9.消息过期怎么处理?

面试官心里分析

  1. 考察面试者是否知道消息为什么会过期?
  2. 针对过期消息如何处理?

消息过期的原因

消息设置了过期时间,如果超时还未被消费,则视为消息过期。

过期消息可以转存到死信队列

在这里插入图片描述

消息过期的处理方案

  1. 过期消息进入到死信队列
  2. 启动专门的消费者消费死信队列消息,并写入到数据库记录日志
  3. 查询数据库消息日志,重新发送消息到MQ

在这里插入图片描述

小结

  • 过期消息产生的原因?
    1. 消息设置了过期时间
    2. 消费方消费出现故障,导致消息一直未被处理,消息就会过期
  • 如何处理过期消息?
    1. 设置死信队列,接受过期消息
    2. 消费死信队列中的过期消息,记录日志
    3. 此后查询过期消息发送到MQ

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

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/78236.html

(0)
小半的头像小半

相关推荐

极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!