共计 1228 个字符，预计需要花费 4 分钟才能阅读完成。
大家好，我是尚影嫣🌷，一名 Java 后端程序媛。如果您喜爱我的文章，欢送点赞➕关注❤️，让咱们一起成为更好的咱们~
音讯队列的流派
一、什么是 MQ
Message Queue（MQ）是一种音讯队列中间件。MQ 真正的目标是为了通信，屏蔽底层简单的通信协定，定义了一套更简略的应用层的通信协定。分布式系统中模块之间的通信无非是 HTTP 或 TCP，这两种协定都是原始的协定，MQ 在这些协定之上构建了一个简略的“协定”—— 生产者 / 消费者模型。它定义了两个对象——生产者和消费者，生产者是发送数据方，消费者是接收数据方，提供 SDK 让咱们定义本人的生产者和消费者实现音讯通信，忽视底层通信协定。
二、有 Broker 的 MQ
这类 MQ 通常有一台服务器作为 Broker，所有的音讯都通过它进行直达。生产者只须要将音讯发送给它就实现工作了，Broker 再将音讯被动推送给消费者（或由消费者被动轮询）。
重 Topic
kafka、JMS（ActiveMQ）属于此流派，生产者会发送 key 和数据到 Broker，由 Broker 比照 key 后决定发给哪个消费者。这种模式是咱们最常见的模式，此模式中一个 topic 往往是一个较大的概念，甚至一个零碎中可能只有一个 topic，某种意义上讲 topic 就是 queue。
如上图所示，Broker 定义了三个队列，key1，key2，key3，生产者发送数据的时候会发送 key1 和 data，Broker 在推送数据的时候则推送 data（也可能带上 key）。
尽管架构一样，但 kafka 的性能要比 JMS 的性能高很多倍，所以重 Topic 类型的 MQ 优选 kafka。܉
轻 Topic
轻 Topic 的代表是 RabbitMQ（AMQP）。生产者发送 key 和数据，消费者定义订阅的队列，Broker 收到数据后，通过肯定逻辑计算出 key 对应的队列，并将数据交给队列。此模式解耦了 key 和 queue，在这种架构中 queue 是轻量级的，消费者只关怀本人的 queue，生产者不用关怀数据最终给谁，只须要指定 key 就行，两头的那层映射在 AMQP 中叫 exchange 交换机。
AMQP 中有四种 exchange：
- Direct exchange：key 等于 queue；
- Fanout exchange：忽视 key，会给所有 queue 各发一份；
- Topic exchange：key 能够用“宽字符”含糊匹配 queue；
- Headers exchange：忽视 key，通过查看音讯的头部元数据来决定发给哪个 queue。
三、无 Broker 的 MQ
无 Broker 的 MQ 的代表是 ZeroMQ。MQ 是更高级的 Socket，它是用来解决通信问题的，ZeroMQ 被设计成了一个库，而不是一个中间件，这种实现也能够达到无 Broker 的目标。
节点之间通信的音讯发送到彼此的队列中，每个节点都既是生产者又是消费者。ZeroMQ 做的事件就是封装出一套相似于 Socket 的 API，能够实现发送和读取数据。
本文参加了思否技术征文，欢送正在浏览的你也退出。
