何为MQ以及为何要用MQ

何为MQ

MQ，Message Queue，消息队列，队列是一种先进先出的数据结构，而消息队列表示对于消息的发送和接收也具有先进先出的特性。

所谓消息，就是具备一定格式（协议），携带数据的消息载体。

为何要用MQ

MQ是一直存在，不过随着分布式/微服务架构的流行，成了解决微服务之间问题的常用工具。

应用解耦

假设有系统A、B、C。

A系统要与B、C系统交互，调用B、C系统，假设没有使用MQ。使用直连调用的话。

A、B、C系统必须同时在线，否则就会调用失败。比如订单系统下单后要调用物流系统发货，但是由于物流系统宕机，导致订单系统也不能用了。

使用MQ之后：

系统A不再是直连系统B和系统C了，而是通过把消息发到MQ的某个topic或者Queue中进行存储，然后系统B、C通过订阅MQ的这个主题或者队列实现消息的接收消费。
消息的发送是消费都是异步的，所以A、B、C系统无需必须同时在线，就算B、C宕机也不影响系统A生产消息发送到MQ，就算A系统宕机，只要他生产了消息到MQ上，也不影响B、C对消息进行消费。比如订单系统下单后，往MQ发一个发货消息，然后物流系统就算当时挂了，只要重新上线之后也能接收消息，完成消息的消费。

流量削峰

当某个系统的请求量在某个时刻大大增加，有可能会把系统压垮。

假设在某个时间段系统的请求大大增加，大量的请求到了后台，可能会把数据库MySql压垮。

使用消息队列的话，可以将用户请求入队在消息队列里面，缓存起来，MQ起一个缓冲池的作用。
然后系统在自身承受范围内对用户请求从MQ中获取进行消费。

比如一个系统的正常时段QPS是1000，流量高峰时期是10000，为了应对流量高峰期采用高性能的服务器，在经济角度上来说不是很划算，此时使用MQ，对请求进行一个削峰的作用，把用户请求缓冲起来，再以一定的峰值让系统进行消费。

消息分发

假设有系统A、B、C。

假设需求改变之后，A系统不再需要调用C系统了，就要修改A系统的代码删除对C系统的调用。
假设需求改变之后，新增了一个D系统，A系统要调用D系统。此时也要修改A系统的代码增加调用D系统的代码。

使用MQ后：

假设需求改变之后，A系统不再需要调用C系统了，也无需修改A系统的代码，只需修改C系统的代码，比如取消订阅这个主题、队列等。
假设需求改变之后，新增了一个D系统，也无需修改A系统的代码，只需修改D系统代码来消费消息，比如使D系统订阅某个主题或者队列。

通过MQ可以使得消息在多个系统之间可以更加流通，数据的产生方无需知道消息由谁消费，只管把消息发送到MQ的某个topic或者queue中，数据的消费方也无需知道消息由谁产生，只管从某个topic或者queue订阅消息进行消费即可。

异步消息

可以把业务系统调用链中的非实时核心业务需求通过MQ进行异步化，提升系统吞吐量。
有A、B、C三个系统，A系统调用B系统，B系统调用C系统。
B系统的处理时间为10ms，C系统的处理时间为3s。并且C系统的业务对于操作来说并不需要实时知道结果。

比如用户注册业务：

消费端发送请求到用户系统，用户系统进行一系列判断后，往数据库的用户表添加一条数据，耗时10ms，然后用户系统调用日志系统进行日志的记录，耗时3s，假设不使用MQ，此时消费端得到响应的时间为3s又10ms。

因为日志记录并不需要实时记录，所以可以使用MQ进行异步调用。

消费端发送请求到用户系统，用户系统进行一系列判断后，往数据库的用户表添加一条数据，耗时10ms，然后用户系统往MQ上发送一条日志记录的消息，耗时1ms后，就返回响应给消费端。然后日志系统异步进行日志记录。此时消费端得到响应的时间是11ms。效率大大增加。

假设一些需求需要得到一个回调函数，使用消息总线，可以很方便解决这个问题，A调用B服务后，只需要监听B处理完成的消息，当B处理完成后，会发送一条消息给MQ，MQ会将此消息转发给A服务。

这样A服务既不用循环调用B的查询api，也不用提供callback api。同样B服务也不用做这些操作。A服务还能及时的得到异步处理成功的消息。

缺点：

系统稳定性降低：系统引用的外部依赖越多，系统的稳定性就越差，因为此时系统的稳定性不仅要收系统本身影响，还要受外部依赖的稳定性影响，比如如果MQ系统宕机了，就会对系统业务造成影响。所以MQ的高可用性选型的一个重要指标。
MQ的加入大大得增加了系统的复杂性，以前系统同步远程直连调用，现在是通过MQ进行异步调用，如何保证消息没有被重复消费、怎么处理消息丢失的情况、怎么保证消息处理的顺序正确性等。
一致性问题：A系统处理完业务后，通过MQ把发送消息给B、C、D三个系统，如果B、C系统处理成功、D系统处理失败，如何保证消息处理的一致性？
…