消息队列的作用：解耦、异步、削峰

1.高度耦合场景

在上图的场景中，每次新增系统接入都需要改代码，而每次移除服务都要删除代码，耦合度太高了。

另外，A系统还要考虑其他下游系统会不会宕机后接收不到消息的问题。为此要考虑做一个重试机制？

2.MQ解耦

上图的场景中，维护这个代码：不需要考虑其他系统是否调用成功、失败超时。

3.同步高延时场景

这样一个请求全部完成，需要耗费的总时长是：820ms。

用户通过浏览器发起这个请求，等待将近1秒钟，几乎不可能接受。一般的互联网企业，对用户的直接的操作，一般要求是每个请求都必须在200ms内完成，对用户几乎是无感知的。

4.异步低延时场景

用户请求系统A到系统A发送3个消息到MQ队列，然后系统A返回。总耗时为3+5=8ms。

从感知上，只是点了一个按钮，然后就直接返回了，体验很好。

5.请求高峰负荷崩溃场景

在每天的12:00~13:00，每秒并发请求可能高达5k+，服务基于MySQL的，大量请求的进入以为对MySQL执行也达到了5k+。

一般的MYSQL支持2k的请求，当前超过2k达到5k+的请求会将MYSQL打死，导致系统崩溃，用户也就无法访问系统A了。

当高峰期过后，在线用户降低到1w左右，每秒请求回落到50~100左右，此时对MYSQL执行的请求在100以内远低于最高负载的2k，对整个系统毫无压力。

6.流量削峰场景

如果使用MQ，每秒5k+请求写入MQ，A系统每秒最多只处理2k的请求，因为MYSQL每秒最多处理2k个请求。

A系统从MQ中慢慢拉取请求，当进入12:00~13:00请求高峰期。A系统依旧按照2k的数量去拉取请求，此时大量请求会堆积在MQ的队列中无法处理。假设高峰期为1小时，将有数十上百万的请求堆积在MQ中。

对MQ而言，是可以负载这么多基于的消息的。当高峰期过后，请求回落到100左右，此时A服务依旧按照2k每秒去拉取，相较于MQ的入列数据数量而言，A服务很快就能将积压的请求处理完