消息队列的流派

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

RabbitMQ

RocketMQ：阿里、参考Kafka

Kafka

ZeroMQ

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

MessageQueue(MQ)，消息队列中间件。

很多人都说：MQ通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是一一MQ是异步的，用来解耦的，但是这个只是MQ的效果而不是目的。

MQ真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。

一个分布式系统中两个模块之间通讯要么是HTTP，要么是自己开发的（rpc）TCP，但是这两种协议其实都是原始的协议。

HTTP 协议很难实现两端通讯一一模块A可以调用B，B也可以主动调用A，如果要做到这个两端都要背上 WebServer ，而且还不支持长连接(HTTP2，0的库根本找不到）。

TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。

MQ 所要做的就是在这些协议之上构建一个简单的"协议''一一生产者/消费者模型。

MQ 带来“协议”不是具体的通讯协议，而是更高层次通讯模型。

它定义了两个对象一一发送数据的叫生产者；接收数据的叫消费者，提供一个SDK让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议

这个流派通常有一台务器作为 Broker，所有的的息都过它中转。

生产者把消息发送给它就结束自己的任务了，Broker 则把消息主动推送给消费者（或者消者主动轮询）

Kafka、JMS(ActiveMQ）就属于这个流派，生产者会发送 key 和数据到 Broker，由 Broker 比较 key 之后决定给哪个消费者。

这种模式是我们最常见的模式，是我们对 MQ 最多的印象。

在这种模式下一个 topic 往往是一个比较大的概念，甚至一个系统中就可能只有一个 topic, topic 某种意义上就是 queue，生产者发送 key 相当于说：“把数据放到key的队列中”

如上图所示，Broker 定义了三个队列，key1，key2，key3，生产者发送数据的时候会发送 key1 和 data，Broker 在推送数据的时候则推送 data（也可能把 key 带上）。

虽然架构一样，但是 Kafka 的性能要比 JMS 的性能不知道高多少倍，所以基本这种类型的 MQ 只有 Kafka 一种备选方案。

如果你需要一条暴力的数据流（在乎性能多过灵活性）那么 Kafka 是最好的选择

这种的代表是 RabbitMQ（或者说是 AMQP）。

生产者发送 key 和数据，消费者定义订阅的队列，Broker 收到数据之后会通过一定的逻辑计算出 key 对应的队列，然后把数据交给队列

目录