1、初识MQ

MQ全称是Message Queue，消息队列，多用于系统之间进行异步通信。队列的概念数据结构中有详细介绍过，先进先出，消息队列就是存储消息的数据结构。

同步调用和异步调用两者之间的区别：

同步调用：发送方需要等待接收方的响应，待接收方返回结果之后，发送方才会进行后续的处理逻辑。因此同步调用是阻塞模式。

异步调用：发送方不需要等待接收方的响应，发送方将调用消息发到接收方之后，就会继续进行后续的处理逻辑。当被调用的函数或方法执行完成后再回调处理结果。这样可以提高程序的并发性，充分利用计算机资源，提高程序的运行效率。异步调用是非阻塞模式。

其中，MQ是实现系统之间异步通信的常用方式。

如下是两种调用方式的示意图：

同步调用

异步调用

2、MQ的优势和劣势

下面介绍使用MQ的优势和劣势，其实也是对比【同步调用】和【异步调用】之间的优势劣势。

2.1 优势

2.1.1 应用解耦

考虑上述这样一个购物场景，用户在订单系统进行下单，在同步调用的方式下，订单系统会依次调用库存系统、支付系统、物流系统，并且在每个系统都返回响应结果之后，才会进行后续调用执行。其中，调用部分的代码都在订单系统中。后续如何系统进行扩展，下单的时候需要调用X系统，那么订单系统部分的代码就需要进行修改，增加X系统的调用。导致系统之间的耦合性过高，扩展极为不便。

而且，如果下单的时候，调用库存系统失败（库存系统短暂停止服务2分钟），那么后续的环节也都会执行失败。即使后面库存系统恢复服务，该笔下单也会失败。

但是如果我们借助MQ，把系统建设为异步调用的方式，订单系统把订单发布到MQ，之后订单系统继续后续的处理逻辑。库存系统、支付系统、物流系统分别订阅MQ中的消息，进行处理，之后如果需要再把X系统、Y系统纳入，订单系统也不需要进行修改，只需要加入订阅即可。这样系统之间就完成了解耦。

而且，如果下单的时候，恰好遇到库存系统短暂停止服务2分钟，也不会导致下单失败。后面库存系统恢复服务，从MQ中取出订单进行处理即可。

所以，借助MQ，我们实现了应用之间的解耦。

2.2 异步提速

还是上面的购物场景，同步调用的方式，相当于是串行执行，所以整个环节完成之后耗时920ms，对于用户来讲，会感觉到系统响应缓慢，体验不好。

但是，如果通过MQ实现异步调用，订单系统发送到MQ之后，就把“下单成功”的消息返回给用户，之后库存系统、支付系统、物流系统分别从MQ中取消息进行处理，但是这个处理MQ消息的过程我们就不用等待。整个流程的时间只有25ms，大大提升了响应速度和用户体验。

但是，如果库存系统、支付系统、物流系统中的某个系统处理的时候，判断订单不能执行，比如缺少库存怎么办？这个时候根据库存系统返回的消息，订单系统的回调函数会更新订单状态，更新为【订单下单失败，库存不足】。所以一开始返回的“下单成功”消息，更准确的来讲，应该是“下单指令发送成功”，但是订单的最终状态应该等待后面三个系统的处理结果最终决定。

2.3 削峰填谷

假设我们A系统，每秒钟最大处理1000请求，当请求突然增多，每秒钟来5000请求，就会造成积压，系统处理缓慢，用户后面发来的请求就会等待比较长的时间。

如果我们借助MQ，请求都先进入MQ，然后A系统按照自己的最大处理能力，每秒钟从MQ中取出1000个请求进行处理，系统承担的压力就会减小，消息都积压在MQ中，不会积压在系统端，超出系统的最大承受能力。

2.4 优势总结

2.2 劣势

2.2.1 系统可用性降低

引入MQ之后，系统之间的交互都通过MQ进行，MQ的稳定性非常重要，一旦MQ宕机，整个系统就会瘫痪，因此必须保证MQ的高可用。

2.2.2 系统复杂度提高

引入MQ之后，需要考虑：

消息有没有被重复消费
消息丢失怎么处理
消息传递的顺序性怎么保证

2.2.3 一致性问题

A系统通过MQ向B、C、D系统发送消息，如果B系统和C系统处理成功，D系统处理失败，消息数据处理的一致性如何保证。

2.3 总结

通过上面的介绍，我们进行总结，在什么样的场景下，我们可以选择使用MQ：

生产者不需要从消费者处获得反馈：在尚未获得反馈的情况下，不影响生产者后续的执行。
容许内容短暂的不一致性：以上面的购物场景为例，订单系统发送订单消息之后，返回下单成功的消息，但是这个时候库存系统、支付系统、物流系统尚未处理完成，库存尚未减少，账户金额尚未扣减，和下单成功的状态是不一致的。系统需要能够容许这种数据不一致的情况短暂存在。
确实有效果，且利大于弊：使用MQ的优势获得的收益，大于我们维护MQ付出的成本。