为什么使用消息队列？

为什么使用消息队列？

消息队列常见的使用场景有很多，但是比较核心有3个：解耦、异步、削峰

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

在这个场景中，A系统跟其他各种系统严重耦合，A系统产生比较关键数据很多系统都需要A系统将数据发送过来。A系统时时刻刻还要考虑BCDE四个系统如果挂了怎么办？要不要重新发送，要不要把消息存起来。 如果使用MQ系统产生一条数据发送到MQ里面去，哪个系统需要自己去MQ里面消费，如果系统需要直接从MQ里消费，如果某系统不需要数据，就取消对MQ消费即可，这样A系统需要考虑给谁发送数据，不需要维护这个代码，也不需要考虑是否调用成功、失败 超时等情况。

异步：场景如下，A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己写库就要3ms，BCD三个库中要分别写库要300ms、450ms、200ms。最终请求时间接近1s，用户感觉搞个什么东西，慢死了，用户通过浏览器发起请求等待1s，几乎是不接受的。

一般互联网的企业，对于用户直接操作，一般要求都必须在200ms以内完成，对用户几乎是无感。 如果使用MQ，那么A系统连续发送三条消息到MQ队列中，假如耗时6ms，A系统接收一个请求反应给用户总时长9ms对于用户而言，感觉点击按钮就返回，真快。

削峰：假如每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃。

如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 请求，不要超过自己每秒能处理的最大请求数量，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ中。