原文链接：Kafka、RabbitMQ、RocketMQ等消息中间件的对比
消息中间件现在有不少，网上很多文章都对其做过对比，在这我对其做进一步总结与整理。

RocketMQ

淘宝内部的交易系统使用了淘宝自主研发的Notify消息中间件，使用Mysql作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011年初，Linkin开源了Kafka这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用Java语言编写了RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

Kafka

Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。

RabbitMQ

RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

有关测试结论

Kafka的吞吐量高达17.3w/s，不愧是高吞吐量消息中间件的行业老大。这主要取决于它的队列模式保证了写磁盘的过程是线性IO。此时broker磁盘IO已达瓶颈。

RocketMQ也表现不俗，吞吐量在11.6w/s，磁盘IO %util已接近100%。RocketMQ的消息写入内存后即返回ack，由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件。

RabbitMQ的吞吐量5.95w/s，CPU资源消耗较高。它支持AMQP协议，实现非常重量级，为了保证消息的可靠性在吞吐量上做了取舍。我们还做了RabbitMQ在消息持久化场景下的性能测试，吞吐量在2.6w/s左右。

在服务端处理同步发送的性能上，Kafka>RocketMQ>RabbitMQ。

对比了最简单的小消息发送场景,Kafka暂时胜出。但是,作为经受过历次双十一洗礼的RocketMQ,在互联网应用场景中更有它优越的一面。

阿里官网对比

| 功能 | 消息队列 RocketMQ | Apache RocketMQ
（开源） | 消息队列 Kafka | Apache Kafka
（开源） | RabbitMQ
（开源） |
| --- | --- | --- | --- | --- | --- |
| 安全防护 | 支持 | 不支持 | 支持 | 不支持 | 支持 |
| 主子账号支持 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| 可靠性 | - 同步刷盘

同步双写
超3份数据副本
99.99999999% | - 同步刷盘
异步刷盘 | - 同步刷盘
同步双写
超3份数据副本
99.99999999% | 异步刷盘，丢数据概率高 | 同步刷盘 |
| 可用性 | - 非常好，99.95%
Always Writable | 好 | - 非常好，99.95%
Always Writable | 好 | 好 |
| 横向扩展能力 | - 支持平滑扩展
支持百万级 QPS | 支持 | - 支持平滑扩展
支持百万级 QPS | 支持 | - 集群扩容依赖前端
LVS 负载均衡调度 |
| Low Latency | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| 消费模型 | Push / Pull | Push / Pull | Push / Pull | Pull | Push / Pull |
| 定时消息 | 支持（可精确到秒级） | 支持（只支持18个固定 Level） | 暂不支持 | 不支持 | 支持 |
| 事务消息 | 支持 | 不支持 | 不支持 | 不支持 | 不支持 |
| 顺序消息 | 支持 | 支持 | 暂不支持 | 支持 | 不支持 |
| 全链路消息轨迹 | 支持 | 不支持 | 暂不支持 | 不支持 | 不支持 |
| 消息堆积能力 | 百亿级别
不影响性能 | 百亿级别
影响性能 | 百亿级别
不影响性能 | 影响性能 | 影响性能 |
| 消息堆积查询 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 消息回溯 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 消息重试 | 支持 | 支持 | 暂不支持 | 不支持 | 支持 |
| 死信队列 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
| 性能（常规） | 非常好
百万级 QPS | 非常好
十万级 QPS | 非常好
百万级 QPS | 非常好
百万级 QPS | 一般
万级 QPS |
| 性能（万级 Topic 场景） | 非常好
百万级 QPS | 非常好
十万级 QPS | 非常好
百万级 QPS | 低 | 低 |
| 性能（海量消息堆积场景） | 非常好
百万级 QPS | 非常好
十万级 QPS | 非常好
百万级 QPS | 低 | 低 |

对比

|
| ActiveMQ | RabbitMQ | RocketMq | ZeroMQ | Kafka |
| 关注度 | 高 | 高 | 中 | 中 | 高 |
|

成熟度

| 成熟 | 成熟 | 比较成熟 | 不成熟 | 成熟 |
|

所属社区/公司

| Apache | Mozilla
Public
License |

Alibaba

Apache

