消息队列的使用场景及优缺点?

(1)为什么使用消息队列啊?

其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么

面试官问你这个问题,期望的一个回答是说,你们公司有个什么业务场景,这个业务场景有个什么技术挑战,如果不用MQ可能会很麻烦,但是你现在用了MQ之后带给了你很多的好处

先说一下消息队列的常见使用场景吧,其实场景有很多,但是比较核心的有3个:解耦、异步、削峰

解耦:现场画个图来说明一下,

A系统发送个数据到BCD三个系统,接口调用发送,那如果E系统也要这个数据呢?那如果C系统现在不需要了呢?现在A系统又要发送第二种数据了呢?A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿,A系统要时时刻刻考虑BCDE四个系统如果挂了咋办?我要不要重发?我要不要把消息存起来?头发都白了啊。。。

面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用MQ给他异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个MQ去进行系统的解耦。在简历中体现出来这块东西,用MQ作解耦。

异步:现场画个图来说明一下,

A系统接收一个请求,需要在自己本地写库,还需要在BCD三个系统写库,自己本地写库要3ms,BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms,接近1s,用户感觉搞个什么东西,慢死了慢死了。

削峰:每天0点到11点,A系统风平浪静,每秒并发请求数量就100个。结果每次一到11点~1点,每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊。。。尴尬了,系统会死。。。

(2)消息队列有什么优点和缺点啊?

优点上面已经说了,就是在特殊场景下有其对应的好处,解耦、异步、削峰

缺点呢?显而易见的

系统可用性降低:系统引入的外部依赖越多,越容易挂掉,本来你就是A系统调用BCD三个系统的接口就好了,人ABCD四个系统好好的,没啥问题,你偏加个MQ进来,万一MQ挂了咋整?MQ挂了,整套系统崩溃了,你不就完了么。

系统复杂性提高:硬生生加个MQ进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已

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

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

(3)kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点啊?

常见的MQ其实就这几种,别的还有很多其他MQ,但是比较冷门的,那么就别多说了

作为一个码农,你起码得知道各种mq的优点和缺点吧,咱们来画个表格看看


特性


ActiveMQ


RabbitMQ


RocketMQ


Kafka


单机吞吐量


万级,吞吐量比RocketMQ和Kafka要低了一个数量级


万级,吞吐量比RocketMQ和Kafka要低了一个数量级


10万级,RocketMQ也是可以支撑高吞吐的一种MQ


10万级别,这是kafka最大的优点,就是吞吐量高。

一般配合大数据类的系统来进行实时数据计算、日志采集等场景


topic数量对吞吐量的影响


topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降

这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topic


topic从几十个到几百个的时候,吞吐量会大幅度下降

所以在同等机器下,kafka尽量保证topic数量不要过多。如果要支撑大规模topic,需要增加更多的机器资源


时效性


ms级


微秒级,这是rabbitmq的一大特点,延迟是最低的


ms级


延迟在ms级以内


可用性


高,基于主从架构实现高可用性


高,基于主从架构实现高可用性


非常高,分布式架构


非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用


消息可靠性


有较低的概率丢失数据


经过参数优化配置,可以做到0丢失


经过参数优化配置,消息可以做到0丢失


功能支持


MQ领域的功能极其完备


基于erlang开发,所以并发能力很强,性能极其好,延时很低


MQ功能较为完善,还是分布式的,扩展性好


功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准


优劣势总结


非常成熟,功能强大,在业内大量的公司以及项目中都有应用

偶尔会有较低概率丢失消息

而且现在社区以及国内应用都越来越少,官方社区现在对ActiveMQ 5.x维护越来越少,几个月才发布一个版本

而且确实主要是基于解耦和异步来用的,较少在大规模吞吐的场景中使用


erlang语言开发,性能极其好,延时很低;

吞吐量到万级,MQ功能比较完备

而且开源提供的管理界面非常棒,用起来很好用

社区相对比较活跃,几乎每个月都发布几个版本分

在国内一些互联网公司近几年用rabbitmq也比较多一些

但是问题也是显而易见的,RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重。

而且erlang开发,国内有几个公司有实力做erlang源码级别的研究和定制?如果说你没这个实力的话,确实偶尔会有一些问题,你很难去看懂源码,你公司对这个东西的掌控很弱,基本职能依赖于开源社区的快速维护和修复bug。

而且rabbitmq集群动态扩展会很麻烦,不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码,很难定制和掌控。


接口简单易用,而且毕竟在阿里大规模应用过,有阿里品牌保障

日处理消息上百亿之多,可以做到大规模吞吐,性能也非常好,分布式扩展也很方便,社区维护还可以,可靠性和可用性都是ok的,还可以支撑大规模的topic数量,支持复杂MQ业务场景

而且一个很大的优势在于,阿里出品都是java系的,我们可以自己阅读源码,定制自己公司的MQ,可以掌控

社区活跃度相对较为一般,不过也还可以,文档相对来说简单一些,然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码

还有就是阿里出台的技术,你得做好这个技术万一被抛弃,社区黄掉的风险,那如果你们公司有技术实力我觉得用RocketMQ挺好的


kafka的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展

同时kafka最好是支撑较少的topic数量即可,保证其超高吞吐量

而且kafka唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略

这个特性天然适合大数据实时计算以及日志收集

综上所述,各种对比之后,我个人倾向于是:

一般的业务系统要引入MQ,最早大家都用ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了;

后来大家开始用RabbitMQ,但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他,对公司而言,几乎处于不可控的状态,但是确实人是开源的,比较稳定的支持,活跃度也高;

