消息队列的使用场景（为什么使用消息队列）
消息队列的使用场景（3 个：解耦、异步、削峰。）
消息队列使用场景： 解耦
不适用MQ的时候
[
数据来源与多个不同的系统 实时告警信息推送
数据统一放在消息队列中供二级系统（采集服务）数据获取
]
A系统需要考虑 其中一个系统挂了怎么办？当有一个接口调用失败 ? 怎么保证数据的一致性？
数据是不是要进行持久化处理（存库）？ 数据堆积 ---->
当模式修改为使用MQ 的时候 A系统只需要产生消息 那个系统需要消息哪个系统自己去取就行了，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
总结： 通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。
消息队列使用场景： 异步
假设： A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，
自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3
+ 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器
发起请求，等待个 1s，这几乎是不可接受的。
一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，
对用户几乎是无感知的。
如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一
个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，
8ms 以后就直接返回了，爽！网站做得真好，真快！
消息队列使用场景： 削峰
每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00
，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入
MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。
一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把
MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。
如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟
最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒
能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而
MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有
几十万甚至几百万的请求积压在 MQ 中。
这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系
统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压
的消息给解决掉