消息队列-为什么要使用消息队列（面试）

为什么要用消息队列？

面试官的主要目的就是为了想问问你消息队列的运用场景，在你的项目里面是怎么运用消息队列的，用来解决了什么问题。

面试官期待的回答就是：你们公司的某一个业务场景遇到了技术挑战，如果不用MQ就会很麻烦，但是用了MQ的话就会带来什么样的好处。

消息队列的运用场景：解耦、异步、削峰。

解耦：

如果一个A系统发送数据到BCD三个系统，通过接口发送。如果现在有个E系统也要接收数据，然后C系统不需要再接收数据了，这样A系统的负责人就会崩溃（大改）。具体如下图：

在上面的场景当中，A系统与其它各个系统的耦合是非常严重的。A系统在发送数据的时候需要考虑 如果接收的系统挂掉了，是重发数据还是将数据存起来？需要考虑的问题太多。

如果使用了MQ，A系统产生一条数据就发生到 MQ 里面去，其他的系统需要数据时就去 MQ 当中消费就行，如果有新的系统需要数据，也可以去 MQ 当中消费。如果系统不需要获取数据了，就不去 MQ 当中获取就行了。这样的话 A 系统就不需要考虑谁要数据，谁有没有成功收到数据，只需要往 MQ 当中生产数据就行了。具体情况如下图所示：

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

异步：

另外一个场景：A系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库。如果 A 系统本地写库的时间为 3 ms，BCD 三个系统写库的时间为 300ms、450ms、200ms。总体花费的时间为953ms，接近 1 s。用户体验就会很差，场景示意图如下：

一般互联网类的企业，对于用户的直接操作，一般要求是在200ms以内完成的，这样对用户来说几乎的无感知的。

如果在上述的场景当中运用 MQ ，A 系统连续发生3条消息到 MQ 中，假如耗时 5 ms，这样 A 系统从接收一个请求到返回响应给用户所花费的时间为 5 + 3 = 8 ms，这样对用户体验来说是极佳的。具体流程如下图：

削峰:

另一个场景：每天的 0：00 到 12：00 风平浪静的，每秒并发的请求数量为 50 个。结果一到 12：00 ~ 13：00 每秒的并发请求数量就会暴增到 5k+ ，大量的请求涌入到 MySql 。一般 MySql 的处理能力为 2k/秒。5k+ 的话 MySql 就直接GG了，进而系统也会GG，用户就没办法再使用系统了。但是到了下午的时间，就又变成了低峰期，对整个系统来说基本没什么压力。

如果接入 MQ 的话，每秒写入 5k 请求到 MQ，A 系统每秒最多就处理 2k 的请求（MySql 限制），A 系统慢慢的从 MQ 中拉取请求，每秒钟拉取 2k 左右的请求，不要超过 2k 就行了。在中午高峰期的时候每秒有 5K 左右的请求写入 MQ，但是 A 系统保持 每秒处理的请求不超过 2k，这样是没有问题的，只是有很多的数据积压在了 MQ 当中。高峰期过去以后，A 系统还是以不超过 2k/秒 的速率去消费。最后还是能将请求都消费完。