开发笔记:详解ＭＱ消息队列及四大主流ＭＱ的优缺点

前言

近期有了想跳槽的打算&＃xff0c;所以自己想巩固一下自己的技术&＃xff0c;想了解一些面试比较容易加分的项&＃xff0c;近期准备深入研究一下Redis和MQ这两样&＃xff0c;这总体上都是为了解决服务器并发的原因&＃xff0c;刚翻到了一篇有关于MQ的&＃xff0c;觉得写得特别好&＃xff0c;特此记录一下&＃xff0c;也算是为了加深自己的印象。

面试题切入

• 为什么要使用MQ

• 消息队列有什么优点和缺点

• kafka、ActiveMQ、RabbitMQ、RocketMQ有什么区别

面试官心理分析

首先&＃xff0c;你们系统里面为什么要用MQ

不少去面试的人&＃xff0c;都知道自己以前项目里面用过MQ、Redis&＃xff0c;但是为什么用这个&＃xff0c;却不知道&＃xff0c;这种人说白了就是为了用而用&＃xff0c;又或者这个框架就是别人设计的&＃xff0c;他自己都没了解过里面的东西&＃xff0c;自然也不知道为什么要用。如果面试的时候面试官问你这种问题你答不上来&＃xff0c;可能已经被pass百分之三十了&＃xff0c;面试官通常对这种人印象很不好&＃xff0c;他怕你进了公司只会埋头苦干&＃xff0c;不懂得自己思考。

第二&＃xff0c;你既然用了MQ&＃xff0c;那你知不知道MQ有什么好处和坏处

如果没考虑过这个问题一定要慎重回答&＃xff0c;因为你没考虑过这个&＃xff0c;盲目的弄个MQ进系统&＃xff0c;当下的问题可能是解决了&＃xff0c;但万一后面出了问题不是给公司留坑吗&＃xff0c;面试官就怕这样的人&＃xff0c;招进来干了一年&＃xff0c;自己跳槽了&＃xff0c;给系统挖一堆坑&＃xff0c;留下无穷祸患。

第三&＃xff0c;既然你用了MQ&＃xff0c;比如其中一种MQ&＃xff0c;那你当时做没做过调研

别看别人用了MQ&＃xff0c;咦&＃xff0c;感觉挺好的&＃xff0c;就自己瞎弄了一个&＃xff0c;根本没考虑过MQ的选型&＃xff0c;比如kafka&＃xff0c;每个MQ并没有绝对的好处和坏处&＃xff0c;现在业界流行的MQ各有各的好处&＃xff0c;各有各的坏处&＃xff0c;你要做的就是扬长避短&＃xff0c;挑选最适合自己系统的MQ。

面试题剖析

①为什么要使用MQ

其实面试官问你这个问题就是想知道&＃xff0c;你们公司有个什么样的业务场景&＃xff0c;这个业务场景有个什么技术挑战&＃xff0c;如果不用MQ可能会比较麻烦&＃xff0c;包括现在用了MQ以后有哪些好处等等。先说一下MQ常见的使用场景吧&＃xff0c;MQ的使用场景有很多&＃xff0c;但是比较核心的就是&＃xff1a;解耦、异步、削锋。

系统解耦

首先举例下面这个场景&＃xff0c;现有ABCDE五个系统&＃xff0c;最初的时候BCD三个系统都要调用A系统的接口获取数据&＃xff0c;一切都很正常&＃xff0c;但是突然&＃xff0c;D系统说&＃xff1a;我不要了&＃xff0c;你不用给我传数据了&＃xff0c;A系统无奈&＃xff0c;只能修改代码&＃xff0c;将调用D系统的代码删除&＃xff0c;这时候还没删除呢&＃xff0c;E系统发送了请求&＃xff0c;但是A系统这时候还没处理完D系统的请求&＃xff0c;A系统卒&＃xff01;&＃xff01;&＃xff01;彻底崩溃。看下图↓↓↓↓↓↓↓↓↓↓↓

上述场景中&＃xff0c;BCDE都需要用到A系统提供的数据&＃xff0c;A系统跟其他四个系统严重耦合&＃xff0c;需要时时刻刻考虑其他四个系统要是挂了怎么办&＃xff0c;需不需要重新发送数据给他们&＃xff0c;这个时候的A系统内心是崩溃的。

但是如果使用了MQ之后 &＃xff0c;A系统的数据只需要放到MQ里面&＃xff0c;其他的系统想请求获取数据只需要去MQ里面消费即可&＃xff0c;如果突然不想请求了&＃xff0c;就取消对MQ的消费就行了&＃xff0c;A系统根本不需要考虑给谁去响应这个数据&＃xff0c;也不需要去维护代码&＃xff0c;也不用考虑其他系统是否调用成功&＃xff0c;失败超时等情况。详细看下图↓↓↓↓↓↓↓↓

