消息队列（一）

我们在系统中很多时候要使用消息队列，那么究竟什么时候才使用消息队列，使用消息队列会带来哪些好处，又会生出什么缺点？

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

一、解耦

A系统产生了一条数据，要发给BCD三个系统，需要调用接口来实现，那么E系统也需要这样一条数据，或者B系统不需要这样的数据了，这样的场景中，A系统和别的系统产生了严重的耦合。如果使用MQ发送一条消息，那么BCD那个系统使用，哪个系统去队列消费这条消息即可，直接把A系统从BCD等系统中解放出来。A系统压根不用考虑消息发给谁，对方处理了没有，有没有返回结果，不用去维护那么多代码。

二、异步

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

如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了。

三、削峰（秒杀相关业务）某个时间段，请求数量暴增，系统基于mysql，如果直接让大量请求直接到达mysql，直接会让mysql宕机。

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

这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。

使用MQ的缺点：

一、系统可用性降低

二、系统复杂度升高

三、一致性问题

各种Mq特性对比图如下：