谈谈你对MQ(消息中间件)的理解

昨天，有位56年工作经验的粉丝面试被问到，什么是消息中间件。平时只关注使用，并没有去总结过，竟然被这个问题住了。今天，我给大家来聊一聊。

1、什么是MQ

MQ全称是Message Queue，直译过来叫做消息队列，主要是作为分布式应用之间实现异步通信的方式。

主要由三个部分组成，分别是生产者、消息服务端和消费者。

生产者（Producer），是生产消息的一端，相当于消息的发起方，主要负责载业务信息的消息的创建。

然后是消息服务端（Server），是处理消息的单元，本质就是用来创建和保存消息队列，它主要负责消息的存储、投递以及跟消息队列相关的附加功能。消息服务端是整个消息队列最核心的组成部分。

第三个是消费者（Consumer），是消费消息的一端，主要是根据消息所承载的信息去处理各种业务逻辑。

2、MQ的应用场景

那么，我们为什么要用MQ，它能解决什么问题呢？我从以下三个方面来分析：

第一个是流量消峰，主要是针对大流量入口过大，而业务需求又要短时间响应。但是服务器性能无法满足，导致大量请求积压，从而使得客户端大量等待超时的场景。为了保证高可用，可以把大量的并行任务发送给MQ，MQ再将请求分发给其他服务器，从而平稳地处理后续的业务。起到一个大流量缓冲的作用。

举个例子，假设订单系统最大QPS是1万，这个处理能力应付正常时段在1秒内就能返回结果。但是在流量高峰期，比如促销秒杀，如果QPS达到2万，订单系统就处理不过来了，只能在超过负载后不允许用户下单。如果使用消息队列做缓冲，我们可以取消这个限制，把超出负载的订单分散成一段时间来处理，这时有些用户可能在下单十几秒后才能收到下单成功的操作，但是比不能下单的体验要好。

第二个是应用解耦

可以理解为，把一些相关的、但耦合度不高的系统关联起来，以电商应用为例，比如订单系统、库存系统、物流系统、支付系统有关联，但是有没有那么紧密。每个系统将一些约定好的消息发送到 ，另外的系统直接去消费这些消息就可以了，它可以解决不同系统之间使用不同的框架或者不同编程语言的兼容性问题，从而提高整个系统的灵活性。

第三个是异步处理

主要应用于实时性要求不严格的场景，比如用户登录发送验证码，支付成功通知等等。服务提供方（生产者）只需要将协商好的消息发送到消息队列，之后的处理就由消费者，也不需要等待消费者的返回结果。

3、如何选择MQ

目前，主流的消息中间件有ActiveMQ、RabbitMQ、Kafka、RocketMQ、Pulsar。在技术选型的时候，可以根据具体的业务需求更合适的中间件。

数据量大、吞吐量要求比较高的场景一般采用Kafka；

对消息可靠性要求很高，甚至要求支持事务的场景，比如金融互联网，可以选择RocketMQ；

对于中小型公司来说， 可以选择RabbitMQ，它利用erlang 语言本身的并发优势，性能好 在微秒级。

而Pulsar近两年开始流行起来了，它是下一代云原生分布式消息流平台，可以集消息、存储、轻量化函数式计算为一体。

至于ActiveMQ，目前的一些新项目很少有人用了。

好了，以上就是我对MQ的理解。