为什么要使用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的 过了高峰期就可以处理数据