这是我参与更文挑战的第2天，活动详情查看： 更文挑战
MQ概述
MQ全称Message Queue（消息队列），实在消息的传递过程中保存消息的容器，多用于分布式系统之间的通信。
graph TD
A系统 --> MQ-->B系统
A系统生产消息 B系统消费消息 MQ消息中间件
MQ的优劣
优势
- 应用解耦
- 异步提速
- 削峰填谷 劣势
- 系统可用性降低
- 系统复杂度提高
- 一致性问题
应用解耦
graph TD
订单系统 --> 物流系统
订单系统 --> 库存系统
订单系统 --> 支付系统
用户点击按钮下订单访问订单系统，订单系统要求通知库存系统减少库存，通知支付系统支付，通知物流系统去发货。直接去通过远程调用去通知这三个系统，那么这四个系统就耦合到了一起，就会出现一些问题，比如库存系统出现问题挂了，整个过程都可能出现问题，客户通过订单系统去下单，就可能得到下单失败的反馈，系统的容错性比较低。比如新来一个需求要求下单时访问购物车系统，就得去修改订单系统的代码，这样可维护性就降低了。反观使用mq如何解决这个问题
graph TD
订单系统 --> mq
mq-->物流系统
mq-->库存系统
mq-->付系统
用户下单访问订单系统，订单系统把消息发到Mq,这时候我们就可以通知订单系统下单成功，然后下游系统从mq拿到消息消费掉。系统的容错性就提高了。再加入别的系统时，只需要新加的系统在mq拿到消息消费一下就可以了。
异步提速
原来通过远程调用的方法去处理下单之后的操作，一个系统处理完之后返回再到下一个系统，调用一个系统用时200ms,调用三个系统花费接近600ms，好不算订单系统自身处理的时间，这样用户的体验就非常的差。反观使用mq我们只需要把消息发给mq就可以返回显示下单完成，其他的处理别的系统拿到消息后自行消费，该扣库存扣库存，该发快递发快递，整个过程用时不会超过100ms，效率提升，提高系统吞吐量，用户体验极佳。
削峰填谷
还是商城系统，端午节商城做活动0.1秒杀月饼，没有mq的情况下，订单系统每秒最大可处理的访问量1000个，活动开始，50000个人都开始下单，请求全发过来，订单系统瞬间就挂了，凉凉。
graph TD
用户A --> 订单系统
用户B --> 订单系统
用户C --> 订单系统
用户3-5000 --> 订单系统
使用mq的话，mq的吞吐量时非常的大的，我们可以使用mq，让所有请求都发到mq，缓存起来，订单系统消费完一部分在继续来mq里边拿消息，避免了订单系统收到大量请求而导致挂掉，减少了流量峰值，存在mq中的消息慢慢的被消费，填谷。
graph TD
用户A --> mq
用户B --> mq
用户C --> mq
用户3-50000 --> mq
mq-->订单系统
系统可用性降低
由于引入了mq，之前我们只需要保证各个系统之间不出问题就可以完美运行，现在还需要保证mq正常运行，引入的外部依赖越多，系统却不稳定，可用性降低。
系统复杂度提高
之前是直接调用，现在通过mq，增加了系统的复杂度，怎么保证消息不被重复消费，消息丢失，传递的顺序。
一致性问题
A发消息给BCD系统处理，BC处理完成，D系统挂了，消息就不一致了。
小结
mq存在优劣势，那我们应该怎样决定使用mq呢
- 消息发送方不需要从接受方获得反馈，这才能让消费方还没走完，生产方已近完成动作。
- 允许短暂的不一致性，但最终会是一致的。
- 对系统势有益的，即好处大于坏处，解耦，性能提升，削峰填谷。
