为什么使用消息队列?消息对列有什么好处?

SpringBoot集成rabbitMq入门（目录）

问题

为什么使用消息队列？
消息队列的优点？
消息队列的缺点？

为什么使用消息队列？

如果你在面试的时候，面试官问你为什么要使用消息队列，其实这个问题就是就是考验你多消息队列的了解，以及要你回答，在那些业务场景中使用消息队列。
毕竟有些业务中是不需要使用消息队列的，在这些不需要使用的业务中添加消息队列对团队来说是一个坑，因为你添加了消息队列之后就必须考虑消息队列的缺点。
使用MQ之后一定要带给你好处！
先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。

消息队列的优点？

解耦

看一个场景，这是一个购买商城的系统，用户下单之后调用订单系统，之后订单系统要调用库存系统、支付系统、物流系统。
但如果库存系统或者其他任意一个系统出现问题，那么整个系统流程都会出现问题。
还有，项目经理突然想到了一个好的想法，要加一个x系统，这个时候，就要修改订单系统的代码，突然项目经理有要添加一个y系统，他想了想之后又觉得x系统不好，要删除系统，订单系统的负责人几乎崩溃… … “我不干了！！！”
因此，在这个场景中，订单系统和其它各种乱七八糟的系统严重耦合，订单系统要时时刻刻考虑其他系统是否成功，如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！

这个是就可以添加MQ，订单系统产生的消息发送到MQ中，至于其他的就不用管了，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。

总结：
通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。

异步

再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。
因为，一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。
而如果你让用户等待的时间过长，用户就会不断的刷新！最后用户：真垃圾！！！并关掉你的系统。

如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了。
用户：爽！网站做得真好，真快！

削峰

平时，根本没有太多的用户访问你的网站A系统每秒最大处理1000请求根本用不完，但公司为了吸引客户搞了一个活动，在活动期间，用户的请求突然增多，每秒5000个请求，这样你的系统就会承受不住访问量，挂掉！
用户：网站真垃圾！！！
而你可以去找项目经理发泄心中的怒火！！！

但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1000 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。
如果添加mq，就会削峰。

只要高峰期一过，A 系统就会快速将积压的消息给解决掉。

消息队列的缺点？

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰
当然，任何事情都有两面性，有优点就有缺点！
MQ的缺点有一下几个：

• 系统的可用性降低
  系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？
  如何保证消息队列的高可用。
• 系统的复杂度提高
  硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。
• 一致性问题
  A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。
  当然，这个你不加mq也同样要解决。

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。