不过现在确实越来越多的公司,会去用RocketMQ,确实很不错,但是我提醒一下自己想好社区万一突然黄掉的风险,对自己公司技术实力有绝对自信的,我推荐用RocketMQ,否则回去老老实实用RabbitMQ吧,人是活跃开源社区,绝对不会黄

所以中小型公司,技术实力较为一般,技术挑战不是特别高,用RabbitMQ是不错的选择;大型公司,基础架构研发实力较强,用RocketMQ是很好的选择

如果是大数据领域的实时计算、日志采集等场景,用Kafka是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范

原文地址:https://www.cnblogs.com/laojiao/p/9573016.html

时间: 2024-10-05 07:33:35

消息队列的使用场景及优缺点?的相关文章

挨踢部落坐诊第四期:Java消息队列的应用场景和作用

挨踢部落是为核心开发者提供深度技术交流,解决开发需求,资源共享的服务社群.基于此社群,我们邀请了业界技术大咖对开发需求进行一对一突破,解除开发过程中的绊脚石.以最专业.最高效的答复为开发者解决开发难题. 消息队列 话题关键词:消息队列.索引.App.路由.接口 部落阵容:51CTO管理团队: 面向对象:移动开发者.IT运维.数据分析师 参与方式:加入51CTO开发者QQ交流群(群号370892523(已满).请加312724475),有任何技术问题,在群里提问,或发给群主小官. 活动详情: 重庆

转:消息队列的使用场景

一.消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题.实现高性能,高可用,可伸缩和最终一致性架构.是大型分布式系统不可缺少的中间件. 目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等. 二.消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景.异步处理,应用解耦,流量削锋和消息通讯四个场景. 2.1异步处理 场景说明:用户注册后,需要发注册邮件和注册短信.传统

消息队列的使用场景

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题 实现高性能,高可用,可伸缩和最终一致性架构 使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ 二.消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景.异步处理,应用解耦,流量削锋和消息通讯四个场景 2.1异步处理 场景说明:用户注册后,需要发注册邮件和注册短信.传统的做法有两种 1.串行的方式:2.并行方式 (1)串行方式:将注册信息写入数

消息队列常用应用场景介绍

消息队列作为分布式系统中重要的组件,可以解决应用耦合,异步消息,流量削锋等系列问题 实现高性能,高可用,可伸缩和最终一致性架构 使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ 消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景. 1 异步处理 场景说明:用户注册后,需要发注册邮件和注册短信.传统的做法有两种 1.串行的方式:2.并行方式 (1)串行方式:将注册信息写入数据库成功后,发送注册邮件,再发送注册短信.以上三个任

RabbitMQ,Apache的ActiveMQ,阿里RocketMQ,Kafka,ZeroMQ,MetaMQ,Redis也可实现消息队列,RabbitMQ的应用场景以及基本原理介绍,RabbitMQ基础知识详解,RabbitMQ布曙

消息队列及常见消息队列介绍 2017-10-10 09:35操作系统/客户端/人脸识别 一.消息队列(MQ)概述 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为: 当不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候. 消息队列主要解决了应用耦合.异步处理.流量削锋等问题. 当前使用较多的消息队列有RabbitMQ.RocketMQ.ActiveMQ.Kafka.ZeroMQ.MetaMq等,而部分数据库如Re

MQ入门总结(一)消息队列概念和使用场景

一.消息队列 消息即是信息的载体.为了让消息发送者和消息接收者都能够明白消息所承载的信息(消息发送者需要知道如何构造消息:消息接收者需要知道如何解析消息),它们就需要按照一种统一的格式描述消息,这种统一的格式称之为消息协议.所以,有效的消息一定具有某一种格式:而没有格式的消息是没有意义的. 而消息从发送者到接收者的方式也有两种.一种我们可以称为即时消息通讯,也就是说消息从一端发出后(消息发送者)立即就可以达到另一端(消息接收者),这种方式的具体实现就是我们已经介绍过的RPC(当然单纯的http通

浅谈消息队列及常见的消息中间件

消息队列 已经逐渐成为企业应用系统 内部通信 的核心手段.它具有 低耦合.可靠投递.广播.流量控制.最终一致性 等一系列功能. 当前使用较多的 消息队列 有 RabbitMQ.RocketMQ.ActiveMQ.Kafka.ZeroMQ.MetaMQ 等,而部分 数据库 如 Redis.MySQL 以及 phxsql 也可实现消息队列的功能. 正文 1. 消息队列概述 消息队列 是指利用 高效可靠 的 消息传递机制 进行与平台无关的 数据交流,并基于 数据通信 来进行分布式系统的集成. 通过提供

Java常用消息队列原理介绍及性能对比

消息队列使用场景 为什么会需要消息队列(MQ)? 解耦  在项目启动之初来预测将来项目会碰到什么需求,是极其困难的.消息系统在处理过程中间插入了一个隐含的.基于数据的接口层,两边的处理过程都要实现这一接口.这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束. 冗余  有些情况下,处理数据的过程会失败.除非数据被持久化,否则将造成丢失.消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险.许多消息队列所采用的"插入-获取-删除"范式中,在把一

面试官对于消息队列的连环炮

1. 引子 消息队列分布式系统中重要的组件,一种存放消息的容器,主要作用有解耦.异步.削锋,是大型分布式系统不可缺少的中间件. 常见的消息队列有 ActiveMQ,RabbitMQ,RocketMQ,Kafka. 简历中涉及到了消息队列,面试官先问了这样几个问题: 你们系统里为什么要使用消息队列? 既然使用了消息队列,说说他还有什么使用场景? 消息队列的优缺点是什么? 2. 为什么使用消息队列? 我的回答:甲方提供 EOS 充值服务,我方进行调用.出于解耦的目的,引入了消息队列. 一个类似应试的