聊聊什么时候引入MQ

MQ的特点

  消息发送方不关注消息接收方是谁，同时消息接收方不关注消息发送方是谁，但发送方和接收方都要依赖MQ。

什么时候引入MQ

  结合MQ的特点我们知道，两个或多个服务不在同一台服务器上且一个服务需要使用其他服务产生的数据时可以使用MQ。那么，具体的场景呢？

服务顺序执行

  服务A执行完毕再执行服务B，服务B执行完毕再执行服务C。。。MQ不就是为这种场景量身定做的嘛！

消息发送方不关心执行结果

  先来看看该场景下不使用MQ的坏处：两个服务A、B之间使用RPC机制实现通信，此时服务A程序中直接RPC调用服务B，可以看到该做法是强耦合的，服务A依赖服务B，导致服务A执行时间延长，而且一旦服务B挂掉，可能导致服务A也挂掉；同时若有一个新服务C需要接入，服务A要修改程序，调用服务C。
  使用MQ以后，服务A和服务B进行了解耦，服务A只需要把消息发送到MQ即可，谁爱接收谁接收；此时服务A执行完毕就返回了，不会延时，服务B挂掉也不关服务A的事儿，接入新服务C时服务A可能压根不知道，不是说了，谁爱接收谁接收么。

消息发送方关心执行结果，但消息接收方执行时间很长

  很明显使用RPC调用时间会很长，此时使用两次MQ。消息发送方发送消息到MQ，消息接收方监听MQ，这是第一次MQ，此时消息发送方不必担心执行时间；消息接收方执行完毕后，发送消息到MQ，消息发送方监听MQ，这是第二次MQ，此时消息发送方能得到执行结果，消息接收方不必担心在第一次MQ时需要接收新的发送方的消息。

不适合使用MQ

  专挑MQ的弱点下手就不适合喽：消息发送方关心执行结果，服务之间强依赖。