MQ----为什么使用MQ，MQ的优点和缺点呢?

为什么使用MQ?

文章引用地址：
感谢前辈分享
https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/why-mq.md

为什么使用MQ?就是说我们因为了什么所以使用了MQ
我们使用MQ都是为了我们的业务，因为业务上有个什么场景，因此使用了MQ。
MQ中进场使用的三种场景是，解耦，异步，削峰

首先是解耦

有这样的一个场景，ABCD一共有四个系统，A系统通过接口将数据发送给BCD，此时如果新来了一个E系统也要求放数据，D系统说自己不需要了，这个时候A系统很奔溃

这个场景之下，A系统和其他各种系统的耦合相当严重，A系统要时刻考虑到BCDE四个系统，考虑他们能否接收数据，如果系统挂了，数据要不要重发。

这个时候MQ出现了，A系统产生一条数据发送到MQ中，哪个系统需要数据自己去MQ中消费，哪个系统不需要数据了就不对MQ消费，这样就A系统就不需要考虑给谁发送数据不给谁发，也不用考虑其他的系统是否成功的接收了信息，失败超时了怎么办

这样子A系统就达到了解耦的效果，我们使用MQ就是给他进行了异步解耦。

其次是异步

有这样的一个场景，A系统接收到了一个请求，需要在本地写库自己写库的时间是3ms，还需要在BCD三个系统中写库300ms、450ms、200ms，注意，这里是写库，这个时候入过等待写完将会浪费很长时间，这是不能接收的。

这时候如果使用MQ，A系统将请求发送到MQ中，注意这里是三个MQ（因为MQ内部也是一个queue，不能等一个执行完之后再执行下一个），三个MQ将消息接收到，之后响应给A，总共用时5ms，然后BCD的写入操作在后台执行进行

这种情况下，系统接收到请求之后，将请求发送给MQ,MQ接收到信息之后就完成了这个 请求，之后再由其他系统执行MQ的请求，这样就是异步

最后是削峰

每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。
这个时候如果使用MQ，每秒中由5k个请求写入MQ中，A系统每一秒处理2k个请求，A系统慢慢的拉去请求，这个时候，Mysql就能够在自己的承受范围之内，哪怕是高峰期也不会挂掉。但是这种情况下可能造成在MQ中挤压了很多的请求。

这中高峰期时候短暂的积压是可以的，因为高峰期之后又会恢复正常。
MQ的好处总结就是，解耦，异步，削峰
缺点呢？
我们在原先的系统中增加了一个模块，这个系统的复杂性提高，MQ在系统中起重要作用，如果MQ挂掉了整套系统就崩溃了，可用性低，MQ怎么保证系统传来的信息没有被重复的消费，消息没有丢失，消息传递的顺序性，A系统给MQ发送完请求就直接返回成功了，哪我们怎么知道其他执行MQ的系统是否执行成功了？

这就存在几个重要问题

系统复杂性
MQ挂掉了怎么保证可用性
怎么保证消息没有被重复消费，怎么保证消息没有丢失，怎么保证消息的顺序性
怎那么保证MQ的中的消息是被所有的系统已经执行完的一致性问题