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

不念不忘少年蓝@ 2022-10-07 13:54 219阅读 0赞

**[SpringBoot集成rabbitMq入门（目录）][SpringBoot_rabbitMq]**

# 问题 #

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

# 为什么使用消息队列？ #

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

# 消息队列的优点？ #

## 解耦 ##

看一个场景，这是一个购买商城的系统，用户下单之后调用**订单系统**，之后**订单系统**要调用**库存系统**、**支付系统**、**物流系统**。  
但如果**库存系统**或者其他任意一个系统出现问题，那么整个系统流程都会出现问题。  
还有，项目经理突然想到了一个好的想法，要加一个x系统，这个时候，就要修改订单系统的代码，突然项目经理有要添加一个y系统，他想了想之后又觉得x系统不好，要删除系统，订单系统的负责人几乎崩溃… … “我不干了！！！”  
因此，在这个场景中，**订单系统**和其它各种乱七八糟的系统严重耦合，**订单系统**要时时刻刻考虑其他系统是否成功，如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70]  
这个是就可以添加MQ，**订单系统**产生的消息发送到MQ中，至于其他的就不用管了，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 1]  
**总结：**  
通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。

## 异步 ##

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

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

## 削峰 ##

平时，根本没有太多的用户访问你的网站A系统每秒最大处理1000请求根本用不完，但公司为了吸引客户搞了一个活动，在活动期间，用户的请求突然增多，每秒5000个请求，这样你的系统就会承受不住访问量，挂掉！  
用户：网站真垃圾！！！  
而你可以去找项目经理发泄心中的怒火！！！  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 4]  
但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1000 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。  
如果添加mq，就会削峰。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 5]  
只要高峰期一过，A 系统就会快速将积压的消息给解决掉。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 6]

# 消息队列的缺点？ #

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

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

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

[SpringBoot_rabbitMq]: https://blog.csdn.net/xt314159/article/details/117999149
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70]: /images/20221005/8486b1378847432cae60e636c6ea8018.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 1]: /images/20221005/e5bd4595352642a9b4a2dda1a6d0319a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 2]: /images/20221005/ca553da5859a48578a628da35cbafb36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 3]: /images/20221005/f685905dd2fd4b2bb3f2fb7eeb2b5061.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 4]: /images/20221005/4e21cac8756f43dbb4e125e0f0c5383d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 5]: /images/20221005/750fd79001ab4af393983967cd25c526.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h0MzE0MTU5_size_16_color_FFFFFF_t_70 6]: /images/20221005/d8bf4377bf5740088ca101f53ad29636.png