为什么要使用MQ?

为什么使用消息队列

 

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

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

 

 

 

 

 

解耦

 

 

刚开始D系统需要消息 后来不需要了 A系统就要修改代码 然后再打包上线

B系统也不需要了 也需要修改代码 然后打包上线  一会儿要发一会又不要发

不用MQ就严重耦合了一起

 

 

 

 

 

谁需要，谁就从Mq里面去消费

如果系统E也要消费 跟系统A已经没关系了 写个代码直接从Mq中消费数据就可以了

系统D不需要了 取消对MQ消费即可 

系统A不需要考虑给谁发送数据 不需要维护代码  不需要调用是否成功 失败超时等问题 唯一要做的就是产生数据 发送到MQ

通过这个模型 pub/sub（需要了解） 让系统A和其他人解耦合了

 

 

 

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

 

这部分需要了解 询问导师相关场景

 

 

异步

 

不用MQ的同步高延时请求场景

 

 

用户对系统A发起请求

 

做 2 3 4 5 四件事情

 

20 + 100 +150 + 80 =350ms

20 + 300 +450 +200=970ms

 

这么久的时间 接近1s钟 是不可接受的

一般需要在 200ms 内完成

 

使用MQ进行异步化之后的接口性能优化

 

 

步骤 1 2 总花费时间是25ms 然后我就不管了

 

 

系统B可以去监听MQ队列1 在自己本地执行相对应的操作

 

系统A从接收请求到返回响应给用户 只有25ms 步骤1 2  就不管了 直接返回了

 

耗时的操作 都在对应的BCD本地进行操作 慢慢执行

 

 

削峰

 

没有用MQ的时候高峰期系统被打死的情景

 

 

 

 

 

 

使用MQ来进行削峰

 

挤压的话是OK的 过了高峰期就可以处理数据