总结&＃xff1a;通过MQ发布订阅消息的模型&＃xff0c;A系统就成功的跟其他系统解耦了。另外&＃xff0c;在Java面试题精选 公众号后台回复“面试资料”&＃xff0c;送你一份Java面试题宝典。

面试技巧&＃xff1a;你需要思考一下&＃xff0c;在你自己的系统里面有没有类似的情况&＃xff0c;一个系统或者模块&＃xff0c;调用了多个系统或者模块&＃xff0c;它们互相之间的调用非常复杂&＃xff0c;并且维护起来很麻烦&＃xff0c;但其实这个调用是不需要直接同步调用接口的&＃xff0c;如果用MQ给它异步化解耦也是可以的&＃xff0c;你就需要思考在你的项目里&＃xff0c;是不是可以用MQ给它进行系统的解耦&＃xff0c;可以自己组织一下语言回答。

异步调用

场景二&＃xff0c;还是ABCD四个系统&＃xff0c;A系统收到一个请求&＃xff0c;需要在自己本地写库&＃xff0c;还需要往BCD三个系统写库&＃xff0c;A系统自己写本地库需要3ms&＃xff0c;往其他系统写库相对较慢&＃xff0c;B系统200ms &＃xff0c;C系统350ms&＃xff0c;D系统400ms&＃xff0c;这样算起来&＃xff0c;整个功能从请求到响应的时间为3ms&＃43;200ms&＃43;350ms&＃43;400ms&＃61;953ms&＃xff0c;接近一秒&＃xff0c;对于用户来说&＃xff0c;点个按钮要等这么长时间&＃xff0c;基本是无法接受的&＃xff0c;侧面也反映出这家研发人员技术不咋地。详情如下图↓↓↓↓↓↓

一般的互联网企业&＃xff0c;对于用户请求响应的时间要求在100ms-200ms之间&＃xff0c;这样&＃xff0c;用户的眼睛存在视觉暂停现象&＃xff0c;用户响应时间在此范围内就可以了&＃xff0c;所以上面的现象是不可取的。

如果用了MQ&＃xff0c;用户发送请求到A系统耗时3ms&＃xff0c;A系统发送三条消息到MQ&＃xff0c;假如耗时5ms&＃xff0c;用户从发送请求到相应3ms&＃43;5ms&＃61;8ms&＃xff0c;仅用了8ms&＃xff0c;用户的体验非常好。

流量削峰

场景三&＃xff0c;这次举个实例吧&＃xff0c;也是近期发生的&＃xff0c;我们都知道 &＃xff0c;2020年爆发的这场新冠病毒&＃xff0c;导致各大线上商城APP里面的口罩被抢购一空&＃xff0c;在这种情况下&＃xff0c;JD商城开启了一场每晚八点的抢购3Q口罩的活动&＃xff0c;每天下午三点进行预约&＃xff0c;晚上八点抢购&＃xff0c;从JD商城刚上线这个活动&＃xff0c;我连续抢了近一个周&＃xff0c;也算是见证了一个百万并发量系统从出现问题到完善的一个过程&＃xff0c;最初第一天&＃xff0c;我抢购的时候&＃xff0c;一百多万预约&＃xff0c;到八点抢购估计也能有百万的并发量&＃xff0c;可是第一天&＃xff0c;到八点我抢的时候&＃xff0c;由于并发量太高&＃xff0c;直接把JD服务器弄崩了&＃xff0c;直接报了异常&＃xff0c;可能JD在上线这个活动的时候也没能够想到会有那么高的并发&＃xff0c;打了一个猝不及防&＃xff0c;但是这只是在前一两天出现报异常的情况&＃xff0c;后面却没有再出现异常信息&＃xff0c;到后来再抢购只是响应的时间变得很慢&＃xff0c;但是JD系统并没有崩溃&＃xff0c;这种情况下一般就是用了MQ&＃xff08;或者之前用了MQ&＃xff0c;这次换了个吞吐量级别更高的MQ&＃xff09;&＃xff0c;也正是利用了MQ的三大好处之一——削峰。

JD系统每天0—19点&＃xff0c;系统风平浪静&＃xff0c;结果一到八点抢购的时候&＃xff0c;每秒并发达到百万&＃xff0c;假设JD数据库没秒能处理1.5w条并发请求&＃xff08;并非实际数据&＃xff0c;主要为了举例&＃xff09;,到八点抢购的时候&＃xff0c;每秒并发百万&＃xff0c;这直接导致系统异常&＃xff0c;但是八点一过&＃xff0c;可能也就几万用户在线操作&＃xff0c;每秒的请求可能也就几百条&＃xff0c;对整个系统毫无压力。

