What

消息系统是一种跨进程的通信机制，用于上下游传递消息的。

Why

使用了MQ后，消息发送上游只需要依赖MQ，不需要在依赖其他服务了。

When

1. 数据驱动的任务依赖
   比如：系统经常需要在凌晨做一些数据统计的任务，这些任务之间有一定的依赖性。比如说我要先归档，然后在统计完各个类别有多少个案件数，然后用这个案件数来做下一步的统计...，这样多个任务之间有个顺序的依赖关系。
   这种情况下我们可以使用MQ来解耦，每个任务执行结束后都发一个消息，告诉其他任务我这边结束了，你可以开始了。
   可以用来做这种通知的，多个任务之间只需要依赖MQ即可
   其实这种情况也可以开个接口，但这样可能会导致服务之间，系统之间耦合度比较高。

2. 上游不需要关心你下游执行的结果
   上游只管发消息就好了，你这个消息后面是怎么被消费的，是怎么被下游使用的我上游是不怎么太关心的。也可以说是不需要适时性那么高。
   比如：在案件信息有变动的时候需要给当事人发短信，但实际上我们可能不需要太关心短信是否适时的正确发送了。
   采用这种方案的优点是：

   1. 上游执行时间短
   2. 逻辑解耦，除了依赖mq，其他互不依赖
   3. 如果需要新增一个下游的功能，上游不需要修改代码，只需要新加的这个下游服务订阅上游即可

3. 上游比较关注执行的结果，但是执行时间比较长
   有时候执行执行很长，而且我们还需要等待。这时候我们要关注结果我们该怎么办呢？
   举个栗子：在调用微信支付，我们会调用微信的接口，但是执行时间会比较长。这个是时候微信会立即返回一个调用成功的消息，然后微信执行完了，付款成功就往MQ发个消息。然后上游订阅这个消息就可以知道付款到底是成功还是没有成功，没有成功的话可能需要重试之类的操作。

NO WHEN （不需要使用MQ的场景）

MQ这么好那我们什么场景都要用MQ吗？
不是的，在那种调用和被调用的关系中我们是无法用MQ来取代的。
MQ有哪些缺点：

1. 多加了一个组件
2. 消息路径更长了
3. 要同时保证消息不丢失和消息不重复很难
4. 上游不知道下游执行的结果