为什么使用消息队列

使⽤消息队列主要是为了：

减少响应所需时间和削峰。
降低系统耦合性（解耦/提升系统可扩展性）。

当我们不使⽤消息队列的时候，所有的⽤户的请求会直接落到服务器，然后通过数据库或者
缓存响应。假如在⾼并发的场景下，如果没有缓存或者数据库承受不了这么⼤的压⼒的话，
就会造成响应速度缓慢，甚⾄造成数据库宕机。但是，在使⽤消息队列之后，⽤户的请求数
据发送给了消息队列之后就可以⽴即返回，再由消息队列的消费者进程从消息队列中获取数
据，异步写⼊数据库，不过要确保消息不被重复消费还要考虑到消息丢失问题。由于消息队
列服务器处理速度快于数据库，因此响应速度得到⼤幅改善。

通过以上分析我们可以得出消息队列具有很好的削峰作⽤的功能——即通过异步处理，将短
时间⾼并发产⽣的事务消息存储在消息队列中，从⽽削平⾼峰期的并发事务。举例：在电
⼦商务⼀些秒杀、促销活动中，合理使⽤消息队列可以有效抵御促销活动刚开始⼤量订单涌
⼊对系统的冲击。如下图所示：

使⽤消息队列还可以降低系统耦合性。我们知道如果模块之间不存在直接调⽤，那么新增模
块或者修改模块就对其他模块影响᫾⼩，这样系统的可扩展性⽆疑更好⼀些。

缺点:

系统可⽤性降低：系统可⽤性在某种程度上降低，为什么这样说呢？在加⼊ MQ 之
前，你不⽤考虑消息丢失或者说 MQ 挂掉等等的情况，但是，引⼊ MQ 之后你就需要
去考虑了！
系统复杂性提⾼：加⼊ MQ 之后，你需要保证消息没有被重复消费、处理消息丢失的
情况、保证消息传递的顺序性等等问题！
⼀致性问题：我上⾯讲了消息队列可以实现异步，消息队列带来的异步确实可以提⾼
系统响应速度。但是，万⼀消息的真正消费者并没有正确消费消息怎么办？这样就会导
致数据不⼀致的情况了!
消息队列都有哪些使用场景，然后你项目里具体是什么场景，在这个场景里用消息队列是什么？

消息队列常见的使用场景有很多，比较核心的有三个：解耦、异步、削峰

解耦

A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？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 给打死了，导致系统崩溃，用户也就没法再使用系统了。但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。
如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟
最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒
能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而
MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有
几十万甚至几百万的请求积压在 MQ 中。
这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系
统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压
的消息给解决掉。