前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >2022年Java秋招面试求职必看的RabbitMQ面试题

2022年Java秋招面试求职必看的RabbitMQ面试题

原创
作者头像
Java程序猿
修改于 2022-07-13 13:56:56
修改于 2022-07-13 13:56:56
7870
举报
文章被收录于专栏:Java核心技术Java核心技术

前言

RabbitMQ是一个消息中间件:它接受并转发消息。你可以把它当做一个快递站点,当你要发送一个包裹时,你把你的包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这种逻辑RabbitMQ是一个快递站,一个快递员帮你传递快件。RabbitMQ与快递站的主要区别在于,它不处理快件而是接收,存储和转发消息数据。

小编分享的这份2022年Java秋招备战面试题总计有1000多道面试题,包含了MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、RedisMySQLJava 并发编程、Java基础、Spring、微服务、LinuxSpring Boot 、Spring Cloud、RabbitMQ、kafka等16个专题技术点,都是小编在今年金三银四总结出来的面试真题,已经有很多粉丝靠这份PDF拿下众多大厂的offer,今天在这里总结分享给到大家!【已完结】

1、什么是rabbitmq

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

2、为什么要使用rabbitmq

  • 在分布式系统下具备异步,削峰,负载均衡等一系列高级功能;
  • 拥有持久化的机制,进程消息,队列中的信息也可以保存下来。
  • 实现消费者和生产者之间的解耦。
  • 对于高并发场景下,利用消息队列可以使得同步访问变为串行访问达到一定量的限流,利于数据库的操作。
  • 可以使用消息队列达到异步下单的效果,排队中,后台进行逻辑下单。

3、使用rabbitmq的场景

  • 服务间异步通信
  • 顺序消费
  • 定时任务
  • 请求削峰

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

发送方确认模式

将信道设置成 confirm 模式(发送方确认模式),则所有在信道上发布的消息都会被指派一个唯一的 ID。 一旦消息被投递到目的队列后,或者消息被写入磁盘后(可持久化的消息),信道会发送一个确认给生产者(包含消息唯一 ID)。

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

接收方确认机制

接收方消息确认机制

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

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

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

6、消息基于什么传输?

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

7、消息如何分发?

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

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

8、消息怎么路由?

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

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

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

消息到达交换器后,RabbitMQ 会将消息的路由键与队列的路由键进行匹配(针对不同的交换器有不同的路由规则);

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

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

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

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

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

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

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

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

10、使用RabbitMQ有什么好处?

  • 服务间高度解耦
  • 异步通信性能高
  • 流量削峰

11、RabbitMQ的集群

镜像集群模式

你创建的 queue,无论元数据还是 queue 里的消息都会存在于多个实例上,然后每次你写消息到 queue 的时候,都会自动把消息到多个实例的 queue 里进行消息同步。

好处在于,你任何一个机器宕机了,没事儿,别的机器都可以用。坏处在于,第一,这个性能开销也太大了吧,消息同步所有机器,导致网络带宽压力和消耗很重!第二,这么玩儿,就没有扩展性可言了,如果某个 queue 负载很重,你加机器,新增的机器也包含了这个 queue 的所有数据,并没有办法线性扩展你的 queue

