为什么要使用消息队列？

为什么要使用消息队列

解耦

1.传统模式

如上图所示现在有以下几个问题：
1.假如系统A在执行SQL后需要通知系统B,C或者将数据发送系统B,C。在此基础上我们新开发了一个系统D，也同样需要系统A在执行保存SQL后通知系统D，这时，系统A就需要重新修改自己的代码也向系统D发送一条数据。如果，我们以后重新开发的系统E,F,G,H…都需要得到系统A在执行保存SQL后的数据这时我们该怎么办，难道每次都去修改系统A的代码吗？这显然是不合理的。
2.现在系统B需求改变，不再需要系统A的数据，难道每次出现这种状况都去修改系统A的代码吗？这显然也是不合理的。

2.消息中间件

系统A只需要将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。当需求改变，不再需要系统A的数据只需要自己接触与消息队列的绑定

异步

1.传统模式

A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。

2.消息中间件

如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，加快响应速度

削峰填谷

1.传统模式

一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。

2.消息中间件

如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。