一、面试官心理分析

第一,你知不知道你们系统里为什么要用消息队列这个东西?

        不少候选人,说自己项目里用了 Redis

MQ

,但是其实他并不知道自己为什么要用这个东西。其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过。

        没有对自己的架构问过为什么的人,一定是平时没有思考的人,面试官对这类候选人印象通常 很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿,不会自己思考。

        

第二,你既然用了消息队列这个东西,你知不知道用了有什么好处&坏处?

        你要是没考虑过这个,那你盲目弄个 MQ

进系统里,后面出了问题你是不是就自己溜了给公司 留坑?你要是没考虑过引入一个技术可能存在的弊端和风险,面试官把这类候选人招进来了,

基本可能就是挖坑型选手。就怕你干 1

年挖一堆坑,自己跳槽了,给公司留下无穷后患。

第三,既然你用了 MQ,可能是某一种 MQ,那么你当时做没做过调研?

        你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ

,比如

Kafka

,甚至都从没调研过行业流 行的 MQ

到底有哪几种。每一个

MQ

的优点和缺点是什么。每一个

MQ

没有绝对的好坏

,但是就是看用在哪个场景可以

扬长避短,利用其优势,规避其劣势

        如果是一个不考虑技术选型的候选人招进了团队,leader

交给他一个任务,去设计个什么系 统,他在里面用一些技术,可能都没考虑过选型,最后选的技术可能并不一定合适,一样是留坑。

二、面试题剖析

1.为什么使用消息队列?

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

        面试官问你这个问题,

期望的一个回答

是说,你们公司有个什么

业务场景

,这个业务场景有 个什么技术挑战,如果不用 MQ

可能会很麻烦,但是你现在用了

MQ

之后带给了你很多的好处。

        先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有

3

个:

解耦

异 步

削峰

解耦

        看这么个场景。A

系统发送数据到

BCD

三个系统,通过接口调用发送。如果

E

系统也要这个数据呢?那如果 C

系统现在不需要了呢?

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

,这几乎是不可接受的。

        一般互联网类的企业,对于用户直接的操作,一般要求是每个请求都必须在 200 ms

以内完成,对用户几乎是无感知的。

        如果

使用

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

系统就会快速将积压 的消息给解决掉。

2.消息队列有什么优缺点?

        优点上面已经说了,就是

在特殊场景下有其对应的好处

解耦

异步

削峰

缺点有以下几个:

(1)系统可用性降低

        系统引入的外部依赖越多,越容易挂掉。本来你就是 A

系统调用

BCD

三个系统的接口就好了,ABCD 四个系统还好好的,没啥问题,你偏加个

MQ

进来,万一

MQ

挂了咋整?

MQ

一挂,整套系统崩溃,你不就完了?如何保证消息队列的高可用,可以

点击这里查看

(2)系统复杂度提高

        硬生生加个 MQ

进来,你怎么

保证消息没有重复消费

?怎么

处理消息丢失的情况

?怎么保证 消息传递的顺序性?头大头大,问题一大堆,痛苦不已。

(3)一致性问题

        A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是

BCD

三个系统那里,BD

两个系统写库成功了,结果

C

系统写库失败了,咋整?你这数据就不一致了。

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

倍。但是关键时刻,用,还是得用的。

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

综上,各种对比之后,有如下建议:

        一般的业务系统要引入 MQ

,最早大家都用

ActiveMQ

,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个 了;后来大家开始用

RabbitMQ

,但是确实

erlang

语言阻止了大量的

Java

工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度 也高。

        不过现在确实越来越多的公司会去用 RocketMQ

,确实很不错,毕竟是阿里出品,但社区可能有突然黄掉的风险(目前 RocketMQ

已捐给

Apache

,但

GitHub

上的活跃度其实不算高)对自己公司技术实力有绝对自信的,推荐用 RocketMQ

,否则回去老老实实用

RabbitMQ

吧,人家有活

跃的开源社区,绝对不会黄。

        所以

中小型公司

,技术实力较为一般,技术挑战不是特别高,用

RabbitMQ

是不错的选择;

大型公司

,基础架构研发实力较强,用

RocketMQ

是很好的选择。

        如果是

大数据领域

的实时计算、日志采集等场景,用

Kafka

是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。

推荐阅读

评论可见,请评论后查看内容,谢谢!!!评论后请刷新页面。

大家都在找:

kafka:kafka官网

activemq:activemq信息泄露漏洞flag

rabbitmq:rabbitmq怎么解决重复消费

大家都在看: