谈谈消息队列的流派

关于 MQ 的定义

Message Queue（MQ）消息队列中间件，一般咱们在网上看到的对其定义是将消息的发送和接受分离来实现应用程序的异步和解耦，给人的直觉是 MQ 是异步的，用来解耦的。但这个只是 MQ 的效果，而不是目的。MQ 真正的目的是为了通信，屏蔽底层复杂的通信协议，定义了一套应用层上更加简单的通信协议。

一套分布式系统中两个模块之间通信要么是 HTTP，要么是 TCP，但这两种协议其实都是原始的协议。前者实现通信就必需要作到各客户端都有 WebServer，并且不支持长链接；后者就更加原始了 — 粘包、心跳、私有的协议。

而 MQ 所要作就是在基于这些现有的协议之上构建一个更简单的通信（生产者/消费者）模型。它定义了两个对象 —发送数据的叫生产者，接受数据的叫消费者，提供一个 SDK 给咱们本身定义生产者和消费者实现消息通信，且无视底层通信协议。

带 Broker 的流派

这个流派一般有一台服务器做为 Broker，全部的消息都经过它进行中转。生产者把消息发送给它就结束本身的任务了，最后 Broker 则把消息主动推送给消费者（或者消费者主动轮询）。

重 Topic 的 MQ

Kafka、Active MQ 就属于这个流派：生产者发送 key 和数据到 Broker，由 Broker 比较 key 以后决定给哪一个消费者。

在这种模式下，Topic（主题消息） 每每是一个比较大的概念，甚至一个系统中就可能只有一个 Topic。

虽然这两种消息队列的架构同样，可是 Kafka 的性能要比 Active MQ 的性能不知道高到多少倍，因此基本这种类型的 MQ 只有 Kafka一种备选方案。

轻 Topic 的 MQ

这种的表明是 RabbitMQ（AMQP）。生产者发送 key 和数据，Borker 收到数据以后会根据 key 经过必定的逻辑计算出相应的队列，最后消费者订阅队列。

在这种架构中 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 的目的。

各节点之间的通信都是发送到彼此的队列中，每一个节点便是生产者也是消费者。相似于一套 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！