RabbitMQ--面试官问为什么要使用MQ,应该怎么回答

如果简历中有写到使用过RabbitMQ或者其他的消息中间件,可能在MQ方面的第一个问题就是问:为什么要使用MQ

面试官期望的回答

  1、项目中有什么业务场景需要用到MQ

  2、但是用了MQ,会带来很多问题,有什么缺点

所以,我们首先要回答的就是MQ的使用场景,在第一篇MQ文章中有简单提过这个

应用场景

  1、异步处理

  2、流量削峰

  3、日志处理

  4、应用解耦

1、异步处理

  什么时候,我们有多个服务,如果是串行同步设计,例如:A服务产生一条数据,进行入库操作花费100ms,然后需要同步给B服务,B服务执行

insert和update SQL花费了200ms,然后A服务得到响应,到了C服务,又花费了300ms,然后整个系统响应花费了600ms+,如果系统有更多服务,用

户整个就崩溃了,特别是互联网公司,需要响应在200ms以内

  如果使用MQ,A服务入库操作话费100ms,发给MQ Broker只用了20ms,整个系统响应120ms,后面其余服务的入库操作就是异步的了,这个响应

时间就很正常

2、流量削峰

  流量高峰期对于系统来说是不可避免的,特别是互联网公司,例如:饿了吗中午是高峰期,这时候有100W用户在使用,每秒5000个请求打过来,

MySQL理论上只能承受每秒2000笔(这里不考虑Redis,或者其他架构设计),MySQL可能直接就挂了

  如果使用MQ,每次从MQ拉取2000请求过来,处理完了,进行ACK确认,继续拉取,能够有流量削峰的作用,虽然会造成MQ消息的堆积

3、日志处理

  这个主要是针对kafka的,很多大数据平台的日志量超级恐怖,kafka就是为了解决这种问题的,kafka我们怎么用过,就不细讲了。。。

4、应用解耦

  其实本人做过的第一个项目是保险项目,应用耦合比较严重,技术方面都比较落后吧,一个保费计算通过WebService接口串行调用好几个第三方

服务接口,感觉真的有点操蛋。类似这种情况,可能今天新增一个别的接口,明天减少一个接口。而且要考虑有的接口突然不通了,或者超时。是否

需要有一个重试机制,总之来说,很麻烦。

  这种时候如果使用RabbitMQ,通过发布订阅模型,使用交换机类型为fanout,都可以收到Producer的消息,fanout在讲java API的时候有讲到实

广播,我只要把消息发送给Broker,下游是否接口怎么变化,跟上游的关系已经不大了,反正就是你想怎么搞就怎么搞

MQ优缺点:

优点:

  应用场景也是MQ的优点。。。

缺点:

  1、系统可用性降低,MQ一旦挂了,影响很大,虽然MQ也有集群,可以实现高可用。据说有一线互联网公司MQ真的宕机过几小时,影响很大

  2、使用MQ,我们需要考虑的更多了,导致系统复杂性增加,例如:消息的幂等性、消息如何进行可靠性投递、消息突然丢失了等

  3、一致性问题。例如业务流程设计服务ABCD,需要保证原子性的,但是ABC都成功了,D失败了,这种时候就很蛋疼了

所以无论是什么中间件,Redis、MQ、Elasticsearch等,都要考虑很多

 

猜你喜欢

转载自www.cnblogs.com/huigelaile/p/10923420.html