|
|
|
| 社区活跃度 | 高 | 高 | 中 | 低 | 高 |
| 文档 | 多 | 多 | 中 | 中 | 多 |
| 特点 | 功能齐全，被大量开源项目使用 | 由于Erlang 语言的并发能力，性能很好 | 各个环节分布式扩展设计，主从 HA；支持上万个队列；多种消费模式；性能很好 | 低延时，高性能，最高 43万条消息每秒 |
|
| 授权方式 | 开源 | 开源 | 开源 | 开源 | 开源 |
| 开发语言 | Java | Erlang | Java | C |
|
| 支持的协议 | OpenWire、
STOMP、
REST、XMPP、
AMQP | AMQP | 自己定义的一
套(社区提供
JMS--不成熟) | TCP、UDP |
|
| 客户端支持语言 | Java、C、
C++、
Python、
PHP、
Perl、.net 等 | Java、C、
C++、
Python、
PHP、
Perl、.net 等 | Java
C++（不成熟） | python、 java、 php、.net 等 |
|
| 持久化 | 内存、文件、数据库 | 内存、文件 | 磁盘文件 | 在消息发送端保存 |
|
| 事务 | 支持 | 不支持 | 支持 | 不支持 |
|
| 集群 | 支持 | 支持 | 支持 | 不支持 |
|
| 负载均衡 | 支持 | 支持 | 支持 | 不支持 |
|
| 管理界面 | 一般 | 好 | 无社区有 web
console 实现 | 无 |
|
| 部署方式 | 独立、嵌入 | 独立 | 独立 | 独立 |
|
| 顺序 | 无法保证严格的顺序 |
| 保证严格的消费顺序 |
|
|
| 评价 | 优点：
成熟的产品，已经在很多公司得到应用（非大规模场景）。有较多的文档。各种协议支持较好，有多重语言的成熟的客户端；
缺点：
根据其他用户反馈，会出莫名其妙的问题，切会丢失消息。其重心放到activemq6.0 产品—apollo 上去了，目前社区不活跃，且对 5.x 维护较少；
Activemq 不适合用于上千个队列的应用场景 | 优点：由于erlang语言的特性，mq 性能较好；管理界面较丰富，在互联网公司也有较大规模的应用；支持amqp系诶，有多中语言且支持 amqp 的客户端可用

缺点：
erlang语言难度较
大。集群不支持动态扩展。 | 优点：
模型简单，接口易用（JMS 的接口很多场合并不太实用）。在阿里大规模应用。目前支付宝中的余额宝等新兴产
品均使用rocketmq。集群规模大概在50 台左右，单日处理消息上百亿；性能非常好，可以大量堆
积消息在broker 中；支持多种消费，包括集群消费、广播消费等。开发度较活跃，版本更新很快。
缺点：
没有在 mq 核心中去实现JMS 等接口， |
|
|
|
|
|
|
|
|
|

RabbitMQ

是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。

Redis

是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

ZeroMQ

号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。

ActiveMQ

是Apache下的一个子项目。类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

Jafka/Kafka

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

rabbitmq比kafka可靠，kafka更适合IO高吞吐的处理，比如ELK日志收集**

Kafka和RabbitMq一样是通用意图消息代理，他们都是以分布式部署为目的。但是他们对消息语义模型的定义的假设是非常不同的。我对”AMQP 更成熟”这个论点是持怀疑态度的。让我们用事实说话来看看用什么解决方案来解决你的问题。
　　a) 以下场景你比较适合使用Kafka。你有大量的事件(10万以上/秒)、你需要以分区的，顺序的，至少传递成功一次到混杂了在线和打包消费的消费者、你希望能重读消息、你能接受目前是有限的节点级别高可用或则说你并不介意通过论坛/IRC工具得到还在幼儿阶段的软件的支持。
　　b) 以下场景你比较适合使用RabbitMQ。你有较少的事件（2万以上/秒）并且需要通过复杂的路由逻辑去找到消费者、你希望消息传递是可靠的、你并不关心消息传递的顺序、你需要现在就支持集群-节点级别的高可用或则说你需要7*24小时的付费支持（当然也可以通过论坛/IRC工具）。

redis 消息推送（基于分布式 pub/sub）多用于实时性较高的消息推送，并不保证可靠。

redis 消息推送（基于分布式 pub/sub）多用于实时性较高的消息推送，并不保证可靠。其他的mq和kafka保证可靠但有一些延迟（非实时系统没有保证延迟）。redis-pub/sub断电就清空，而使用redis-list作为消息推送虽然有持久化，但是又太弱智，也并非完全可靠不会丢。另外一点，redis 发布订阅除了表示不同的 topic 外，并不支持分组，比如kafka中发布一个东西，多个订阅者可以分组，同一个组里只有一个订阅者会收到该消息，这样可以用作负载均衡。比如，kafka 中发布：topic = “发布帖子” data=”文章1” 这个消息，后面有一百台服务器每台服务器都是一个订阅者，都订阅了这个 topic，但是他们可能分为三组，A组50台，用来真的做发布文章，A组50台里所有 subscriber 都订阅了这个topic。由于在同一组，这条消息（topic=”发布帖子”, data=”文章1”）只会被A组里面一台当前空闲的机器收到。而B组25台服务器用于统计，C组25台服务器用于存档备份，每组只有一台会收到。用不同的组来决定每条消息要抄送出多少分去，用同组内哪些订阅者忙，哪些订阅者空闲来决定消息会被分到哪台服务器去处理，生产者消费者模型嘛。redis完全没有这类机制，这两点是最大的区别。

