为什么要使用消息队列？

消息队列有三个常用的核心场景: 解耦、异步、削峰。

 

解耦

看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 D 系统现在不需要了呢？A 系统负责人几乎崩溃......

 

 

在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！

如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。

 

 

 

异步

　　A系统接收一个请求，需要在本地写库，还需要在BCD三个系统写库，自己写库需要3ms，BCD三个系统写库分别需要300ms,450ms和200ms。

最终请求总延时是3+300+450 +200 =953ms,接近1s。延迟太大了。

 

但是如果使用MQ，假设A系统连续发送3条消息到MQ队列中需要5ms，那么A系统从接受一个请求到返回响应给用户，总时长是3+5 = 8ms。对比没有使用MQ，响应时间大大缩短。

 

 

 削峰

比如外卖APP，每天接近饭店的时候请求数量就会暴增。我们假设每天非饭点的时候每秒并发请求量就50个。结果每到饭点，并发请求量突然暴增到5k+。但是系统的基于MYSQL的，一般MYSQL每秒最多执行2k个请求。因为如果不做处理则会让MYSQL挂掉。但是当高峰期过了又恢复每秒并发请求50个左右。对于系统没有压力。

 

 如果使用MQ，每秒5k个请求写入MQ，A系统每秒从MQ中拉取2k个请求。这样即使是高峰期，系统也能正常运行。

但是每秒有5k个请求进入MQ，但只有2k个被拉出。所以在高峰期可能会有几十万甚至几百万的请求积压在MQ中。

 

消息队列有什么优缺点

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。

缺点有以下几个：

1.系统可用性降低
系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整，MQ 一挂，整套系统崩溃的，你不就完了？

2.系统复杂度提高
硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。

3.一致性问题
A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

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