What
消息系统是一种跨进程的通信机制，用于上下游传递消息的。
Why
使用了MQ后，消息发送上游只需要依赖MQ，不需要在依赖其他服务了。
When
数据驱动的任务依赖
比如：系统经常需要在凌晨做一些数据统计的任务，这些任务之间有一定的依赖性。比如说我要先归档，然后在统计完各个类别有多少个案件数，然后用这个案件数来做下一步的统计...，这样多个任务之间有个顺序的依赖关系。
这种情况下我们可以使用MQ来解耦，每个任务执行结束后都发一个消息，告诉其他任务我这边结束了，你可以开始了。
可以用来做这种通知的，多个任务之间只需要依赖MQ即可
其实这种情况也可以开个接口，但这样可能会导致服务之间，系统之间耦合度比较高。-
上游不需要关心你下游执行的结果
上游只管发消息就好了，你这个消息后面是怎么被消费的，是怎么被下游使用的我上游是不怎么太关心的。也可以说是不需要适时性那么高。
比如：在案件信息有变动的时候需要给当事人发短信，但实际上我们可能不需要太关心短信是否适时的正确发送了。
采用这种方案的优点是：- 上游执行时间短
- 逻辑解耦，除了依赖mq，其他互不依赖
- 如果需要新增一个下游的功能，上游不需要修改代码，只需要新加的这个下游服务订阅上游即可
上游比较关注执行的结果，但是执行时间比较长
有时候执行执行很长，而且我们还需要等待。这时候我们要关注结果我们该怎么办呢？
举个栗子：在调用微信支付，我们会调用微信的接口，但是执行时间会比较长。这个是时候微信会立即返回一个调用成功的消息，然后微信执行完了，付款成功就往MQ发个消息。然后上游订阅这个消息就可以知道付款到底是成功还是没有成功，没有成功的话可能需要重试之类的操作。
NO WHEN （不需要使用MQ的场景）
MQ这么好那我们什么场景都要用MQ吗？
不是的，在那种调用和被调用的关系中我们是无法用MQ来取代的。
MQ有哪些缺点：
- 多加了一个组件
- 消息路径更长了
- 要同时保证消息不丢失和消息不重复很难
- 上游不知道下游执行的结果
