1.为什么使用消息队列

在每天的12:00~13:00，每秒并发请求可能高达5k+，服务基于MySQL的，大量请求的进入以为对MySQL执行也达到了5k+一般的MYSQL支持2k的请求，当前超过2k达到5k+的请求会将MYSQL打死，导致系统崩溃，用户也就无法访问系统A了当高峰期过后，在线用户降低到1w左右，每秒请求回落到50~100左右，此时对MYSQL执行的请求在100以内远低于最高负载的2k，对整个系统毫无压力

5.如果哪个系统不需要某条数据就取消对MQ的消费即可

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

调用接口

系统A

3.系统B~F需要数据自己去MQ订阅消费

2.系统从MQ每秒拉取2k个请求

系统B

MQ队列

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

MySQL

A系统

2.MQ将系统A的数据发布出来

系统F

D系统

E系统

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

削峰

系统C

1.用户请求系统某个数据

异步低延时场景

用户请求系统A到系统A发送3个消息到MQ队列，然后系统A返回。总耗时为3+5=8ms从感知上，只是点了一个按钮，然后就直接返回了，体验很好

如果使用MQ，每秒5k+请求写入MQ，A系统每秒最多只处理2k的请求，因为MYSQL每秒最多处理2k个请求。A系统从MQ中慢慢拉取请求，当进入12:00~13:00请求高峰期。A系统依旧按照2k的数量去拉取请求，此时大量请求会堆积在MQ的队列中无法处理。假设高峰期为1小时，将有数十上百万的请求堆积在MQ中。对MQ而言，是可以负载这么多基于的消息的。当高峰期过后，请求回落到100左右，此时A服务依旧按照2k每秒去拉取，相较于MQ的入列数据数量而言，A服务很快就能将积压的请求处理完

1.产生一条数据，发送到MQ

为什么使用消息队列

B系统

2.系统A收到每秒5000的请求，该请求处理基于DB

2.第一步：在系统A自己本地的数据库里执行了一个SQL，花费了20ms

5.调用了系统D的接口，系统D在自己本地数据里执行了2条SQL，花费了200ms

3.调用了系统B的接口，系统B在自己本的数据库里执行了3条SQL，花费了300ms

同步高延时场景

1.每秒5k个请求

高度耦合

新接入E系统，A系统需要改代码，调用E系统

3.mysql每秒收到5k+执行请求

新加入消费

系统E

系统D

断开

MQ

4.如果新系统需要数据，自己直接从MQ订阅消费即可

请求高峰超负荷崩溃场景

4.调用了系统C的接口，系统C在自己本地数据库里执行了3条SQL，花费了300ms

维护这个代码：不需要考虑其他系统是否调用成功、失败超时

用户请求系统A

D系统移除，A系统需要改代码将调用D系统的代码删除

系统A发送消息到3个MQ队列，耗时5ms

MQ解耦

C系统

1.大量用户请求系统A