1、 消息队列的使用场景
使用消息队列无外乎有三个作用：解耦、异步、削峰填谷。
下面我们详细说道下。
1.1 解耦
大家可以想想在没有消息队列的时候，我们是如何处理业务的。
我们来假设一个场景。一个系统A执行完业务后，需要将数据发送给B、C、D三个系统，我们怎么做，是不是直接调用三个系统的接口。
这样做正常是没啥问题，大家一致都是这样做的。但我们再深入想想
第一：如果B、C、D任何一个系统出问题了，是不是A系统的业务也会出问题。
第二：如果有个E系统需要A的数据，那A系统是不是又要修改代码调用E系统的接口。
所以通过MQ的发布订阅，A只管把消息扔到mq，需要的人自己去拿就可以了，代码也不用修改，和其他系统也就解耦。
1.2 异步
还是上图那个场景，A系统一个的业务操作时间，是不是A+B+C+D四个系统操作都完成后的所有操作时间总和。这样的时长对于用户可能是不可接受的。
同样通过MQ，A系统将数据扔到MQ就可以给用户及时响应，下游系统异步消费，大家都很轻松。
1.3 削峰填谷
我们的业务系统的请求量并不是稳定不变的，总会有高峰和低谷期。但我们的系统承受能力是固定，假设我们每秒只能处理2k个写mysql请求，但高峰期有6k个请求过来怎么办，是不是系统就被打垮了；或者为了系统稳定我们将服务扩容，但仅仅因为短暂的高峰期就扩容，服务器的利用率低。
所以我们同样可以利用MQ，将请求写入MQ，积压在MQ中，我们的按照固定的能力2k去慢慢消费，待到高峰一过，请求也慢慢被处理完成。
2、消息队列的缺点
万事有利有弊，MQ有很多优点，但缺点也是有的。
缺点主要有：系统可用性降低、系统复杂度提高、数据一致性问题。
2.1 可用性降低
很容易理解，按照之前的图我们只用关注ABCD四个系统是否稳定就可以，但有MQ后，万一MQ挂了呢，我们就要关注mq的高可用。
2.2 复杂度提高
引进了MQ后，我们要考虑消息的是否丢失，消息有没有被重复消费、要不要保证顺序消费。
2.3 数据一致性问题
按照之前的场景，A系统操作完成了就告诉用户成功了，但B、C、D系统消费后操作数据库失败了怎么办。
