如果简历中有写到使用过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，后面其余服务的入库操作就是异步的了，这个响应
时间就很正常。而且对失败重试很友好，设置重试次数，给个最终状态，如果还是失败，需要人工进行处理。
更通俗的例子就是：注册之后，发送短信和邮件，通过MQ异步处理。
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等，都要考虑很多