如果使用了MQ&＃xff0c;每秒百万个请求写入MQ&＃xff0c;因为JD系统每秒能处理1W&＃43;的请求&＃xff0c;JD系统处理完然后再去MQ里面&＃xff0c;再拉取1W&＃43;的请求处理&＃xff0c;每次不要超过自己能处理的最大请求量就ok&＃xff0c;这样下来&＃xff0c;等到八点高峰期的时候&＃xff0c;系统也不会挂掉&＃xff0c;但是近一个小时内&＃xff0c;系统处理请求的速度是肯定赶不上用户的并发请求的&＃xff0c;所以都会积压在MQ中&＃xff0c;甚至可能积压千万条&＃xff0c;但是高峰期过后&＃xff0c;每秒只会有一千多的并发请求进入MQ&＃xff0c;但是JD系统还是会以每秒1W&＃43;的速度处理请求&＃xff0c;所以高峰期一过&＃xff0c;JD系统会很快消化掉积压在MQ的请求&＃xff0c;在用户那边可能也就是等的时间长一点&＃xff0c;但是绝对不会让系统挂掉。

消息队列的优缺点

优点

上面已经说过了&＃xff0c;系统解耦&＃xff0c;异步调用&＃xff0c;流量削峰。

缺点

①系统可用性降低&＃xff1a; 系统引入的外部依赖越多&＃xff0c;系统要面对的风险越高&＃xff0c;拿场景一来说&＃xff0c;本来ABCD四个系统配合的好好的&＃xff0c;没啥问题&＃xff0c;但是你偏要弄个MQ进来插一脚&＃xff0c;虽然好处挺多&＃xff0c;但是万一MQ挂掉了呢&＃xff0c;那样你系统不也就挂掉了。

②系统复杂程度提高&＃xff1a; 非要加个MQ进来&＃xff0c;如何保证没有重复消费呢&＃xff1f;如何处理消息丢失的情况&＃xff1f;怎么保证消息传递的顺序&＃xff1f;问题太多。

③一致性的问题&＃xff1a; A系统处理完再传递给MQ就直接返回成功了&＃xff0c;用户以为你这个请求成功了&＃xff0c;但是&＃xff0c;如果在BCD的系统里&＃xff0c;BC两个系统写库成功&＃xff0c;D系统写库失败了怎么办&＃xff0c;这样就导致数据不一致了。

所以。消息队列其实是一套非常复杂的架构&＃xff0c;你在享受MQ带来的好处的同时&＃xff0c;也要做各种技术方案把MQ带来的一系列的问题解决掉&＃xff0c;等一切都做好之后&＃xff0c;系统的复杂程度硬生生提高了一个等级。

四大主流MQ&＃xff08;kafka、ActiveMQ、RabbitMQ、RocketMQ&＃xff09;各自的优缺点

目前业界四大主流的MQ有kafka、ActiveMQ、RabbitMQ、RocketMQ。其他的MQ也有&＃xff0c;不过比较冷门。就不用多说了&＃xff0c;画个表就明白了。↓↓↓↓↓↓↓↓

综上所述&＃xff0c;各种对比之后&＃xff0c;我个人倾向于是&＃xff1a;

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

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

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

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

如果是大数据领域的实时计算、日志采集等场景&＃xff0c;用Kafka是业内标准的&＃xff0c;绝对没问题&＃xff0c;社区活跃度很高&＃xff0c;绝对不会黄&＃xff0c;何况几乎是全世界这个领域的事实性规范。另外&＃xff0c;关注Java知音公众号&＃xff0c;回复“后端面试”&＃xff0c;送你一份面试题宝典&＃xff01;

ok&＃xff0c;消息队列写到这里就结束了&＃xff0c;记得点个在看&＃xff01;&＃xff01;&＃xff01;&＃xff01;&＃xff01;

感谢阅读&＃xff0c;希望对你有所帮助 :) 

来源&＃xff1a;blog.csdn.net/qq_44240587/article/details/104630567

推荐好文>>【练手项目】基于SpringBoot的ERP系统&＃xff0c;自带进销存&＃43;财务&＃43;生产功能>>分享一套基于SpringBoot和Vue的企业级中后台开源项目&＃xff0c;代码很规范&＃xff01;>>能挣钱的&＃xff0c;开源 SpringBoot 商城系统&＃xff0c;功能超全&＃xff0c;超漂亮&＃xff01;