消息中间件对比

消息队列中间件

一、做用：应用解耦、弹性伸缩、冗余存储、流量削峰、异步通讯、数据同步

二、具体：

ActiveMQ ： Apache 出品的、采用 Java 语言编写的彻底基于 JMS1.1 规范的面向消息的中间件。

RabbitMQ ：采用 Erlang 语言实现的 AMQP 协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。

Kafka：起初是由 LinkedIn 公司采用 Scala 语言开发的一个分布式、多分区、多副本且基于 zookeeper 协调的分布式消息系统，现已捐献给 Apache 基金会。它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被普遍使用。目前愈来愈多的开源分布式处理系统如 Cloudera、Apache Storm、Spark、Flink 等都支持与 Kafka 集成。

RocketMQ ：阿里开源的消息中间件，目前已经捐献个 Apache 基金会，它是由 Java 语言开发的，具有高吞吐量、高可用性、适合大规模分布式系统应用等特色，经历过双 11 的洗礼，实力不容小觑。

ZeroMQ ：号称史上最快的消息队列，基于 C 语言开发。ZeroMQ 是一个消息处理队列库，可在多线程、多内核和主机之间弹性伸缩，虽然大多数时候咱们习惯将其纳入消息队列家族之中，可是其和前面的几款有着本质的区别，ZeroMQ 自己就不是一个消息队列服务器，更像是一组底层网络通信库，对原有的 Socket API 上加上一层封装而已。

其余：腾讯系的 PhxQueue、CMQ、CKafka，基于 Go 语言的 NSQ，甚至相似 Redis 的产品。

三、功能维度

优先级队列，优先级高的消息具有优先被消费的特权，若是消费者的消费速度大于生产者的速度，而且消息中间件服务器（通常简单的称之为 Broker）中没有消息堆积，那么对于发送的消息设置优先级也就没有什么实质性的意义了，由于生产者刚发送完一条消息就被消费者消费了，那么就至关于 Broker 中至多只有一条消息，对于单条消息来讲优先级是没有什么意义的。

延迟队列，当消息被发送之后，并不想让消费者马上拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费。通常分为两种：基于消息的延迟和基于队列的延迟。基于消息的延迟是指为每条消息设置不一样的延迟时间，那么每当队列中有新消息进入的时候就会从新根据延迟时间排序，固然这也会对性能形成极大的影响。实际应用中大多采用基于队列的延迟，设置不一样延迟级别的队列，好比 5s、10s、30s、1min、5mins、10mins 等，每一个队列中消息的延迟时间都是相同的，这样免去了延迟排序所要承受的性能之苦，经过必定的扫描策略（好比定时）便可投递超时的消息。

死信队列/回退队列/重试队列，消息第一次消费失败入重试队列 Q1，Q1 的从新投递延迟为 5s，在 5s 事后从新投递该消息；若是消息再次消费失败则入重试队列 Q2，Q2 的从新投递延迟为 10s，在 10s 事后再次投递该消息。以此类推，重试越屡次从新投递的时间就越久，为此须要设置一个上限，超过投递次数就入死信队列。重试队列与延迟队列有相同的地方，都是须要设置延迟级别，它们彼此的区别是：延迟队列动做由内部触发，重试队列动做由外部消费端触发；延迟队列做用一次，而重试队列的做用范围会向后传递。

消费模式，分为推（push）模式和拉（pull）模式。推模式是指由 Broker 主动推送消息至消费端，实时性较好，不过须要必定的流制机制来确保服务端推送过来的消息不会压垮消费端。而拉模式是指消费端主动向 Broker 端请求拉取（通常是定时或者定量）消息，实时性较推模式差，可是能够根据自身的处理能力而控制拉取的消息量。

广播消费，通常有两种传递模式：点对点（P2P，Point-to-Point）模式和发布 / 订阅（Pub/Sub）模式。对于点对点的模式而言，消息被消费之后，队列中不会再存储，因此消息消费者不可能消费到已经被消费的消息。虽然队列能够支持多个消费者，可是一条消息只会被一个消费者消费。发布订阅模式定义了如何向一个内容节点发布和订阅消息，这个内容节点称为主题（topic），主题能够认为是消息传递的中介，消息发布者将消息发布到某个主题，而消息订阅者则从主题中订阅消息。主题使得消息的订阅者与消息的发布者互相保持独立，不须要进行接触便可保证消息的传递，发布 / 订阅模式在消息的一对多广播时采用。RabbitMQ 是一种典型的点对点模式，而 Kafka 是一种典型的发布订阅模式。可是 RabbitMQ 中能够经过设置交换器类型来实现发布订阅模式而达到广播消费的效果，Kafka 中也能以点对点的形式消费，你彻底能够把其消费组（consumer group）的概念当作是队列的概念。不过对比来讲，Kafka 中由于有了消息回溯功能的存在，对于广播消费的力度支持比 RabbitMQ 的要强。

消息回溯，……