12、mq的缺点

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
【韧性架构设计】分布式系统的韧性
由许多协同工作的微服务组成的云原生应用程序架构形成了一个分布式系统。确保分布式系统可用——减少其停机时间——需要提高系统的弹性。弹性是使用提高可用性的策略。弹性策略的示例包括负载平衡、超时和自动重试、截止日期和断路器。
架构师研究会
2022/07/29
5030
【韧性架构设计】分布式系统的韧性
【韧性设计】韧性设计模式:重试、回退、超时、断路器
软件本身并不是目的:它支持您的业务流程并使客户满意。如果软件没有在生产中运行,它就无法产生价值。然而,生产性软件也必须是正确的、可靠的和可用的。
架构师研究会
2022/05/25
1.4K0
【韧性设计】韧性设计模式:重试、回退、超时、断路器
分布式系统的弹性设计
在讨论分布式系统的弹性之前,让我们快速回顾一些基本术语: 弹性Resiliency:任何系统从困难中恢复的能力,(banq注:弹性也就是适应能力)。 分布式系统:一些网络组件通过传递消息来完成一个共同目标。 可用性:任何系统在任何时间点保持正常运行的可能性。 故障与故障:故障Fault是您的系统中是不正确的内部状态。系统中一些常见的故障例子包括: 1.存储层缓慢 2.应用程序中的内存泄露 3.被阻塞的线程 4.依赖性故障 5.在系统中传播坏数据(通常是因为输入数据没有足够的验证) 失败Failure是系统无法执行其预期工作。 失败意味着系统正常运行时间和可用性的损失。故障如果不被封装,会导致在系统中传播,从而导致失败。 当故障Fault转为失败Failure时就意味着系统发生了故障: 弹性就是为了防止故障Fault转化为失败Failure 我们为什么关心系统的弹性? 系统的弹性与其正常运行时间和可用性成正比。系统越有弹性,服务用户的可用性越高。 如果不具有弹性能力,可能会以多种方式影响公司各个方面。 分布式系统的弹性设计很难 我们都明白'可用'至关重要。为了保证可用性,我们需要从零开始建立弹性,以便我们系统中的故障自动恢复。 但是在具有多个分布式系统的复杂微服务架构中建立弹性是很困难的。这些困难是: 1.网络不可靠 2.依赖性总是失败 3.用户行为是不可预测的 虽然构建弹性很难,但并非不可能。遵循一些构建分布式系统的模式可以帮助我们在整个服务中实现较高的正常运行时间。我们将讨论未来的一些模式: 模式[0] = nocode
lyb-geek
2018/09/27
2K0
分布式系统的弹性设计
[微服务架构 ]微服务集成中的3个常见缺陷 - 以及如何避免它们
微服务风靡一时。 他们有一个有趣的价值主张,即在与多个软件开发团队共同开发的同时,将软件快速推向市场。 因此,微服务是在扩展您的开发力量的同时保持高敏捷性和快速的开发速度。
架构师研究会
2019/05/06
1.2K0
[微服务架构 ]微服务集成中的3个常见缺陷 - 以及如何避免它们
【韧性架构】让你的微服务容错的 5 种模式
在本文中,我将介绍微服务中的容错以及如何实现它。如果你在维基百科上查找它,你会发现以下定义:
架构师研究会
2022/06/08
1K0
【韧性架构】让你的微服务容错的 5 种模式
【微服务架构】为故障设计微服务架构
微服务架构可以通过定义明确的服务边界隔离故障。但就像在每个分布式系统中一样,网络、硬件或应用程序级别问题的可能性更高。由于服务依赖关系,任何组件都可能对其消费者暂时不可用。为了最大限度地减少部分中断的影响,我们需要构建可以优雅地响应某些类型的中断的容错服务。
架构师研究会
2022/05/25
5110
【微服务架构】为故障设计微服务架构
【软件架构】支持大规模系统的设计模式和原则
今天,即使是小型初创公司也可能不得不处理数 TB 的数据或构建支持每分钟(甚至一秒钟!)数十万个事件的服务。所谓“规模”,通常是指系统应在短时间内处理的大量请求/数据/事件。
架构师研究会
2022/05/05
6150
【软件架构】支持大规模系统的设计模式和原则
故障驱动的微服务架构设计
此文背景: 之所以发布此文,是有一个直接的原因,就是我们之前在线上遇到了一个使用timeout来判断是否失败的案例,这是真实的,结果就是效果很不好。看了本文中介绍的各种技术和架构模式,让我忽然对之前的这个案例有了一个新的认识,就是“快速失败”不应该依赖于传统的比如timeout这种超时机制来进行,也许使用本文中介绍到的技术(比如:Circuit Breakers)要更加地可靠和受控。 目录 微服务架构的风险 优雅的服务降级 变更管理 健康检查和负载平衡 自愈(Self-healing) 故障转移缓存
ImportSource
2018/04/03
1.4K0
故障驱动的微服务架构设计
深入微服务核心:从架构设计到规模化
《Building Microservices》这本书是吃透微服务的大部头,本文基于全书内容,系统性地阐述了微服务架构的设计原则、实施策略与挑战,从微服务的核心概念出发,延伸到架构设计、服务拆分、集成技术及规模化实践,为开发者提供了构建稳健微服务体系的指导框架。
腾讯云开发者
2025/04/24
2990
深入微服务核心:从架构设计到规模化
业务开发:防御性编程之网络超时与重试机制、幂等机制的关系
网络超时的情况可以分为服务端超时和客户端超时。当api请求超时,客户端并不知道服务端是否成功处理请求,即网络请求超时,服务端业务执行结果可能是成功,也可能是失败。
崔认知
2023/06/19
3930
业务开发:防御性编程之网络超时与重试机制、幂等机制的关系
微服务架构中10个常用的设计模式
从软件开发早期(1960 年代)开始,应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性,软件工程师和架构师们做了许多尝试:David Parnas 的模块化和封装 (1972), Edsger W. Dijkstra (1974)的关注点分离以及 SOA(1988)。
架构之家
2022/07/12
9740
微服务架构中10个常用的设计模式
与我一起学习微服务架构设计模式3—微服务架构中的进程间通信
选择合适的进程间通信机制是一个重要的架构决策,它会影响应用的可用性,甚至与事务管理相互影响。
java达人
2019/10/23
1.9K0
万字详解高可用架构设计
系统高可用是一个宏大的命题,从设计思想、架构原则到工程能力、服务管理等等方方面面,每个视角单拆出来都不是一篇文章可以解决的。本文将从大局上全面系统地梳理高可用系统架构,起到一个提纲挈领的作用。
腾讯云开发者
2025/01/07
2.3K0
万字详解高可用架构设计
构建故障恢复系统
作者 | Gandharv Srivastava 译者 | Sambodhi 策划 | marsxxl 1.5 亿,这个数字,是 Capillary 的 Engage+ 产品在新年高峰时段两小时内发送的通信量。即便是这样的小故障,也会影响到我们客户的资本和我们产品的信誉。 故障就像一场大爆炸,它们可以是手榴弹的爆炸,也可以是核弹级别的爆炸,而爆炸造成的破坏取决于爆炸半径。再好的系统,也会有出故障的一天。若不及早发现并加以处置,也会加剧造成更大的破坏。 请注意,这篇文章将着重于微服务设计中的健壮性和
深度学习与Python
2023/03/29
9090
构建故障恢复系统
微服务架构如何避免大规模故障?
点击关注公众号,Java干货及时送达 微服务架构通过一种良好的服务边界划分,能够有效地进行故障隔离。但就像其他分布式系统一样,在网络、硬件或者应用级别上容易出现问题的机率会更高。服务的依赖关系,导致在任何组件暂时不可用的情况下,就它们的消费者而言都是可以接受的。为了能够降低部分服务中断所带来的影响,我们需要构建一个容错服务,来优雅地应对特定类型的服务中断。 本文基于一些在RisingStack的顾问咨询与开发经验,介绍了如何运用一些最常用的技术和架构模型,去构建与维护一个高可用的微服务系统。 如果你不熟
Java技术栈
2022/03/03
4130
设计一个容错的微服务架构
本文介绍了构建和操作高可用性微服务系统的最常见技术和架构模式。如果你不熟悉本文中的模式,那并不一定意味着你做错了。系统设计没有通用解决方案,建立可靠的系统总是会带来额外的成本。
Superbeet
2020/04/17
7170
微服务架构及其最重要的10个设计模式
微服务架构,独享数据库、事件驱动、CQRS、Saga、BFF、API 网关、Strangler、断路器、外部化配置、消费端驱动的契约测试
深度学习与Python
2021/01/06
1.3K0
构建容错软件系统的艺术
我们生活在一个由软件系统驱动的世界。它们已融入我们的日常生活,其持续、可靠的性能不再是奢侈品,而是必需品。企业现在比以往任何时候都更需要确保其系统保持可用性、可靠性和弹性。这种必要性是由满足客户和超越竞争对手的愿望推动的。实现这一目标的秘诀是什么?构建容错软件系统。
用户5166556
2023/10/19
2640
构建容错软件系统的艺术
Istio如何同时实现Hytrix|Ribbon|Zuul|微服务安全的功能?:为微服务引入Istio服务网格(下)
版权说明:本文由高晓雪参照如下文档翻译。魏新宇根据高晓雪的翻译文档,做了适当的注解和文字矫正。 https://developers.redhat.com/download-manager/file/istio_mesh_for_microservices_r1.pdf 本文适合对istio的读者提供泛读参考,对istio理解较深的读者,建议直接阅读英文原文。本系列分上下两篇:上篇为1-3章内容,下篇为4-7章内容。 目录 为微服务引入Istio服务网格 1.介绍 1.1.更快的挑战 1.2.认识I
魏新宇
2018/06/25
2.2K0
重试暂时性故障处理设计-常用的架构设计原则
与远程服务和资源通信的所有应用程序必须对暂时性故障敏感。 对于云中运行的应用程序尤其如此,因为其环境的性质与通过 Internet 建立连接的特点,意味着更容易遇到这种类型的故障。 暂时性故障包括组件和服务瞬间断开网络连接、服务暂时不可用,或者当服务繁忙时出现超时。 这些故障通常可自我纠正,如果在适当的延迟后重复操作,则可能会成功。
jack.yang
2025/04/05
1050
推荐阅读
相关推荐
【韧性架构设计】分布式系统的韧性
更多 >
目录
  • 前言
    • 1、什么是rabbitmq
    • 2、为什么要使用rabbitmq
    • 3、使用rabbitmq的场景
    • 4、如何确保消息正确地发送至RabbitMQ? 如何确保消息接收方消费了消息?
    • 5.如何避免消息重复投递或重复消费?
    • 6、消息基于什么传输?
    • 7、消息如何分发?
    • 8、消息怎么路由?
    • 9、如何确保消息不丢失?
    • 10、使用RabbitMQ有什么好处?
    • 11、RabbitMQ的集群
    • 12、mq的缺点
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档