面试题:为什么要使用中间件MQ

为什么使用消息队列

面试题
  • 为什么使用消息队列?
  • 消息队列有什么优点和缺点?
  • Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景?
面试题剖析
为什么使用消息队列

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

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

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

解耦

看这么个场景,A系统发送数据到BCD三个系统,通过接口调用发送,如果E系统也要这个数据呢?那如果现在D系统现在不需要了呢?A系统的负责人几乎要崩溃了

在这里插入图片描述

在这个场景中,A系统跟其他各种乱七八糟的系统严重耦合,A系统产生一条比较关键的数据,很多系统都需要A系统讲这个发送过来,A系统要时时刻刻考虑BCDE四个系统如果挂了该咋办?要不要重发,要不要把消息存起来?

如果使用MQ,A系统产生一条数据,发送到MQ里面去。哪个系统需要数据自己去MQ里面消费,如果新系统需要数据,也直接从MQ里消费即可;如果某个系统不需要这条数据了,就取消对MQ消息的消费即可。这样下来,A系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。

在这里插入图片描述

总结:通过一个MQ,Pub/Sub发布订阅消息这么一个模型,A系统就跟其他系统彻底解耦了

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

异步

再来看一个场景,A系统接收一个请求,需要在自己本地写库,还需要在BCD三个系统写库,自己本地写库要3ms,BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3+300+450+200 = 953ms,接近1s,用户感觉搞什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个1s,这几乎是不可接受的。

在这里插入图片描述

一般互联网类的企业,对于用户直接的操作,一般要求是每个请求都必须在200ms以内完成,对用户几乎是无感知的。

如果使用MQ,那么A系统连续发送3条消息到MQ队列中,加入耗时5ms,A系统从接受一个请求到返回响应给用户,总时长是3+5 = 8ms,对于用户而言,其实感觉上就是点个按钮,8ms以后就直接返回了,真快!

在这里插入图片描述

削峰

每天0:00到12:00,A系统风平浪静,每秒并发请求数量就50个。结果每次一到12:00~13:00,每秒并发请求数量突然会暴增到5k+条。但是系统是直接基于MySQL的,大量的请求涌入MySQL,每秒钟对MySQL执行约5k条SQL。

一般的MySQL,扛到每秒2k个请求就差不多了,如果每秒请求到5k的话,可能就直接把MySQL给打死了,导致系统奔溃,用户也就没法再使用系统了。

但是高峰期已过,到了下午的时候,就成了低峰期,可能也就1w的用户同时在网站上操作,每秒钟的请求数量可能也就50个请求,对整个系统几乎没有任何的压力。

在这里插入图片描述

如果使用MQ,每秒5k个请求写入MQ,A系统每秒钟最多处理2k个请求,因为MySQL每秒钟最多处理2k个。A系统从MQ中慢慢拉取请求,每秒钟就拉取2k个请求,不要超过自己每秒能处理的最大请求数量就ok,这样下来,哪怕是高峰期的时候,A系统也绝对不会挂掉。而MQ每秒钟5k个请求进来,就2k个请求出去,结果就导致在中午高峰期(1个小时),可能有几十万甚至几百万的请求积压在MQ中。

在这里插入图片描述

这个短暂的高峰期积压是ok的,因为高峰期过了之后,每秒钟就50个请求进MQ,但是A系统依然会按照每秒2k个请求的速度在处理。所以说,只要高峰期一过,A系统就会快速将积压的消息给解决掉。

消息队列有什么优缺点

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

缺点有以下几个:

  • 系统可用性降低

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

  • 系统复杂度提高

硬生生加个MQ进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?

  • 一致性问题

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

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

Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么优缺点?

特性ActiveMQRabbitMQRocketMQKafka
单机吞吐量万级,比RocketMQ、Kafka第一个数量级同ActiveMQ10万级,支撑高吞吐10万级,高吞吐,一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响topic可以达到几百/几千的级别,吞吐量会有较小幅度的下降,这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topictopic从几十到几百个时候,吞吐量会大幅度下降,在同等机器下,Kafka尽量保证topic数量不要过多,如果要支撑大规模的topic,需要增加更多的及其资源
时效性ms级微秒级,这是RabbitMQ的一大特点,延迟最低ms级延迟在ms级以内
可用性高,基于主从架构实现高可用同ActiveMQ非常高,分布式架构非常高,分布式,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
消息可靠性有较低的概率丢失数据基本不丢经过参数优化配置,可以做到0丢失同RocketMQ
功能支持MQ领域的功能极其完备基于erlang开发,并发能力很强,性能极好,延时很低MQ功能较为完善,还是分布式的,扩展性好功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值