期望的回答是,你们公司有什么业务场景,这个业务场景有什么技术挑战,如果不用mq可能会很麻烦,但是你现在用了mq之后给了你很多的好处.
消息队列的使用场景,核心三个
-
解耦
-
不用mq到场景
在本来的开发流程中,系统A要给BCD三个系统发送数据,全部功能都已经完成了,并且已经上线了.此时又有一个e系统,也需要a系统给发送消息,所有a系统只能在修改代码,添加一套对接e系统的代码; 但是过了一段时间原本的bcd三个系统中的d系统,不需要a系统的数据了.a系统的只能将发送d的代码删除.循环往复.a系统一直在干活.
在这种场景下,a系统是严重的和各种系统耦合起来的,因为a系统可能产生了一个关键的数据,很多系统都需要依赖这个系统.获取数据.
还要考虑b系统挂了,c系统访问超时.d系统需要重复消费等等情况.
-
使用了mq的场景
系统a将产生的数据,将数据发送到mq中.a系统就不管了,谁需要这个数据,谁就从mq中消费数据,系统a就不需要考虑给谁发送消息了,不要考虑接口是否调用成功或者失败了
总结:
面试技巧:需要考虑一下,自己负责的系统中是否有类似的场景,就是一个系统或者模块中,调用了多个系统或者模块,互相直接的调用很很复杂,维护起来很麻烦,但是其实这个调用是不需要直接同步调用接口的,如果使用mq给他异步解耦,也是可以的.你就可以考虑在项目中是不是可以运用mq去进行解耦.
-
-
异步
-
不用mq的同步高延时请求场景
用户对系统a发起请求,a系统中又需要调用性需需要做四件事情,调用用bcd三个系统
- 在系统a自己的本地数据库执行了一个sql,使用了20ms
- 调用了系统b,执行了三条sql,使用了100ms
- 调用了c系统,执行了四sql ,使用了400ms
- 调用了系统d,执行2sql,使用了80ms
所以,一个请求耗费的总时长为600ms,用户通过浏览器发起请求,请求需要在200ms内的.所以600ms太久了
-
使用了mq,进行异步化之后的接口性能优化
用户请求了系统a以后,在a系统中去请求三个mq 的队列,分别获取bcd三个系统的数据,请求队列花费的时间大约5ms
bcd每个系统从对应的mq队列中获取请求的参数,去自己的本地执行对应的操作.
此时用户响应的时间为20ms+5ms的总时长.对用来说,点击完就完成了.对于bcd的查询时间,其实都是后台操作了.
可以提高高延时的接口.
-
-
削峰
-
没有用mq系统被打死的场景
大量的请求去访问系统,如果基于mysql,每秒2000的请求,基本就可以把mysql打死了,系统也就奔溃了,但是高峰期过了以后,
对系统到压力就小了,不影响系统.
-
使用mysql进行削峰
用户发起大量的请求,这些请求都被存储到mq中,系统a从mq中慢慢地拉取请求,每秒拉取2000个请求,不要超过自己能处理的最大量.就是是高峰,系统也不会挂掉.
存在的问题:
- 但是在mq中会有积压,但是过了高峰期,积压会被慢慢处理完
- 用户等待的时间会不会很久.
-