什么是消息队列MQ？

一、MQ是什么？

MQ全称Message Queue，中文名称消息队列。顾名思义，它就是一个队列，简单来说就是一个应用程序A将数据丢到一个队列中，由另一个应用程序B从队列中拿到这个数据，再去做一些其他的业务操作。我们把应用程序A叫做生产者，应用程序B叫做消费者，它们之间传输的数据称作消息。

那相比"程序A通过调用接口的方式直接将数据传给B"，引入一个队列有什么好处呢？接着往下看MQ的使用场景。

二、MQ的使用场景

解耦

假设系统A通过调用接口推送数据给B、C、D，如果后续系统E也需要被推送、或者B不再需要被推送呢？那我们就需要修改系统A的代码，加上给E推送数据的逻辑，去掉给B推送数据的逻辑。显然A系统和其他系统严重耦合，在这个场景中，如果使用 MQ，通过发布订阅模型，就可以实现A和其他系统的解耦。A 产生一条数据，发送到 MQ ，哪个系统需要就去订阅消费，如果某个系统不再需要，取消对消息的订阅即可。

异步

将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。

实例：之前有一个项目，用户在后台上传PPT，系统先将PPT保存到文件服务器，拿到PPT的地址再调用拆图服务，将PPT拆分成一张张的图片，拆分后将图片地址保存到数据库，因为拆图操作比较耗时，整个过程大约得要十几秒。

那像这种耗时的操作，如果操作员在上传PPT的时候，先不说接口超不超时的问题，就光页面卡在哪里十几秒，谁能受得了？所以当时就用到了消息队列，上传PPT成功，就给用户返回成功，将PPT的服务器地址丢到队列中，消费者拿到地址再去做拆图操作，如果消费失败再补偿重试，重试3次仍失败，则触发邮件报警。

这个场景对于生产者而言，你不用知道具体的消费者是谁、在哪。你要做的只是将消息向你们约定好的地址进行发送，你的任务就完成了。对应的服务自然能监听到你发送的消息，进行后续的操作。这就是消息队列最大的特点，将同步操作转为异步处理。

削峰限流

商城秒杀活动我们都不陌生，对于商城系统，可能在0点左右会有个短暂的高峰期，但其余时间的并发量也没那么高，假如我们的后台系统直接操作数据库，平时可能没什么问题，但如果突然有很高的的并发量进来，就会因为MySQL并发量过大导致系统瘫痪。

如果使用MQ，请求会短期积压在MQ中，后台系统从MQ中分批拉取消息，从而保证数据库不会被压垮。等高峰期一过，系统就会将MQ中积压的消息慢慢解决掉。这就是MQ的"削峰限流"作用。

三、引入MQ对系统的影响

1、系统的可用性降低

系统的可用性是指系统服务不中断运行的时间占实际运行时间的比例。高可用就是指系统服务不中断运行时间占实际运行时间的比例大。

系统引入的外部依赖越多，越容易挂掉，所以引入MQ后系统的可用性可能会降低。

2、系统的复杂度增加

引入MQ以后要多考虑很多方面的问题，比如怎么保证消息的可靠传输、怎么保证消息的幂等性等，提高了系统的复杂度。

本文到这里就结束啦，对消息中间件感兴趣的小伙伴请持续关注后续的推文。