投稿
  1. 极客之音首页
  2. 技术随笔

RabbitMQ 常见面试题

小半 • • 技术随笔 • 阅读 517

导读：本篇文章讲解 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)
小半的头像小半
0 0

相关推荐

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