redis是内存数据库！redis他爹做了disque，你要不要试试。mq一般都采用订阅～发布模型，如果你考虑性能，主要关注点就放在消费模型是pull还是push。影响最大的，应该是存储结构。kafka的性能要在topic数量小于64的时候，才能发挥威力。partition决定的。极限情况下丢消息，例如：主写入消息后，主机器宕机，并硬盘损坏。review代码的时候发现的。rabbit不知道，但是rocket的性能是（万条每秒），并且能够横向无限扩展，单机topic数量在256时，性能损失较小。rocket可以说是kafka的变种，是阿里在充分reviewkafka代码后，开发的metaQ。在不断更新，修补以后，阿里把metaQ3.0更名为rocket，并且rocket是java写的易于维护。另外就是rocket和kafka有类似无限堆积的能力。想想，断电不丢消息，积压两亿条消息毫无压力，niubilitykafka和rocket性能根本不是你需要考虑的问题。

在应用场景方面，

RabbitMQ,遵循AMQP协议，由内在高并发的erlanng语言开发，用在实时的对可靠性要求比较高的消息传递上。

kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。

在架构模型方面，

RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制。

kafka遵从一般的MQ结构，producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。

在吞吐量，

kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。

rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。

在可用性方面，

rabbitMQ支持miror的queue，主queue失效，miror queue接管。

kafka的broker支持主备模式。

在集群负载均衡方面，

kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。

rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

Kafka是可靠的分布式日志存储服务。用简单的话来说，你可以把Kafka当作可顺序写入的一大卷磁带，可以随时倒带，快进到某个时间点重放。先说下日志的定义：日志是数据库的核心，是对数据库的所有变更的严格有序记录，“表”是变更的结果。日志的其他名字有： Changelog, Write Ahead Log, Commit Log, Redo Log, Journaling.Kafka的特征如下：高写入速度：Kafka能以超过1Gbps NIC的速度写这盘磁带（实际可以到SATA 3速度，参考Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines))，充分利用了磁盘的物理特性，即，随机写入慢（磁头冲停），顺序写入快（磁头悬浮）。高可靠性：通过zookeeper做分布式一致性，同步到任意多块磁盘上，故障自动切换选主，自愈。高容量：通过横向扩展，LinkedIn每日通过Kafka存储的新增数据高达175TB，8000亿条消息，可无限扩容，类似把两条磁带粘到一起。传统业务数据库的根本缺陷在于：1. 太慢，读写太昂贵，无法避免的随机寻址。（磁盘最快5ms寻址，固态又太昂贵。）2. 根本无法适应持续产生的数据流，越用越慢。（索引效率问题）3. 无法水平scale。（多半是读写分离，一主多备。另: NewSQL通过一致性算法，有多主。）针对这些问题，Kafka提出了一种方法: “log-centric approach（以日志为中心的方法）。”将传统数据库分为两个独立的系统，即日志系统和索引系统。“持久化和索引分开，日志尽可能快的落地，索引按照自己的速度追赶。”在数据可靠性在得到Kafka这种快速的，类似磁带顺序记录方式保障的大前提下。数据的呈现，使用方式变得非常灵活，可以根据需要将数据流同时送入搜索系统，RDBMS系统，数据仓库系统，图数据库系统，日志分析等这些各种不同的数据库系统。这些不同的系统只不过是一种对Kafka磁带数据的一种诠释，一个侧面，一个索引，一个快照。数据丢了，没关系，重放一遍磁带即可，更多的时候，对这些各式数据库系统的维护只是需要定期做一个快照，并拷贝到一个安全的对象存储(如S3) 而已。一句话：“日志都是相同的日志，索引各有各的不同。”关于流计算：在以流为基本抽象的存储模型下，数据流和数据流之间，可以多流混合处理，或者流和状态，状态和状态的JOIN处理，这就是Kafka Stream提供的功能。一个简单的例子是，在用户触发了某个事件后，和用户表混合处理，产生数据增补（Augment)，再进入数据仓库进行相关性分析，一些简单的窗口统计和实时分析也很容易就能满足，比如在收到用户登录消息的时候，在线人数+1，离线的时候-1，反应出当前系统的在线用户总数。这方面可以参考PipelineDB https://www.pipelinedb.com/Kafka会让你重新思考系统的构建方式，使以前不可能的事变为可能，是一个系统中最重要的最核心的部分，不夸张的说，系统设计都需要围绕Kafka做。

深入探讨可以加笔者QQ：1120855315
点击获取免费Java免费视频
 添加QQ群837949026可以领取更多学习资料