来源：blog.csdn.net/qq_44240587/article/details/104630567前言最近有跳槽的打算，想巩固一下自己的技能，学习一些面试中比较容易上分的项目。近期打算深入研究Redis和MQ。这个一般是为了解决服务器并发的原因。我刚找到一篇关于MQ的文章。我认为它写得很好。特此记录，加深印象。切入面试题为什么要用MQ消息队列kafka、ActiveMQ、RabbitMQ和RocketMQ有什么优缺点面试官有什么区别？MQ和Redis用过，不知道为什么用这个。这种人就是为了用，或者这个框架是别人设计的。里面的内容他一直没有看懂，自然不知道其中的缘由。使用。如果面试时面试官问你这种问题，你答不上来，你可能已经过了30%的时间。面试官通常对这种人印象不好。他怕你进了公司才会努力，不知道如何为自己着想。二、既然你用过MQ，你知道MQ的优缺点是什么吗？是解决了，但万一以后出了问题，岂不是给公司留下了空子？面试官生怕这样的人招他干一年，然后自己跳槽，给系统挖了很多坑，后患无穷。第三，你既然用了MQ，比如其中一个MQ，你当时有没有做过什么研究？别看别人用过MQ。哎，感觉不错，所以自己弄了一个，完全没有考虑MQ。对于模型选择，比如kafka，各个MQ没有绝对的优缺点。现在业界流行的MQ，各有优缺点。你要做的就是扬长避短，选择最适合你系统的MQ。面试题分析①为什么用MQ其实面试官问你这个问题是想知道你公司有什么样的业务场景，这个业务场景有什么技术挑战。如果不用MQ，可能会比较麻烦，包括现在用。MQ以后有什么好处等等。先说说MQ的常见使用场景。MQ的使用场景有很多，但最核心的是：解耦、异步、锐化。系统解耦首先以如下场景为例。有A、B、C、DE五个系统。一开始，B、C、D三个系统都调用了A系统的接口获取数据。一切正常，突然，D系统说：我不要了，你不用给我发数据了。系统A只好修改代码，删除调用系统D的代码，此时还没有删除。系统E发出了请求，但是系统A还没有处理系统D的请求，一个系统棋子！！！彻底崩溃。看下图↓↓↓↓↓↓↓↓↓↓↓↓在上述场景中，BCDE需要使用系统A提供的数据，系统A与其他四个系统耦合度很高。我应该怎么办？我需要重新发送数据给他们吗？这时候A系统的心脏就碎了。但是使用了MQ之后，系统A的数据只需要放在MQ中，其他系统想要请求数据只需要在MQ中消费即可。如果突然不想请求了，可以取消MQ的消费。A系统根本不需要考虑谁来响应这个数据，也不需要维护代码，也不需要考虑其他系统是否调用成功，失败超时等，见下图详情↓↓↓↓↓↓↓↓↓↓此外，MQ系列面试题及答案全部整理完毕。微信搜索Java技术栈，后台发送：面试，网上可以看。面试技巧：你需要思考自己的系统中是否存在类似的情况。一个系统或模块调用多个系统或模块。它们之间的调用非常复杂，维护起来也很麻烦，但实际上这个调用并不需要直接同步调用接口。如果用MQ异步解耦的话，你需要考虑能不能在你的项目中用MQ来解耦系统，自己组织一下。用语言回答。异步调用场景2还是ABCD的四个系统。系统A收到一个请求，需要在本地写库，同时也需要向BCD的三个系统写库。系统A自己写本地库需要3ms，而写库到其他系统比较慢，B系统200ms，C系统350ms，D系统400ms。这样计算，从请求到响应的时间整个函数的耗时为3ms+200ms+350ms+400ms=953ms，接近一秒。对于用户来说，点击一个按钮等待这么长时间基本上是无法接受的，也反映出这个研发人员的技术不行。具体如下图↓↓↓↓↓↓↓一般互联网公司要求用户请求的响应时间在100ms到200ms之间。这样用户的眼睛就有了视觉上的停顿，用户的反应时间就在这个范围内。因此，上述现象是不可取的。如果使用MQ，用户向系统A发送请求需要3ms，系统A向MQ发送3条消息。如果用5ms的话，用户从发出请求到对应的3ms+5ms=8ms只用了8ms，用户体验非常好。流量削峰场景3。这次我们举个例子。这也是最近发生的。众所周知，2020年新冠病毒的爆发，导致各大网络商城APP中的口罩都被抢购一空。在这种情况下，京东商城在每晚8:00开启了抢购3Q口罩的活动。每天下午3:00预约，晚上8:00购买。从京东商城推出这个活动开始，我已经抢了将近一周的时间，也算是见证了一个百万并发系统是一个从问题到完善的过程。一开始，第一天赶着去买的时候，已经有百万以上的预约了，估计到八点的时候就有百万并发了。但是第一天，赶到八点的时候，因为并发太高，直接把京东服务器挂了，直接报异常。可能京东在活动发起的时候没想到这么高的并发，打了个措手不及，但这只是一两天前报异常的案例。不过后来并没有出现异常信息，后面rush的时候响应时间变得很慢，但是京东系统并没有崩溃。这种情况一般使用MQ（或者之前使用MQ，这次改成吞吐量级别更高的MQ），也使用了MQ的三大优势之一——削峰填谷。京东系统每天从0点到19点都很平静。结果1点到8点买的时候，每秒并发请求数达到百万。假设京东数据库每秒可以处理1.50,000个并发请求（不是实际数据，主要是举例）。8:00抢购的时候，每秒有百万笔交易，直接导致系统异常，但是8:00以后，可能只有几万用户在线，每秒的请求数可能是只有几百个，不会对整个系统造成压力。如果使用MQ，每秒有百万请求写入MQ，因为京东系统每秒可以处理1W+请求。JD系统处理完后，会去MQ，然后拉取1W+的请求进行处理。每次不要超过你能处理的范围。处理的最大请求数是可以的。这样一来，到8点的高峰时间系统才挂掉，但是一个小时内，系统处理请求的速度肯定跟不上用户的并发请求，所以就会积压在MQ中，甚至可能有上千万的积压，但是过了高峰期，每秒只有千余个并发请求会进入MQ，但京东系统仍然会以每秒1W+的速度处理请求，所以一旦高峰期过去，JD系统会快速消化MQ中积压的请求，用户可能会多等一会，但绝对不会让系统挂掉。消息队列的优缺点上面已经说了，系统解耦，异步调用，流量调峰。缺点①系统可用性降低：系统引入的外部依赖越多，系统面临的风险就越高。以场景1为例，ABCD的四个系统很好配合，所以没有问题，但是你想弄个MQ进来踩一下，虽然好处多多，但是万一MQ挂了，那你的系统也会挂掉。②系统的复杂度增加了：如果非要加一个MQ，怎么保证不重复消费？如何处理消息丢失的情况？如何保证消息传递的顺序？太多问题。③一致性问题：A系统处理后直接返回成功，传给MQ。用户认为你的请求成功了。但是在BCD系统中，BC系统写入数据库成功，D系统写入数据库失败。怎么办，这样会导致数据不一致。所以。消息队列其实是一个非常复杂的架构。在享受MQ带来的好处的同时，也需要做出各种技术方案来解决MQ带来的一系列问题。一切搞定之后，系统的复杂度陡然增加了一个级别。四大主流MQ（kafka、ActiveMQ、RabbitMQ、RocketMQ）的优缺点目前业界的四大MQ分别是kafka、ActiveMQ、RabbitMQ、RocketMQ。还有其他的MQ，但是比较冷门。不用多说，画个表就明白了。↓↓↓↓↓↓↓↓↓综上所述，经过各种比较，我个人倾向于：一般的业务系统都应该引入MQ，大家最早也用过ActiveMQ，不过现在大家确实用的不多了。规模吞吐量场景的验证，社区不是很活跃，算了，个人不推荐使用这个；后来大家都开始使用RabbitMQ，但是erlang语言确实阻碍了大量java工程师的深入研究和把控，对于公司来说，几乎处于不可控状态，但是人是开源的，支持相对稳定，活跃度高；但是现在越来越多的公司会使用RocketMQ，这确实很好，但是我提醒自己想想社区突然变黄的风险，我对我公司的技术实力有绝对的信心。我推荐RocketMQ，不然回去老老实实实干RabbitMQ。人是活跃的开源社区，永远不会黄，所以会沦陷RabbitMQ对于技术实力一般，技术挑战不是特别高的小公司来说是个不错的选择；对于基础设施研发能力强的大公司来说，RocketMQ是大数据领域实时计算和日志采集的不错选择场景，使用Kafka是行业标准，绝对没问题，社区很活跃，会的永远不要色情，更何况这几乎是全世界这个领域的事实规范。消息队列就到这里了，记得点开看哦！！！！！近期热点文章推荐：1.1000+Java面试题及答案（2022最新版）2.厉害了！Java协程来了。..3.SpringBoot2.x教程，太全面了！4.不要用爆破爆满画面，试试装饰者模式，这才是优雅的方式！！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
