共计 1433 个字符，预计需要花费 4 分钟才能阅读完成。
对于 MQ 的定义
Message Queue（MQ）音讯队列中间件，通常咱们在网上看到的对其定义是将音讯的发送和承受拆散来实现应用程序的异步和解耦，给人的直觉是 MQ 是异步的，用来解耦的。但这个只是 MQ 的成果，而不是目标。MQ 真正的目标是为了通信，屏蔽底层简单的通信协定，定义了一套应用层上更加简略的通信协定。
一套分布式系统中两个模块之间通信要么是 HTTP，要么是 TCP，但这两种协定其实都是原始的协定。前者实现通信就必须要做到各客户端都有 WebServer，而且不反对长连贯；后者就更加原始了 — 粘包、心跳、公有的协定。
而 MQ 所要做就是在基于这些现有的协定之上构建一个更简略的通信（生产者 / 消费者）模型。它定义了两个对象 —发送数据的叫生产者，承受数据的叫消费者，提供一个 SDK 给咱们本人定义生产者和消费者实现音讯通信，且忽视底层通信协定。
带 Broker 的流派
这个流派通常有一台服务器作为 Broker，所有的音讯都通过它进行直达。生产者把音讯发送给它就完结本人的工作了，最初 Broker 则把音讯被动推送给消费者（或者消费者被动轮询）。
重 Topic 的 MQ
Kafka、Active MQ 就属于这个流派：生产者发送 key 和数据到 Broker，由 Broker 比拟 key 之后决定给哪个消费者。
.png)
在这种模式下，Topic（主题音讯） 往往是一个比拟大的概念，甚至一个零碎中就可能只有一个 Topic。
尽管这两种音讯队列的架构一样，然而 Kafka 的性能要比 Active MQ 的性能不晓得高到多少倍，所以根本这种类型的 MQ 只有 Kafka 一种备选计划。
轻 Topic 的 MQ
这种的代表是 RabbitMQ（AMQP）。生产者发送 key 和数据，Borker 收到数据之后会依据 key 通过肯定的逻辑计算出相应的队列，最初消费者订阅队列。
.png)
在这种架构中 Queue 是十分轻量级的（在 RabbitMQ 中它的下限取决于你的内存），消费者关怀的只是本人的 Queue；生产者不用关怀数据最终给谁，只有指定 key 就行了。两头的那层映射在 AMQP 中叫 exchange（交换机）。
AMQP 中有四种 exchange：
Direct exchange：key等于queue。Fanout exchange：忽视key，给所有的queue都来一份。Topic exchange：key能够用“宽字符”含糊匹配queue。Headers exchange：忽视key，通过查看音讯的头部元数据来决定发给哪个queue。
这种架构给通信带来了极大的灵活性，咱们能想到的通信形式都能够用这四种 exchange 表达出来。
不带 Broker 的流派
ZeroMQ
不带 Broker 的 MQ 代表就是 ZeroMQ。能够说是解决通信问题的更高级 Socket，它被设计成了一个“库”而不是一个中间件，这种实现也能够达到没有 Broker 的目标。
.png)
各节点之间的通信都是发送到彼此的队列中，每个节点即是生产者也是消费者。相似于一套 Socket 的 API，能够实现发送和读取数据。
- 文章作者：彭超
- 本文首发于集体博客：https://antoniopeng.com/2020/06/15/mq/%E8%B0%88%E8%B0%88%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97%E7%9A%84%E6%B5%81%E6%B4%BE/
- 版权申明：本博客所有文章除特地申明外，均采纳 CC BY-NC-SA 4.0 许可协定。转载请注明来自 彭超 | Blog！
