MQ全称为Message Queue-消息队列,是一种应用程序对应用程序的消息通信,一端只管往队列不断发布信息,另一端只管往队列中读取消息,发布者不需要关心读取消息的谁,读取消息者不需要关心发布消息的是谁,各干各的互不干扰。
如果你的MQ消息要从Kafka切换到RocketMQ且不停机,怎么做?在让这个MQ消息调用第三方发奖接口,但无幂等字段又怎么处理?今天小傅哥就给大家分享一个关于MQ消息在这样的场景中的处理手段。
面试官:继上次聊的MQ的问题,想再问问有了解过MQ如何保证其高可用性吗?这个可以简单聊聊吗
一、缘起 如《消息总线消息必达》所述,MQ消息必达,架构上有两个核心设计点: (1)消息落地 (2)消息超时、重传、确认 再次回顾消息总线核心架构,它由发送端、服务端、固化存储、接收端四大部分组成。
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
最近mq越来越火,很多公司在用,很多人在用,其重要性不言而喻。但是如果我让你回答下面的这些问题:
消息重复和幂等问题是很常见的问题,这俩问题基本可以放在一起。 既然是消费消息,那肯定要考虑考虑会不会重复消费?能不能避免重复消费?或者重复消费了也别造成系统异常可以吗?这个是MQ领域的基本问题,其实本质上还是问你使用消息队列如何保证幂等性,这个是你架构里要考虑的一个问题即实际生产上的系统设计问题。
因为业务逻辑从同步代码中移除,所以也要有相应队列处理程序处理消息、执行业务逻辑。随着业务逻辑复杂,会引入更多外部系统和服务,就会越来越多使用MQ,与外部系统解耦合以及提升系统性能。
但MQ在实际应用中不是说保证消息不丢失就万无一失了,它还有两个令人头疼的问题:重复消费和乱序。
关于CAP,BASE理论,以及TCC,seata解决方案,可以参考我上一篇博客.《Java分布式事务-seata,tcc解决方案总结》 本文是接着一篇继续的。
【1】MQ:MessageQueue,消息队列。 队列,是一种FIFO 先进先出的数据结构。消息由生产者发送到MQ进行排队,然后按原来的顺序交由消息的消费者进行处理。QQ和微信就是典型的MQ。
首先我们来看一下消息的传输流程。消息生产者–>MQ–>消息消费者;消息生产者发送消息到MQ服务器,MQ服务器存储消息,消息消费者监听MQ的消息,发现有消息就消费消息。
看这样的业务场景,A系统发送数据到 B、C、D 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如果C系统现在不需要了呢?A系统负责人几乎崩溃......
Kafka 消息框架,大家一定不陌生,很多人工作中都有接触。它的核心思路,通过一个高性能的MQ服务来连接生产和消费两个系统,达到系统间的解耦,有很强的扩展性。
Broker:接收和分发消息的应用,RabbitMQ Server 就是 Message Broker
消息最多传递一次,如果当时客户端不可用,则会丢失该消息。即消息在传递时,最多被送达一次。无消息可靠性保证,允许丢消息。
本栏目Java开发岗高频面试题主要出自以下各技术栈:Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。
之前已经出过MQ系列相关的对线面试官,为方便小伙伴们能够通篇阅读更加方便,此篇文章均出自对线面试官系列。往期文章参考:
对系统增加MQ对峰值写流量做削峰填谷,对次要业务逻辑做异步,对不同系统模块做解耦。 因为业务逻辑从同步代码中移除了,所以也要有相应队列处理程序处理消息、执行业务逻辑。
在注册流程中,数据写DB是主流程,但注册后给用户发优惠券或欢迎短信是分支流程,时效性也不强。
最近这年头,面试找工作不问点中间件相关知识好像说不过去,而面试考察最多的中间件就是缓存数据库Redis和消息中间件MQ。
消息队列(MQ)在现代分布式系统中扮演着至关重要的角色,它们用于解耦系统组件、提高可伸缩性和确保数据可靠传输。然而,MQ 中的消息可能会出现重复消费的情况,这可能会导致不期望的结果。在本文中,我们将深入探讨MQ中的重复消费问题,并介绍如何避免它以及如何实现幂等性来确保数据的正确性。
看这么个场景。A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃......
消息队列(Message Queue,简称MQ),其主要用于在复杂的微服务系统中进行消息通信,它的优点可以大致整理成以下几点:
A 系统产生了一个比较关键的数据,很多系统需要 A 系统将数据发过来,强耦合(B,C,D,E 系统可能参数不一样、一会需要一会不需要数据,A 系统要不断修改代码维护)
面试官在面试候选人时,如果发现候选人的简历中写了在项目中使用了 MQ 技术(如Kafka、RabbitMQ、RocketMQ),基本都会抛出一个问题:在使用 MQ的时候,怎么确保消息 100% 不丢失?
其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么?
如果需要和新的系统建立通信或删除已建立的通信,都需要修改代码,这种方案显然耦合度很高。
为什么使用消息队列?消息队列的优点和缺点?kafka、activemq、rabbitmq、rocketmq都有什么优缺点?
为什么使用消息队列啊?消息队列有什么优点和缺点啊?kafka、activemq、rabbitmq、rocketmq都有什么区别以及适合哪些场景?
MQ是面试中比较高频的问题,面试官在面试候选人时,如果发现候选人的简历中写了在项目中使用了 MQ 技术(如 Kafka、RabbitMQ、RocketMQ)。通常面试官会给他抛出一个问题:
其实这里要讲的就是使用MQ的好处,MQ的的使用场景有很多,但是比较核心的有3个:解耦、异步、削峰
引入 MQ 消息中间件最直接的目的是:做系统解耦合流量控制,追其根源还是为了解决互联网系统的高可用和高性能问题。
文章来源:blog.csdn.net/gu131007416553/article/details/120934738
1.保证消息传递与一致性 1.1生产者确保消息自主性 当生产者发送一条消息时,它必须完成他的所有业务操作。 如下图: 这保证消费者接受到消息时,生产者已处理完毕相关业务,也就是1PC的基础。 1.2
我之前写过一篇关于 rocketMQ 实现分布式锁的文章,主要介绍如何使用 RocketMQ 实现分布式锁,
为了便于大家查找问题,了解全貌,整理个目录,我们可以快速全局了解关于消息队列,面试官一般会问哪些问题。
为什么会出现消息重复?消息重复的原因有两个:1.生产时消息重复,2.消费时消息重复。
优秀的项目都由同步、异步和定时任务三种处理模式相辅相成。其中当属异步编程充满坑点。
参考 B站视频 PPT 参考文章 为什么要使用消息队列 主要考察应用场景及优缺点 优点 解耦: 不同服务间的调用 异步:不同系统间的调用 消峰:秒杀等场景,平时量不高,但在特定时间会有大量请求的情况,配置基础服务器资源,并引入MQ平滑处理请求,亦节约了成本。 缺点 可用性降低: 依赖于MQ,若MQ异常,将导致业务异常甚至系统崩溃 复杂度提高:需要考虑消息丢失,重复消费等问题 一致性问题:多个队列同时操作,部分消费失败的问题,异步的处理返回给用户是成功 消息队列产品比较 如何根据特点进行取舍
因此主流MQ其实都提供了可靠性投递机制,确保即使网络异常,消息也能可靠传递,而不会丢失。
点击关注公众号,Java干货及时送达 作者:美得让人心动 来源:blog.csdn.net/gu131007416553/article/details/120934738 面试官在面试候选人时,如果发现候选人的简历中写了在项目中使用了 MQ 技术(如 Kafka、RabbitMQ、RocketMQ),基本都会抛出一个问题:在使用 MQ 的时候,怎么确保消息 100% 不丢失? 这个问题在实际工作中很常见,既能考察候选者对于 MQ 中间件技术的掌握程度,又能很好地区分候选人的能力水平。接下来,我们就从这个
领取专属 10元无门槛券
手把手带您无忧上云