image-20210804182037654

什么是消息队列

消息队列(Message Queue，简称MQ)，指保存消息的一个容器，本质是个队列。

消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。

消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。

MQ的本质

不论是RocketMQ、Kafka还是其他消息队列，它们的本质都是：一发一存一消费，再直白点就是一个转发器。

生产者先将消息投递已汇入叫做队列的容器中，然后再从这个容器中取出消息，在最后再转发给消费者，仅此而已。

image-20210804142711268

  • 生产者（Producer）：消息生产者，负责产生和发送消息到 Broker

  • 处理（Broker）：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue

  • 消费者（Consumer）：消息消费者，负责从 Broker 中获取消息，并进行相应处理

上面这个图便是消息队列最原始的模型，它包含了两个关键词：消息和队列。

  1. 消息：就是要传输的数据，可以是最简单的文本字符串，也可以是自定义的复杂格式（只要能按预定格式解析出来即可）。
  2. 队列：是一种先进先出的数据结构，它是存放消息的容器，消息从队尾入队，从队头出队，入队即发消息的过程，出队即收消息的过程。

原始模型的进化

如今最常用的消息队列产品，比如RocketMQ、Kafka等等，会发现，它们都是在原始的消息模型上做了扩展，同时提出了一些新名词，比如：主题（topic）、分区（partition）、队列（queue）等等。

要彻底理解这些五花八门的新概念，我们化繁为简，先从消息模型的演进说起（道理好比：架构从来不是设计出来的，而是演进而来的）。

1.队列模型（点对点模式，一对一）

消息队列它是一个严格意义上的队列（Queue）。消息按照什么顺序写进去，就按照什么顺序读出来。不过，队列没有”读“这个操作，读就是出队，从队头中”删除“这个消息。

image-20210804151712988

image-20210804160636666

消息生产者消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。消息被消费以后，Queue中不再有存储，所以消息消费者不可能消费到已经被消费的信息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消息者可以消费。

这便是队列模型：它允许多个生产者往同一个队列发送消息。但是，如果多个消费者，实际上是竞争关系，也就是一条消息只能被其中一个消息者接收到，读完即被删除。

2.发布-订阅模型（一对多）

如果需要将一份消息数据分发给多个消费者，并且每个消费者都要求收到全量的消息。很显然，队列模型无法满足这个需求。

一个可行的方案是：为每个消费者创建一个单独的队列，让生产者发送多份。这种做法比较笨，而且同一份数据会被复制多份，也很浪费空间。

为了解决这个问题，就演化出了另外一种消息模型：发布-订阅模型。

image-20210804154429949

在发布-订阅模型中，存放消息的容器变成了 “主题”，订阅者在接收消息之前需要先 “订阅主题”。最终，每个订阅者都可以收到同一个主题的全量消息。仔细对比下它和 “队列模式” 的异同：生产者就是发布者，队列就是主题，消费者就是订阅者，无本质区别。唯一的不同点在于：一份消息数据是否可以被多次消费。

小结

上面两种模型，说白了就是：单播和广播的区别。而且，当发布-订阅模型中只有一个订阅者的，它和队列模型就一样了，因此功能上是完全兼容队列模型的。

这也解释了为什么现代主流的 RocketMQ、Kafka 都是直接基于发布-订阅模型实现的！此外，RabbitMQ 中之所以有一个 Exchange 模块！其实也是为了解决消息的投递问题，可以变相实现发布-订阅模型。

包括大家接触到的 “消费组”、“集群消费”、“广播消费” 这些概念，都和上面这两种模型相关，以及在应用层面大家最常见的情形：组间广播、组内单播，也属于此范畴。

使用消息队列的好处

  1. 解耦
    • 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
  2. 可恢复性
    • 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
  3. 缓冲
    • 有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
  4. 灵活性&峰值处理能力
    • 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
  5. 异步通信
    • 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户一把消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再处理它们。

透过模型看MQ的应用场景

目前，MQ 的应用场景非常多，大家能倒背如流的是：系统解耦、异步通信和流量削峰。除此之外，还有延迟通知、最终一致性保证、顺序消息、流式处理等等。

那到底是先有消息模型，还是先有应用场景呢？答案肯定是：先有应用场景（也就是先有问题），再有消息模型，因为消息模型只是解决方案的抽象而已。

MQ 经过 30 多年的发展，能从最原始的队列模型发展到今天百花齐放的各种消息中间件（平台级的解决方案），我觉得万变不离其宗，还是得益于：消息模型的适配性很广。

我们试着重新理解下消息队列的模型。它其实解决的是：生产者和消费者的通信问题。那它对比 RPC 有什么联系和区别呢？

image-20210804172149486

通过对比，能很明显地看出两点差异：

  1. 引入MQ之后，由之前一次RPC变成了现在的两次RPC，而且生产者只能队列耦合，它根本无需知道消息者的存在
  2. 多了一个中间点队列进行消息转储，相当于将同步变成了异步

再返过来思考 MQ 的所有应用场景，就不难理解 MQ 为什么适用了？因为这些应用场景无外乎都利用了上面两个特性。

举一个实际例子，比如说电商业务中最常见的订单支付场景，在订单支付成功后，需要更新订单状态、更新用户积分、通知商家有新订单、更新推荐系统中的用户画像等等。

image-20210804175626814

引入 MQ 后，订单支付现在只需要关注它最重要的流程：更新订单状态即可。其他不重要的事情全部交给 MQ 来通知。这便是 MQ 解决的最核心的问题：系统解耦。

改造前订单系统依赖 3 个外部系统，改造后仅仅依赖 MQ，而且后续业务再扩展（比如：营销系统打算针对支付用户奖励优惠券），也不涉及订单系统的修改，从而保证了核心流程的稳定性，降低了维护成本。

这个改造还带来了另外一个好处：因为 MQ 的引入，更新用户积分、通知商家、更新用户画像这些步骤全部变成了异步执行，能减少订单支付的整体耗时，提升订单系统的吞吐量。这便是 MQ 的另一个典型应用场景：异步通信。

除此以外，由于队列能转储消息，对于超出系统承载能力的场景，可以用 MQ 作为 “漏斗” 进行限流保护，即所谓的流量削峰。

我们还可以利用队列本身的顺序性，来满足消息必须按顺序投递的场景；利用队列 + 定时任务来实现消息的延时消费 ……

MQ 其他的应用场景基本类似，都能回归到消息模型的特性上，找到它适用的原因，这里就不一一分析了。

总之，就是建议大家多从复杂多变的实践场景再回归到理论层面进行思考和抽象，这样能吃得更透。

作者：Lowry
链接：https://www.zhihu.com/question/54152397/answer/1802083263
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。