【RabbitMQ】MQ的优缺点

一、优点

1、解耦

     1）未使用MQ之前

                               

 

 

     A系统严重依赖各种乱七八糟的系统耦合起来，A系统产生了一个比较关键的数据，很多系统需要A系统把这个关键的数据传过来。负责A系统的哥们还得考虑，如果A系统挂了怎么办？如果E系统访问超时怎么办？我是不是需要做一个重试机制？

      2）使用MQ之后

                                 

      如果来一个新系统E需要数据，直接从MQ中消费即可。如果老系统D不需要这条数据了，就取消对MQ的消费即可。系统A压根不用考虑给谁发数据，不需要维护这个代码，不需要考虑人家是否调用成功，失败超时等。

      小结：

      通过MQ的发布和订阅的这么一个模型，Pub/Sub模型，系统A就跟其他系统彻底解耦了。

      我们需要考虑一下负责的项目中是否有类似的场景，就是1个系统或者一个模块，调用了多个系统或者模块，相互之间的调用很复杂，维护起来很麻烦。但是这个调用是不需要同步接口的，如果用MQ给它异步化解耦，也是可以的。你就需要考虑在你的项目里，是否可以用MQ去进行系统的解耦。

2、异步

      1）不用MQ的同步高延时请求

                          

       一般的互联网企业，对用户的直接操作，一般要求是每个请求在200ms以内完成，对用户几乎是无感知的。而按照上述同步执行，整个过程大概需要1秒。

     2）使用MQ异步化之后的接口性能优化

                              

       系统从接受请求到相应给用户共耗时20ms+5ms。对用户A而言，无感知。

3、削峰

      1）没用MQ的时候，高峰期系统被打死的场景

                                          

       一般的MySQL，抗到每秒2000的请求就差不多啦。如果每秒请求5000，可能就直接把mysql打死啦。如果mysql被打死，整个系统没法用了，但是中午高峰期过了之后，到了下午，也就是1万个用户同时操作，每秒中可能就50个请求。

       2）使用MQ来进行削峰

                               

       每秒在MQ积压3000条消息，1个小时积压18万条消息，1个半小时左右差不多就没有积压啦。

二、缺点

      1）系统可用性降低

       MQ一旦故障了，系统A就没法发送消息给MQ啦，然后系统BCD也没法消费到消息。整个系统就崩溃了，没有办法正常运转啦。

      2）系统复杂性变高

       硬生生加了个MQ，你怎么保证消费没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性。问题一大堆，痛苦不已。

      3）系统一致性问题

       系统ABC执行成功了，但是系统D执行失败了。但是给用户返回执行成功了，结果后台逻辑实际上是差了一点。完全没有执行完。