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等，都要考虑很多