开源消息中间件的盘点
2018-11-25 09:10:46 
阿炯
消息队列(MQ)概述
消息队列(Message Queue)，是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。消息队列主要解决了应用耦合、异步处理、流量削锋等问题。当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。
1、消息中间件介绍
一般，我们认为消息中间件是指支持与保障分布式应用程序之间同步/异步收发消息的中间件。消息是分布式应用之间进行数据交换的基本信息单位，分布式应用程序之间的通信接口由消息中间件提供。其中，异步方式指消息发送方在发送消息时不必知道接收方的状态，更无需等待接收方的回复，而接收方在收到消息时也不必知道发送方的目前状态，更无需进行同步的消息处理，它们之间的连接完全是松耦合的，通信是非阻塞的，这种异步通信方式是由消息中间件中的消息队列及其服务机制保障的。一般地，实时性要求较高的业务采用同步方式处理，实时性要求不高的业务采用异步方式进行处理。
消息中间件已广泛应用于各类分布式应用系统，消息中间件开始向发布/订阅架构转变，并成为企业应用集成中间件的一种核心机制，而基于发布/订阅架构的消息中间件通常称为发布/订阅消息中间件或消息代理。目前比较典型的消息中间件包括IBM WebSphere MQSeries、阿里的RocketMQ和Kafka等。消息中间件是在消息的传输过程中保存信息的容器。消息中间件再将消息从它的源中继到它的目标时充当中间人的作用。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它为止，当然，消息队列保存消息也是有期限的。
2、消息中间件的特点
2.1 采用异步处理模式
消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道(主题或队列)上，消息接收者则订阅或是监听该通道。一条信息可能最终转发给一个或多个消息接收者，这些接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
2.2 应用程序和应用程序调用关系为松耦合关系
主要体现在如下两点：
(1)发送者和接受者不必了解对方、只需要确认消息
(2)发送者和接受者不必同时在线
比如在线交易系统为了保证数据的最终一致，在支付系统处理完成后会把支付结果放到消息中间件里通知订单系统修改订单支付状态。两个系统通过消息中间件解耦。
3、消息传递服务模型
4、消息中间件的传输模式
4.1 点对点模型
点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对于消费服务中的一个队列(Queue)，在消息传递给消费者之前它被存储在这个队列中。队列消息可以放在内存中也可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。传统的点对点消息中间件通常由消息队列服务、消息传递服务、消息队列和消息应用程序接口API组成。
特点：
(1)每个消息只用一个消费者
(2)发送者和接受者没有时间依赖
(3)接受者确认消息接受和处理成功
4.2 发布-订阅模型(Pub/Sub)
发布者/订阅者模型支持向一个特定的消息主题生产消息。0或多个订阅者可能对接收来自特定消息主题的消息感兴趣。在这种模型下，发布者和订阅者彼此不知道对方。这种模式就好比是匿名公告板。这种模式被概况为：多个消费者可以获得消息，在发布者和订阅者之间存在时间依赖性。发布者需要建立一个订阅(subscription)，以便能够消费者订阅。订阅者必须保持持续的活动状态及接收消息，除非订阅者建立了持久的订阅。在这种情况下，在订阅者未连接时发布的消息将在订阅者重新连接时重新发布。
发布/订阅模型特性
(1)每个消息可以有多个订阅者
(2)客户端只有订阅后才能接收到消息
(3)持久订阅和非持久订阅
注意：
(1)发布者和订阅者有时间依赖
接受者和发布者只有建立订阅关系才能收到消息
(2)持久订阅
订阅关系建立后，消息就不会消失，不管订阅者是否都在线
(3)非持久订阅
订阅者为了接受消息，必须一直在线
当只有一个订阅者时约等于点对点模式
5、消息中间件应用场景
5.1 用户注册异步处理
网站用户注册，注册成功后会过一会发送邮件确认或者短息。
5.2 日志分析使用
把日志进行集中收集，用于计算PV、用户行为分析。
5.3 数据复制
(1)将数据从源头复制到多个目的地，一般是要求顺序或者保证因果序列
(2)用于跨机房数据传输、搜索、离线数据计算等。
5.4 延迟消息发送和暂存
(1)把消息中间件当成可靠的消息暂存地
(2)定时进行消息投递，比如模拟用户秒杀访问，进行系统性能压测
5.5 消息广播
(1)缓存数据同步更新
(2)往应用推送数据
比如更新本地缓存。
6、消息中间件消息模型分类
6.1 push推消息模型
消息生产者将消息发送给消息传递服务，消息传递服务又将消息推给消息消费者。
6.2 pull拉消息模型
消费者请求消息服务接受消息，消息生产者从消息中间件拉该消息。
6.3 两种类型的区别
push推消息和pull拉消息的区别
消息队列使用场景
消息队列在实际应用中包括如下四个场景：
应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理。
消息队列的两种模式
消息队列包括两种模式，点对点模式(point to point， queue)和发布/订阅模式(publish/subscribe，topic)。
点对点模式
点对点模式下包括三个角色：
消息队列
发送者(生产者)
接收者(消费者)
消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。
点对点模式特点：
每个消息只有一个接收者(Consumer)(即一旦被消费，消息就不再在消息队列中)；
发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；
接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；
发布/订阅模式
发布/订阅模式下包括三个角色：
角色主题(Topic)
发布者(Publisher)
订阅者(Subscriber)
发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
发布/订阅模式特点：
每个消息可以有多个订阅者；
发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息；
为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行。
开源消息系统，被广泛地应用在数据缓冲、异步通信、汇集日志、系统解耦等方面。常见的消息中间件有像RabbitMQ、ActiveMQ、ZeroMQ、Kafka、Redis等。
RabbitMQ
RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
Redis
Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
ZeroMQ
ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输(Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块)。
ActiveMQ
ActiveMQ是Apache下的一个子项目。类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。
Kafka/Jafka
Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
从可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统、社区来看，RabbitMq最好，ActiveMq次之，ZeroMq最差。当然ZeroMq也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。所以在可靠性和可用性上，RabbitMQ是首选，虽然ActiveMQ也具备，但是它性能不及RabbitMQ。从实现语言来看，RabbitMQ最高，原因是它的实现语言是天生具备高并发高可用的erlang语言。
Kafka
Kafka在保障了大部分功能特性的同时，还提供了超一流的读写性能。下面介绍一下Kafka的架构和涉及到的名词：
Topic：用于划分Message的逻辑概念，一个Topic可以分布在多个Broker上。
Partition：是Kafka中横向扩展和一切并行化的基础，每个Topic都至少被切分为1个Partition。
Offset：消息在Partition中的编号，编号顺序不跨Partition。
Consumer：用于从Broker中取出/消费Message。
Producer：用于往Broker中发送/生产Message。
Replication：Kafka支持以Partition为单位对Message进行冗余备份，每个Partition都可以配置至少1个Replication(当仅1个Replication时即仅该Partition本身)。
Leader：每个Replication集合中的Partition都会选出一个唯一的Leader，所有的读写请求都由Leader处理。其他Replicas从Leader处把数据更新同步到本地，过程类似大家熟悉的MySQL中的Binlog同步。
Broker：Kafka中使用Broker来接受Producer和Consumer的请求，并把Message持久化到本地磁盘。每个Cluster当中会选举出一个Broker来担任Controller，负责处理Partition的Leader选举，协调Partition迁移等工作。
ISR(In-Sync Replica)：是Replicas的一个子集，表示目前Alive且与Leader能够“Catch-up”的Replicas集合。由于读写都是首先落到Leader上，所以一般来说通过同步机制从Leader上拉取数据的Replica都会和Leader有一些延迟(包括了延迟时间和延迟条数两个维度)，任意一个超过阈值都会把该Replica踢出ISR。每个Partition都有它自己独立的ISR。
Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：
以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。
高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。
支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。
同时支持离线数据处理和实时数据处理。
支持在线水平扩展。
Kafka的高容错性是如何保证的？
producer不使用批量接口，并采用同步模型持久化消息。
consumer不采用批量化，每消费一次就更新offset。
与传统的mq的区别？
更快！单机可有上万TPS；传统的MQ，消息被消化掉后会被mq删除，而kafka中消息被消化后不会被删除，而是到配置的expire时间后才删除。
传统的MQ，消息的Offset是由MQ维护，而kafka中消息的Offset是由客户端自己维护。
分布式，把写入压力均摊到各个节点。可以通过增加节点降低压力。
与传统MQ的方式的基本术语对比
Producer
Consumer
这两个与传统的MQ一样，就不解释了。
Topic
Kafka中的topic其实对应传统MQ的channel，即消息管道，例如同一业务用同一根管道。
Broker
集群中的KafkaServer，用来提供Partition服务。
Partition
假如说传统的MQ，传输消息的通道(channel)是一条双车道公路，那么Kafka中，Topic就是一个N车道的高速公路。每个车道都可以行车，而每个车道就是Partition。
一个Topic中可以有一个或多个partition。
一个Broker上可以跑一个或多个Partition。集群中尽量保证partition的均匀分布，例如定义了一个有3个partition的topic，而只有两个broker，那么一个broker上跑两个partition，而另一个是1个。但是如果有3个broker，必然是3个broker上各跑一个partition。
Partition中严格按照消息进入的顺序排序
一个从Producer发送来的消息，只会进入Topic的某一个Partition(除非特殊实现Producer要求消息进入所有Partition)
Consumer可以自己决定从哪个Partition读取数据
Offset
单个Partition中的消息的顺序ID，例如第一个进入的Offset为0，第二个为1，以此类推。传统的MQ，Offset是由MQ自己维护，而kafka是由client维护。
Replica
Kafka从0.8版本开始，支持消息的HA，通过消息复制的方式。在创建时，我们可以指定一个topic有几个partition，以及每个partition有几个复制。复制的过程有同步和异步两种，根据性能需要选取。正常情况下，写和读都是访问leader，只有当leader挂掉或者手动要求重新选举，kafka会从几个复制中选举新的leader。
Kafka会统计replica与leader的同步情况。当一个replica与leader数据相差不大，会被认为是一个"in-sync" replica。只有"in-sync" replica才有资格参与重新选举。
ConsumerGroup
一个或多个Consumer构成一个ConsumerGroup，一个消息应该只能被同一个ConsumerGroup中的一个Consumer消化掉，但是可以同时发送到不同ConsumerGroup。通常的做法是一个Consumer去对应一个Partition。
传统MQ中有queuing(消息)和publish-subscribe(订阅)模式，Kafka中也支持：
当所有Consumer具有相同的ConsumerGroup时，该ConsumerGroup中只有一个Consumer能收到消息，就是 queuing 模式
当所有Consumer具有不同的ConsumerGroup时，每个ConsumerGroup会收到相同的消息，就是 publish-subscribe 模式
Kafka和RabbitMQ的比较，最权威的的是kafka的提交者写一篇文章。
RabbitMq比kafka成熟，在可用性、稳定性、可靠性上，RabbitMq超过kafka。Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性。
Kafka的性能(吞吐量、tps)比RabbitMq要强，这篇文章的作者认为，两者在这方面没有可比性。 kafaka比redis pub/sub更加可靠，后者有数据丢失的风险，因为后者是用一次就丢弃的模式，而kafaka会有数据持久化处理。而且kafaka对超大量的数据处理支持远好过redis pub/sub。redis的优势是速度比较快，但是kafaka已经很快了。所以kafaka更符合大数据的实时计算场景。kafka 所有的数据保存在文件系统中，redis主要提供丰富的内存中数据结构，持久化方面性能并不好。kafka更适合消息队列的场景，有更强的稳健性和部署性，完全没必要用redis来替换kafka。
常用消息队列介绍
本部分主要介绍四种常用的消息队列(RabbitMQ/ActiveMQ/RocketMQ/Kafka)的主要特性、优点、缺点。
1、RabbitMQ
RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
主要特性：
可靠性：提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制；
灵活的路由： 消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做RabbitMQ的插件来使用；
消息集群：在相同局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个独立的逻辑代理来使用；
队列高可用：队列可以在集群中的机器上进行镜像，以确保在硬件问题下还保证消息安全；
多种协议的支持：支持多种消息队列协议；
服务器端用Erlang语言编写，支持只要是你能想到的所有编程语言；
管理界面: RabbitMQ有一个易用的用户界面，使得用户可以监控和管理消息Broker的许多方面；
跟踪机制：如果消息异常，RabbitMQ提供消息跟踪机制，使用者可以找出发生了什么；
插件机制：提供了许多插件，来从多方面进行扩展，也可以编写自己的插件；
使用RabbitMQ需要：
ErLang语言包
RabbitMQ安装包
RabbitMQ可以运行在Erlang语言所支持的平台之上。
优点：
由于erlang语言的特性，mq 性能较好，高并发；
健壮、稳定、易用、跨平台、支持多种语言、文档齐全；
有消息确认机制和持久化机制，可靠性高；
高度可定制的路由；
管理界面较丰富，在互联网公司也有较大规模的应用；
社区活跃度高；
缺点：
尽管结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护；
实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，但是使得其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大；
需要学习比较复杂的接口和协议，学习和维护成本较高；
2、ActiveMQ
ActiveMQ是由Apache出品，ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。
主要特性：
服从 JMS 规范：JMS 规范提供了良好的标准和保证，包括：同步或异步的消息分发，一次和仅一次的消息分发，消息接收和订阅等等。遵从 JMS 规范的好处在于，不论使用什么 JMS 实现提供者，这些基础特性都是可用的；
连接性：ActiveMQ 提供了广泛的连接选项，支持的协议有：HTTP/S，IP 多播，SSL，STOMP，TCP，UDP，XMPP等等。对众多协议的支持让 ActiveMQ 拥有了很好的灵活性。
支持的协议种类多：OpenWire、STOMP、REST、XMPP、AMQP ；
持久化插件和安全插件：ActiveMQ 提供了多种持久化选择。而且，ActiveMQ 的安全性也可以完全依据用户需求进行自定义鉴权和授权；
支持的客户端语言种类多：除了 Java 之外，还有：C/C++，.NET，Perl，PHP，Python，Ruby；
代理集群：多个 ActiveMQ 代理可以组成一个集群来提供服务；
异常简单的管理：ActiveMQ 是以开发者思维被设计的。所以它并不需要专门的管理员，因为它提供了简单又使用的管理特性。有很多中方法可以监控 ActiveMQ 不同层面的数据，包括使用在 JConsole 或者 ActiveMQ 的Web Console 中使用 JMX，通过处理 JMX 的告警消息，通过使用命令行脚本，甚至可以通过监控各种类型的日志。
使用ActiveMQ需要：
Java JDK
ActiveMQ安装包
ActiveMQ可以运行在Java语言所支持的平台之上。
优点：
跨平台(JAVA编写与平台无关有，ActiveMQ几乎可以运行在任何的JVM上)
可以用JDBC：可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能，但是数据库一直都是开发人员最熟悉的存储介质。将消息存到数据库，看得见摸得着。而且公司有专门的DBA去对数据库进行调优，主从分离；
支持JMS ：支持JMS的统一接口;
支持自动重连；
有安全机制：支持基于shiro，jaas等多种安全配置机制，可以对Queue/Topic进行认证和授权。
监控完善：拥有完善的监控，包括Web Console，JMX，Shell命令行，Jolokia的REST API；
界面友善：提供的Web Console可以满足大部分情况，还有很多第三方的组件可以使用，如hawtio；
缺点：
社区活跃度不及RabbitMQ高；
根据其他用户反馈，会出莫名其妙的问题，会丢失消息；
目前重心放到activemq6.0产品-apollo，对5.x的维护较少；
不适合用于上千个队列的应用场景；
3、RocketMQ
RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。
主要特性：
是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点；
Producer、Consumer、队列都可以分布式；
Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合；
能够保证严格的消息顺序；
提供丰富的消息拉取模式；
高效的订阅者水平扩展能力；
实时的消息订阅机制；
亿级消息堆积能力；
较少的依赖；
使用RocketMQ需要：
Java JDK
安装git、Maven
RocketMQ安装包
RocketMQ可以运行在Java语言所支持的平台之上。
优点：
单机支持 1 万以上持久化队列
RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，访问时，直接从内存读取。
模型简单，接口易用(JMS 的接口很多场合并不太实用)；
性能非常好，可以大量堆积消息在broker中；
支持多种消费，包括集群消费、广播消费等。
各个环节分布式扩展设计，主从HA；
开发度较活跃，版本更新很快。
缺点：
支持的客户端语言不多，目前是java及c++，其中c++不成熟；
RocketMQ社区关注度及成熟度也不及前两者；
没有web管理界面，提供了一个CLI(命令行界面)管理工具带来查询、管理和诊断各种问题；
没有在 mq 核心中去实现JMS等接口；
4、Kafka
Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。
主要特性：
快速持久化，可以在O(1)的系统开销下进行消息持久化；
高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；
完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；
支持同步和异步复制两种HA；
支持数据批量发送和拉取；
zero-copy：减少IO操作步骤；
数据迁移、扩容对用户透明；
无需停机即可扩展机器；
其他特性：严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制；
使用Kafka需要：
Java JDK
Kafka安装包
优点：
客户端语言丰富，支持java、.net、php、ruby、python、go等多种语言；
性能卓越，单机写入TPS约在百万条/秒，消息大小10个字节；
提供完全分布式架构, 并有replica机制, 拥有较高的可用性和可靠性, 理论上支持消息无限堆积；
支持批量操作；
消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
有优秀的第三方Kafka Web管理界面Kafka-Manager；
在日志领域比较成熟，被多家公司和多个开源项目使用；
缺点：
Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
使用短轮询方式，实时性取决于轮询间隔时间；
消费失败不支持重试；
支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
社区更新较慢；
5、RabbitMQ/ActiveMQ/RocketMQ/Kafka对比
这里列举了上述四种消息队列的差异对比：
结论：Kafka在于分布式架构，RabbitMQ基于AMQP协议来实现，RocketMQ/思路来源于kafka，改成了主从结构，在事务性可靠性方面做了优化。广泛来说，电商、金融等对事务性要求很高的，可以考虑RabbitMQ和RocketMQ，对性能要求高的可考虑Kafka。
参考资料：
1、消息队列：
大型网站架构之分布式消息队列 http://blog.csdn.net/shaobingj126/article/details/50585035
消息队列的使用场景 https://www.zhihu.com/question/34243607/answer/127666030
浅谈异步消息队列模型 http://www.cnblogs.com/sunkeydev/p/5248855.html
消息队列的两种模式 http://blog.csdn.net/heyutao007/article/details/50131089
2、RabbitMQ
RabbitMQ主页 https://www.rabbitmq.com/
RabbitMQ学习教程 https://www.rabbitmq.com/getstarted.html
专栏:RabbitMQ从入门到精通 http://blog.csdn.net/column/details/rabbitmq.html
RabbitMQ能为你做些什么 http://rabbitmq.mr-ping.com/description.html
RabbitMQ指南(1)-特性及功能 https://blog.zenfery.cc/archives/79.html
3、ActiveMQ
ActiveMQ主页 http://activemq.apache.org/
Apache ActiveMQ介绍 http://jfires.iteye.com/blog/1187688
ActiveMQ的简介与安装 http://blog.csdn.net/sl1992/article/details/72824562
ActiveMQ 和消息简介 http://www.cnblogs.com/craftsman-gao/p/7002605.html
4、RocketMQ
主页 https://github.com/alibaba/RocketMQ
RocketMQ 原理简介 http://alibaba.github.io/RocketMQ-docs/document/design/RocketMQ_design.pdf
RocketMQ与kafka对比(18项差异) http://jm.taobao.org/2016/03/24/rmq-vs-kafka/
5、Kafka
1.Kafka主页： http://kafka.apache.org/
Kafka特性 http://www.cnblogs.com/lsx1993/p/4847719.html
Kafka客户端支持语言 https://cwiki.apache.org/confluence/display/KAFKA/Clients
6、RabbitMQ/ActiveMQ/RocketMQ/Kafka对比
RocketMQ－队列选型 http://www.zmannotes.com/index.php/2016/01/17/rocketmq/
RabbitMQ和Kafka http://www.dongcoder.com/detail-416804.html
即时通信RabbitMQ二-性能测试 http://www.jianshu.com/p/d31ae9e3bfb6
RabbitMq、ActiveMq、ZeroMq、kafka之间的比较 http://blog.csdn.net/linsongbin1/article/details/47781187
消息队列软件产品大比拼 http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html
总结：消息队列利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。目前业界有很多的MQ产品，例如RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，也有直接使用数据库redis充当消息队列的案例。而这些消息队列产品，各有侧重，在实际选型时，需要结合自身需求及MQ产品特征，综合考虑。
参考来源：
rabbitMQ、activeMQ、zeroMQ、kafka、redis 比较
消息队列及常见消息队列介绍
消息队列(Message Queue)，是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。消息队列主要解决了应用耦合、异步处理、流量削锋等问题。当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。
1、消息中间件介绍
一般，我们认为消息中间件是指支持与保障分布式应用程序之间同步/异步收发消息的中间件。消息是分布式应用之间进行数据交换的基本信息单位，分布式应用程序之间的通信接口由消息中间件提供。其中，异步方式指消息发送方在发送消息时不必知道接收方的状态，更无需等待接收方的回复，而接收方在收到消息时也不必知道发送方的目前状态，更无需进行同步的消息处理，它们之间的连接完全是松耦合的，通信是非阻塞的，这种异步通信方式是由消息中间件中的消息队列及其服务机制保障的。一般地，实时性要求较高的业务采用同步方式处理，实时性要求不高的业务采用异步方式进行处理。
消息中间件已广泛应用于各类分布式应用系统，消息中间件开始向发布/订阅架构转变，并成为企业应用集成中间件的一种核心机制，而基于发布/订阅架构的消息中间件通常称为发布/订阅消息中间件或消息代理。目前比较典型的消息中间件包括IBM WebSphere MQSeries、阿里的RocketMQ和Kafka等。消息中间件是在消息的传输过程中保存信息的容器。消息中间件再将消息从它的源中继到它的目标时充当中间人的作用。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它为止，当然，消息队列保存消息也是有期限的。
2、消息中间件的特点
2.1 采用异步处理模式
消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道(主题或队列)上，消息接收者则订阅或是监听该通道。一条信息可能最终转发给一个或多个消息接收者，这些接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
2.2 应用程序和应用程序调用关系为松耦合关系
主要体现在如下两点：
(1)发送者和接受者不必了解对方、只需要确认消息
(2)发送者和接受者不必同时在线
比如在线交易系统为了保证数据的最终一致，在支付系统处理完成后会把支付结果放到消息中间件里通知订单系统修改订单支付状态。两个系统通过消息中间件解耦。
3、消息传递服务模型
4、消息中间件的传输模式
4.1 点对点模型
点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对于消费服务中的一个队列(Queue)，在消息传递给消费者之前它被存储在这个队列中。队列消息可以放在内存中也可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。传统的点对点消息中间件通常由消息队列服务、消息传递服务、消息队列和消息应用程序接口API组成。
特点：
(1)每个消息只用一个消费者
(2)发送者和接受者没有时间依赖
(3)接受者确认消息接受和处理成功
4.2 发布-订阅模型(Pub/Sub)
发布者/订阅者模型支持向一个特定的消息主题生产消息。0或多个订阅者可能对接收来自特定消息主题的消息感兴趣。在这种模型下，发布者和订阅者彼此不知道对方。这种模式就好比是匿名公告板。这种模式被概况为：多个消费者可以获得消息，在发布者和订阅者之间存在时间依赖性。发布者需要建立一个订阅(subscription)，以便能够消费者订阅。订阅者必须保持持续的活动状态及接收消息，除非订阅者建立了持久的订阅。在这种情况下，在订阅者未连接时发布的消息将在订阅者重新连接时重新发布。
发布/订阅模型特性
(1)每个消息可以有多个订阅者
(2)客户端只有订阅后才能接收到消息
(3)持久订阅和非持久订阅
注意：
(1)发布者和订阅者有时间依赖
接受者和发布者只有建立订阅关系才能收到消息
(2)持久订阅
订阅关系建立后，消息就不会消失，不管订阅者是否都在线
(3)非持久订阅
订阅者为了接受消息，必须一直在线
当只有一个订阅者时约等于点对点模式
5、消息中间件应用场景
5.1 用户注册异步处理
网站用户注册，注册成功后会过一会发送邮件确认或者短息。
5.2 日志分析使用
把日志进行集中收集，用于计算PV、用户行为分析。
5.3 数据复制
(1)将数据从源头复制到多个目的地，一般是要求顺序或者保证因果序列
(2)用于跨机房数据传输、搜索、离线数据计算等。
5.4 延迟消息发送和暂存
(1)把消息中间件当成可靠的消息暂存地
(2)定时进行消息投递，比如模拟用户秒杀访问，进行系统性能压测
5.5 消息广播
(1)缓存数据同步更新
(2)往应用推送数据
比如更新本地缓存。
6、消息中间件消息模型分类
6.1 push推消息模型
消息生产者将消息发送给消息传递服务，消息传递服务又将消息推给消息消费者。
6.2 pull拉消息模型
消费者请求消息服务接受消息，消息生产者从消息中间件拉该消息。
6.3 两种类型的区别
push推消息和pull拉消息的区别
消息队列使用场景
消息队列在实际应用中包括如下四个场景：
应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理。
消息队列的两种模式
消息队列包括两种模式，点对点模式(point to point， queue)和发布/订阅模式(publish/subscribe，topic)。
点对点模式
点对点模式下包括三个角色：
消息队列
发送者(生产者)
接收者(消费者)
消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。
点对点模式特点：
每个消息只有一个接收者(Consumer)(即一旦被消费，消息就不再在消息队列中)；
发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；
接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；
发布/订阅模式
发布/订阅模式下包括三个角色：
角色主题(Topic)
发布者(Publisher)
订阅者(Subscriber)
发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
发布/订阅模式特点：
每个消息可以有多个订阅者；
发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息；
为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行。
开源消息系统，被广泛地应用在数据缓冲、异步通信、汇集日志、系统解耦等方面。常见的消息中间件有像RabbitMQ、ActiveMQ、ZeroMQ、Kafka、Redis等。
RabbitMQ
RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
Redis
Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
ZeroMQ
ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 0.9.0以前的版本中默认使用ZeroMQ作为数据流的传输(Storm从0.9版本开始同时支持ZeroMQ和Netty作为传输模块)。
ActiveMQ
ActiveMQ是Apache下的一个子项目。类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。
Kafka/Jafka
Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
从可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统、社区来看，RabbitMq最好，ActiveMq次之，ZeroMq最差。当然ZeroMq也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。所以在可靠性和可用性上，RabbitMQ是首选，虽然ActiveMQ也具备，但是它性能不及RabbitMQ。从实现语言来看，RabbitMQ最高，原因是它的实现语言是天生具备高并发高可用的erlang语言。
Kafka
Kafka在保障了大部分功能特性的同时，还提供了超一流的读写性能。下面介绍一下Kafka的架构和涉及到的名词：
Topic：用于划分Message的逻辑概念，一个Topic可以分布在多个Broker上。
Partition：是Kafka中横向扩展和一切并行化的基础，每个Topic都至少被切分为1个Partition。
Offset：消息在Partition中的编号，编号顺序不跨Partition。
Consumer：用于从Broker中取出/消费Message。
Producer：用于往Broker中发送/生产Message。
Replication：Kafka支持以Partition为单位对Message进行冗余备份，每个Partition都可以配置至少1个Replication(当仅1个Replication时即仅该Partition本身)。
Leader：每个Replication集合中的Partition都会选出一个唯一的Leader，所有的读写请求都由Leader处理。其他Replicas从Leader处把数据更新同步到本地，过程类似大家熟悉的MySQL中的Binlog同步。
Broker：Kafka中使用Broker来接受Producer和Consumer的请求，并把Message持久化到本地磁盘。每个Cluster当中会选举出一个Broker来担任Controller，负责处理Partition的Leader选举，协调Partition迁移等工作。
ISR(In-Sync Replica)：是Replicas的一个子集，表示目前Alive且与Leader能够“Catch-up”的Replicas集合。由于读写都是首先落到Leader上，所以一般来说通过同步机制从Leader上拉取数据的Replica都会和Leader有一些延迟(包括了延迟时间和延迟条数两个维度)，任意一个超过阈值都会把该Replica踢出ISR。每个Partition都有它自己独立的ISR。
Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：
以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。
高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。
支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。
同时支持离线数据处理和实时数据处理。
支持在线水平扩展。
Kafka的高容错性是如何保证的？
producer不使用批量接口，并采用同步模型持久化消息。
consumer不采用批量化，每消费一次就更新offset。
与传统的mq的区别？
更快！单机可有上万TPS；传统的MQ，消息被消化掉后会被mq删除，而kafka中消息被消化后不会被删除，而是到配置的expire时间后才删除。
传统的MQ，消息的Offset是由MQ维护，而kafka中消息的Offset是由客户端自己维护。
分布式，把写入压力均摊到各个节点。可以通过增加节点降低压力。
与传统MQ的方式的基本术语对比
Producer
Consumer
这两个与传统的MQ一样，就不解释了。
Topic
Kafka中的topic其实对应传统MQ的channel，即消息管道，例如同一业务用同一根管道。
Broker
集群中的KafkaServer，用来提供Partition服务。
Partition
假如说传统的MQ，传输消息的通道(channel)是一条双车道公路，那么Kafka中，Topic就是一个N车道的高速公路。每个车道都可以行车，而每个车道就是Partition。
一个Topic中可以有一个或多个partition。
一个Broker上可以跑一个或多个Partition。集群中尽量保证partition的均匀分布，例如定义了一个有3个partition的topic，而只有两个broker，那么一个broker上跑两个partition，而另一个是1个。但是如果有3个broker，必然是3个broker上各跑一个partition。
Partition中严格按照消息进入的顺序排序
一个从Producer发送来的消息，只会进入Topic的某一个Partition(除非特殊实现Producer要求消息进入所有Partition)
Consumer可以自己决定从哪个Partition读取数据
Offset
单个Partition中的消息的顺序ID，例如第一个进入的Offset为0，第二个为1，以此类推。传统的MQ，Offset是由MQ自己维护，而kafka是由client维护。
Replica
Kafka从0.8版本开始，支持消息的HA，通过消息复制的方式。在创建时，我们可以指定一个topic有几个partition，以及每个partition有几个复制。复制的过程有同步和异步两种，根据性能需要选取。正常情况下，写和读都是访问leader，只有当leader挂掉或者手动要求重新选举，kafka会从几个复制中选举新的leader。
Kafka会统计replica与leader的同步情况。当一个replica与leader数据相差不大，会被认为是一个"in-sync" replica。只有"in-sync" replica才有资格参与重新选举。
ConsumerGroup
一个或多个Consumer构成一个ConsumerGroup，一个消息应该只能被同一个ConsumerGroup中的一个Consumer消化掉，但是可以同时发送到不同ConsumerGroup。通常的做法是一个Consumer去对应一个Partition。
传统MQ中有queuing(消息)和publish-subscribe(订阅)模式，Kafka中也支持：
当所有Consumer具有相同的ConsumerGroup时，该ConsumerGroup中只有一个Consumer能收到消息，就是 queuing 模式
当所有Consumer具有不同的ConsumerGroup时，每个ConsumerGroup会收到相同的消息，就是 publish-subscribe 模式
Kafka和RabbitMQ的比较，最权威的的是kafka的提交者写一篇文章。
RabbitMq比kafka成熟，在可用性、稳定性、可靠性上，RabbitMq超过kafka。Kafka设计的初衷就是处理日志的，可以看做是一个日志系统，针对性很强，所以它并没有具备一个成熟MQ应该具备的特性。
Kafka的性能(吞吐量、tps)比RabbitMq要强，这篇文章的作者认为，两者在这方面没有可比性。 kafaka比redis pub/sub更加可靠，后者有数据丢失的风险，因为后者是用一次就丢弃的模式，而kafaka会有数据持久化处理。而且kafaka对超大量的数据处理支持远好过redis pub/sub。redis的优势是速度比较快，但是kafaka已经很快了。所以kafaka更符合大数据的实时计算场景。kafka 所有的数据保存在文件系统中，redis主要提供丰富的内存中数据结构，持久化方面性能并不好。kafka更适合消息队列的场景，有更强的稳健性和部署性，完全没必要用redis来替换kafka。
| ActiveMq | RabbitMq | Kafka | |
|---|---|---|---|
| producer容错，是否会丢数据 | 有ack模型，也有事务模型，保证至少不会丢数据。ack模型可能会有重复消息，事务模型则保证完全一致 | 批量形式下，可能会丢数据。 非批量形式下， 1. 使用同步模式，可能会有重复数据。 2. 异步模式，则可能会丢数据。 | |
| consumer容错，是否会丢数据 | 有ack模型，数据不会丢，但可能会重复处理数据。 | 批量形式下，可能会丢数据。非批量形式下，可能会重复处理数据。（ZK写offset是异步的） | |
| 架构模型 | 基于JMS协议 | 基于AMQP模型，比较成熟，但更新超慢。RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制 | producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。 |
| 吞吐量 | rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。 | kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高 | |
| 可用性 | rabbitMQ支持miror的queue，主queue失效，miror queue接管 | kafka的broker支持主备模式 | |
| 集群负载均衡 | rabbitMQ的负载均衡需要单独的loadbalancer进行支持 | kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上 |
常用消息队列介绍
本部分主要介绍四种常用的消息队列(RabbitMQ/ActiveMQ/RocketMQ/Kafka)的主要特性、优点、缺点。
1、RabbitMQ
RabbitMQ 2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。
主要特性：
可靠性：提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制；
灵活的路由： 消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做RabbitMQ的插件来使用；
消息集群：在相同局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个独立的逻辑代理来使用；
队列高可用：队列可以在集群中的机器上进行镜像，以确保在硬件问题下还保证消息安全；
多种协议的支持：支持多种消息队列协议；
服务器端用Erlang语言编写，支持只要是你能想到的所有编程语言；
管理界面: RabbitMQ有一个易用的用户界面，使得用户可以监控和管理消息Broker的许多方面；
跟踪机制：如果消息异常，RabbitMQ提供消息跟踪机制，使用者可以找出发生了什么；
插件机制：提供了许多插件，来从多方面进行扩展，也可以编写自己的插件；
使用RabbitMQ需要：
ErLang语言包
RabbitMQ安装包
RabbitMQ可以运行在Erlang语言所支持的平台之上。
优点：
由于erlang语言的特性，mq 性能较好，高并发；
健壮、稳定、易用、跨平台、支持多种语言、文档齐全；
有消息确认机制和持久化机制，可靠性高；
高度可定制的路由；
管理界面较丰富，在互联网公司也有较大规模的应用；
社区活跃度高；
缺点：
尽管结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护；
实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署，但是使得其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大；
需要学习比较复杂的接口和协议，学习和维护成本较高；
2、ActiveMQ
ActiveMQ是由Apache出品，ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。
主要特性：
服从 JMS 规范：JMS 规范提供了良好的标准和保证，包括：同步或异步的消息分发，一次和仅一次的消息分发，消息接收和订阅等等。遵从 JMS 规范的好处在于，不论使用什么 JMS 实现提供者，这些基础特性都是可用的；
连接性：ActiveMQ 提供了广泛的连接选项，支持的协议有：HTTP/S，IP 多播，SSL，STOMP，TCP，UDP，XMPP等等。对众多协议的支持让 ActiveMQ 拥有了很好的灵活性。
支持的协议种类多：OpenWire、STOMP、REST、XMPP、AMQP ；
持久化插件和安全插件：ActiveMQ 提供了多种持久化选择。而且，ActiveMQ 的安全性也可以完全依据用户需求进行自定义鉴权和授权；
支持的客户端语言种类多：除了 Java 之外，还有：C/C++，.NET，Perl，PHP，Python，Ruby；
代理集群：多个 ActiveMQ 代理可以组成一个集群来提供服务；
异常简单的管理：ActiveMQ 是以开发者思维被设计的。所以它并不需要专门的管理员，因为它提供了简单又使用的管理特性。有很多中方法可以监控 ActiveMQ 不同层面的数据，包括使用在 JConsole 或者 ActiveMQ 的Web Console 中使用 JMX，通过处理 JMX 的告警消息，通过使用命令行脚本，甚至可以通过监控各种类型的日志。
使用ActiveMQ需要：
Java JDK
ActiveMQ安装包
ActiveMQ可以运行在Java语言所支持的平台之上。
优点：
跨平台(JAVA编写与平台无关有，ActiveMQ几乎可以运行在任何的JVM上)
可以用JDBC：可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能，但是数据库一直都是开发人员最熟悉的存储介质。将消息存到数据库，看得见摸得着。而且公司有专门的DBA去对数据库进行调优，主从分离；
支持JMS ：支持JMS的统一接口;
支持自动重连；
有安全机制：支持基于shiro，jaas等多种安全配置机制，可以对Queue/Topic进行认证和授权。
监控完善：拥有完善的监控，包括Web Console，JMX，Shell命令行，Jolokia的REST API；
界面友善：提供的Web Console可以满足大部分情况，还有很多第三方的组件可以使用，如hawtio；
缺点：
社区活跃度不及RabbitMQ高；
根据其他用户反馈，会出莫名其妙的问题，会丢失消息；
目前重心放到activemq6.0产品-apollo，对5.x的维护较少；
不适合用于上千个队列的应用场景；
3、RocketMQ
RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。
主要特性：
是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点；
Producer、Consumer、队列都可以分布式；
Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合；
能够保证严格的消息顺序；
提供丰富的消息拉取模式；
高效的订阅者水平扩展能力；
实时的消息订阅机制；
亿级消息堆积能力；
较少的依赖；
使用RocketMQ需要：
Java JDK
安装git、Maven
RocketMQ安装包
RocketMQ可以运行在Java语言所支持的平台之上。
优点：
单机支持 1 万以上持久化队列
RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，访问时，直接从内存读取。
模型简单，接口易用(JMS 的接口很多场合并不太实用)；
性能非常好，可以大量堆积消息在broker中；
支持多种消费，包括集群消费、广播消费等。
各个环节分布式扩展设计，主从HA；
开发度较活跃，版本更新很快。
缺点：
支持的客户端语言不多，目前是java及c++，其中c++不成熟；
RocketMQ社区关注度及成熟度也不及前两者；
没有web管理界面，提供了一个CLI(命令行界面)管理工具带来查询、管理和诊断各种问题；
没有在 mq 核心中去实现JMS等接口；
4、Kafka
Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log)，，之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。
主要特性：
快速持久化，可以在O(1)的系统开销下进行消息持久化；
高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；
完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；
支持同步和异步复制两种HA；
支持数据批量发送和拉取；
zero-copy：减少IO操作步骤；
数据迁移、扩容对用户透明；
无需停机即可扩展机器；
其他特性：严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制；
使用Kafka需要：
Java JDK
Kafka安装包
优点：
客户端语言丰富，支持java、.net、php、ruby、python、go等多种语言；
性能卓越，单机写入TPS约在百万条/秒，消息大小10个字节；
提供完全分布式架构, 并有replica机制, 拥有较高的可用性和可靠性, 理论上支持消息无限堆积；
支持批量操作；
消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
有优秀的第三方Kafka Web管理界面Kafka-Manager；
在日志领域比较成熟，被多家公司和多个开源项目使用；
缺点：
Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
使用短轮询方式，实时性取决于轮询间隔时间；
消费失败不支持重试；
支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
社区更新较慢；
5、RabbitMQ/ActiveMQ/RocketMQ/Kafka对比
这里列举了上述四种消息队列的差异对比：
结论：Kafka在于分布式架构，RabbitMQ基于AMQP协议来实现，RocketMQ/思路来源于kafka，改成了主从结构，在事务性可靠性方面做了优化。广泛来说，电商、金融等对事务性要求很高的，可以考虑RabbitMQ和RocketMQ，对性能要求高的可考虑Kafka。
参考资料：
1、消息队列：
大型网站架构之分布式消息队列 http://blog.csdn.net/shaobingj126/article/details/50585035
消息队列的使用场景 https://www.zhihu.com/question/34243607/answer/127666030
浅谈异步消息队列模型 http://www.cnblogs.com/sunkeydev/p/5248855.html
消息队列的两种模式 http://blog.csdn.net/heyutao007/article/details/50131089
2、RabbitMQ
RabbitMQ主页 https://www.rabbitmq.com/
RabbitMQ学习教程 https://www.rabbitmq.com/getstarted.html
专栏:RabbitMQ从入门到精通 http://blog.csdn.net/column/details/rabbitmq.html
RabbitMQ能为你做些什么 http://rabbitmq.mr-ping.com/description.html
RabbitMQ指南(1)-特性及功能 https://blog.zenfery.cc/archives/79.html
3、ActiveMQ
ActiveMQ主页 http://activemq.apache.org/
Apache ActiveMQ介绍 http://jfires.iteye.com/blog/1187688
ActiveMQ的简介与安装 http://blog.csdn.net/sl1992/article/details/72824562
ActiveMQ 和消息简介 http://www.cnblogs.com/craftsman-gao/p/7002605.html
4、RocketMQ
主页 https://github.com/alibaba/RocketMQ
RocketMQ 原理简介 http://alibaba.github.io/RocketMQ-docs/document/design/RocketMQ_design.pdf
RocketMQ与kafka对比(18项差异) http://jm.taobao.org/2016/03/24/rmq-vs-kafka/
5、Kafka
1.Kafka主页： http://kafka.apache.org/
Kafka特性 http://www.cnblogs.com/lsx1993/p/4847719.html
Kafka客户端支持语言 https://cwiki.apache.org/confluence/display/KAFKA/Clients
6、RabbitMQ/ActiveMQ/RocketMQ/Kafka对比
RocketMQ－队列选型 http://www.zmannotes.com/index.php/2016/01/17/rocketmq/
RabbitMQ和Kafka http://www.dongcoder.com/detail-416804.html
即时通信RabbitMQ二-性能测试 http://www.jianshu.com/p/d31ae9e3bfb6
RabbitMq、ActiveMq、ZeroMq、kafka之间的比较 http://blog.csdn.net/linsongbin1/article/details/47781187
消息队列软件产品大比拼 http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html
总结：消息队列利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。目前业界有很多的MQ产品，例如RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，也有直接使用数据库redis充当消息队列的案例。而这些消息队列产品，各有侧重，在实际选型时，需要结合自身需求及MQ产品特征，综合考虑。
参考来源：
rabbitMQ、activeMQ、zeroMQ、kafka、redis 比较
消息队列及常见消息队列介绍