什么时候使用消息队列

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

1.解耦：

比如说图中A系统需要给图中的BCDE系统发送消息，但是突然有一天有个F系统也想要A给它发消息呢？C有一天不想要A给他发了呢？A还要关心这些系统是不是正常的收到了消息.......每次都要改，急死了！

有没有办法解决这个问题呢？这个时候使用如果使用MQ就可以解决这个问题，采用pub/sub发布订阅消息模型。如图：

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

2.异步

比如说一个用户请求了一个A系统的某个功能，这个功能需要调用B,C,D系统的某某接口才能完全完成，但是其实有些时候用户只关心A系统的这个事有没有完成，而对整个系统功能有没有完成并不关心（有可能B,C,D这些系统只是一些相关的落库操作之类的），用户只会觉得这个怎么这么慢啊！这时候同样可以借助MQ来解决这个问题。

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

3.削峰

比如说一天之中晚上几乎没有什么业务，也就没什么请求，但是一到早上8点以后，请求就开始多起来了，一般到中午12点达到一个高峰，每秒都有5K-1w的请求量，大量的数据库写操作，数据库需要每秒执行5K-1w的SQL，这个压力可想而知，于是系统成功的挂了。系统的最大处理能力就只有每秒处理2k请求量的能力，怎么办呢？

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