“消息队列的流派”的版本间的差异

2022年8月22日 (一) 08:39的最新版本

目前消息队列的中间件选型有很多中：

RabbitMQ：功能性很强
RocketMQ：阿里开发人员参考 Kafka 实现的消息队列中间件，性能可与 Kafka 比肩，除此之外，封装了更多的功能

Kafka：全球消息处理性能最快的一款 MQ
ZeroMQ

这些消息队列中间件有什么区别？

有 broker（Kafka、RocketMQ、ActiveMQ）、无broker（zeroMQ）；

有 broker 又分重 topic（Kafka、ActiveMQ）和轻 topic（RabbitMQ）；

1.有 Broker

重 Topic：Kafka、RocketMQ、ActiveMQ

 整个 Broker，依据 topic 来进行消息的中转。在重 topic 的消息队列里必然需要 topic 的存在

轻Topic：RabbitMQ

 topic 只是一种中转模式。

2.无 Broker

在生产者和消费者之间没有使用 broker，例如 zeroMQ，直接使用 socket 进行通信

详情

@@ 第1行： / 第1行： @@
 目前消息队列的中间件选型有很多中：
-RabbitMQ
+* RabbitMQ：功能性很强
+* RocketMQ：阿里开发人员参考 Kafka 实现的消息队列中间件，性能可与 Kafka 比肩，除此之外，封装了更多的功能
-RocketMQ：阿里、参考Kafka
+* Kafka：全球消息处理性能最快的一款 MQ
+* ZeroMQ
-Kafka：全球消息处理性能最快的一款 MQ
-ZeroMQ
 这些消息队列中间件有什么区别？
@@ 第15行： / 第13行： @@
 有 broker 又分重 topic（Kafka、ActiveMQ）和轻 topic（RabbitMQ）；
-=== 有 Broker ===
-重 Topic：Kafka、RocketMQ、ActiveMQ
-整个 Broker，依据 topic 来进行消息的中转。
+=== 1.有 Broker ===
-在重 topic 的消息队列里必然需要 topic 的存在
+* 重 Topic：Kafka、RocketMQ、ActiveMQ
+  整个 Broker，依据 topic 来进行消息的中转。在重 topic 的消息队列里必然需要 topic 的存在
+* 轻Topic：RabbitMQ
-轻Topic：RabbitMQ
+  topic 只是一种中转模式。
-topic 只是一种中转模式。
-=== 无broker ===
+=== 2.无 Broker ===
 在生产者和消费者之间没有使用 broker，例如 zeroMQ，直接使用 socket 进行通信
-=== 详细 ===
-==== 什么是 MQ ====
-MessageQueue(MQ)，消息队列中间件。
-很多人都说：MQ通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是一一MQ是异步的，用来解耦的，但是这个只是MQ的效果而不是目的。
-MQ真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。
-一个分布式系统中两个模块之间通讯要么是HTTP，要么是自己开发的（rpc）TCP，但是这两种协议其实都是原始的协议。
-HTTP 协议很难实现两端通讯一一模块A可以调用B，B也可以主动调用A，如果要做到这个两端都要背上 WebServer ，而且还不支持长连接(HTTP2，0的库根本找不到）。
-TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。
-MQ 所要做的就是在这些协议之上构建一个简单的"协议<nowiki>''</nowiki>一一生产者/消费者模型。
-MQ 带来“协议”不是具体的通讯协议，而是更高层次通讯模型。
-它定义了两个对象一一发送数据的叫生产者；接收数据的叫消费者，提供一个SDK让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议
-==== 有 Broker 的 MQ ====
-这个流派通常有一台务器作为 Broker，所有的的息都过它中转。
-生产者把消息发送给它就结束自己的任务了，Broker 则把消息主动推送给消费者（或者消者主动轮询）
-===== 重 Topic =====
-Kafka、JMS(ActiveMQ）就属于这个流派，生产者会发送 key 和数据到 Broker，由 Broker 比较 key 之后决定给哪个消费者。
-这种模式是我们最常见的模式，是我们对 MQ 最多的印象。
-在这种模式下一个 topic 往往是一个比较大的概念，甚至一个系统中就可能只有一个 topic, topic 某种意义上就是 queue，生产者发送 key 相当于说：“把数据放到key的队列中”
-[[文件:重 Topic.png|无|缩略图|800x800像素]]
-如上图所示，Broker 定义了三个队列，key1，key2，key3，生产者发送数据的时候会发送 key1 和 data，Broker 在推送数据的时候则推送 data（也可能把 key 带上）。
-虽然架构一样，但是 Kafka 的性能要比 JMS 的性能不知道高多少倍，所以基本这种类型的 MQ 只有 Kafka 一种备选方案。
-如果你需要一条暴力的数据流（在乎性能多过灵活性）那么 Kafka 是最好的选择
-===== 轻 Topic =====
-这种的代表是 RabbitMQ（或者说是 AMQP）。
-生产者发送 key 和 数据，消费者定义订阅的队列，Broker 收到数据之后会通过一定的逻辑计算出 key 对应的队列，然后把数据交给队列
-[[文件:轻Topic.png|无|缩略图|1200x1200像素]]这种模式下解耦了 key 和 queue，在这种架构中 queue 是非常轻量级的（在 RabbitMQ 中它的上限取决于你的内存），消费者关心的只是自己的queue;
-生产者不必关心数据最终给谁只要指定key就行了，中间的那层映射在 AMQP 中叫exchange（交换机）
-AMQP 中有四种 exchange：
-Directexchange：key就等于queue
-Fanoutexchange：无视key,给所有的queue都来一份
-Topicexchange：key可以用宽字符“模糊匹配queue
-Headersexchange：无视key，通过查看消息的头部元数据来决定发给那个queue(AMQP头部元数据非常丰富而且可以自定义）
-这种结构的架构给通讯带来了很大的灵活性，我们能想到的通讯方式都可以用这四种exchange表达出来。
-如果你需要一个企业数据总线（在乎灵活性）那么 RabbitMQ 绝对的值得一用
-==== 无 Broker 的 MQ ====
-无 Broker 的 MQ 的代表是 ZeroMQ. 该作者非常睿智，他非常敏锐的意识到一一 MQ 是更高级的 Socket，它是解决通讯问题的。
-所以 ZeroMQ 被设计成了一个“库”而不是一个中间件，这种实现也可以达到没有Broker的目的
-[[文件:无 Broker.png|无|缩略图|730x730像素]]
-节点之间通讯的消息都是发送到彼此的队列中，每个节点都既是生产者又是消费者。
-ZeroMQ 做的事情就是圭寸装出一套类似于 Socket 的 API 可以完成发送数据，读取数据。
-ZeroMQ 其实就是一个跨语言的、重量级的 Actor 模型邮箱库。
-你可以把自己的程序想象成一个 Actor，ZeroMQ 就是提供邮箱功能的库；ZeroMQ 可以实现同一台机器的 RPC 通讯也可以实现不同机器的 TCP、UDP 通讯，如果你需要一个强大的、灵活、野蛮的通讯能
-力，别犹豫 ZeroMQ
+[[消息队列的流派 详细|详情]]

“消息队列的流派”的版本间的差异

2022年8月22日 (一) 08:39的最新版本

1.有 Broker

2.无 Broker

导航菜单

搜索