分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间我们自家的产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注。
那么,消息中间件性能究竟哪家强?
带着这个疑问,我们中间件测试组对常见的三类消息产品(Kafka、RabbitMQ、RocketMQ)做了性能比较。
Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache定级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。
RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
测试目的
对比Kafka、RabbitMQ、RocketMQ发送小消息(124字节)的性能。这次压测我们只关注服务端的性能指标,所以压测的标准是:
不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。这时服务端已出现性能瓶颈,可以获得相应的系统最佳吞吐量。
测试场景
在同步发送场景中，三个消息中间件的表现区分明显：
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,在互联网应用场景中更有它优越的一面。
接下来我们会围绕分区数量、消息大小、消费形式等不同的影响因子,对三类消息中间件做对比。敬请期待后续报告!
几种MQ产品说明：
ZeroMQ : 扩展性好，开发比较灵活，采用C语言实现，实际上他只是一个socket库的重新封装，如果我们做为消息队列使用，需要开发大量的代码
RabbitMQ :结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护
ActiveMQ: 历史悠久的开源项目，已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多）.，支持持久化到数据库，对队列数较多的情况支持不好，不过我们的项目中并不会建很多的队列.
Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展
RocketMQ: 阿里巴巴的MQ中间件，在其多个产品下使用，并能够撑住双十一的大流量，他并没有实现JMS规范，使用起来很简单。部署由一个 命名服务（nameserver）和一个代理（broker）组成，nameserver和broker以及producer都支持集群，队列的容量受机器硬盘的限制，队列满后可以支持持久化到硬盘（也可以自己适配代码，将其持久化到NOSQL数据库中），队列满后会影响吞吐量，可以采用主备来保证稳定性，支持回溯消费，可以在broker端进行消息过滤.
针对消息中间件的选择可以从以下方面进行考虑：(主要对比ActiveMQ和RocketMQ)
优先级：我们的项目对此需求不是特别明显，RocketMQ需要新建一个特殊队列来接收优先级高的队列，无法实现从0-65535这种细粒度的控制，ActiveMQ可以精细控制
顺序：我们的消息总线中的消息应该都是无状态的，所以对消息的处理顺序没有严格的要求，如果有特殊要求的话可以在业务层进行控制，activeMQ无法保证严格的顺序，RocketMQ可以保证严格的消费顺序
持久化：都支持
稳定性：RoketMQ在稳定性上可能更值得信赖，支持多种集群方案，毕竟已经撑过几个双十一
消息过滤：ActiveMQ仅支持在客户端消费的时候进行判断是否是自己需要的消息，RocketMQ可以在broker端进行过滤，对于我们的消息总线，这里可以节省大量的网络传输是否会有消息重发造成的重复消费：RocketMQ可以保证，ActiveMQ无法保证
回溯消费：即重新将某一个时刻之前的消息重新消费一遍，我们对于这种需求应该很少，RocketMQ支持，ActiveMQ不支持（RocketMQ的队列是持久化到硬盘的，定期进行清除
事务：都支持
定时消费：RocketMQ支持
消息堆积：就是当缓存消息的内存满了之后的解决方案，一种是丢弃策略，这种不会影响吞吐量，还有一种就是将消息持久化到磁盘，这种会影响吞吐量，在评估影响程度上，RocketMQ的成绩稍微好一点
客户端不在线：RocketMQ可以在客户端上线后继续将未消费的消息推送到客户端
目前比较活跃的几种MQ中间件产品的对比如下：（仅统计开源的项目）
| ActiveMQ | RabbitMQ | RocketMq | ZeroMQ | |
| 关注度 | 高 | 高 | 中 | 中 |
| 成熟度 | 成熟 | 成熟 | 比较成熟 | 不成熟 |
| 所属社区/公司 | Apache | Mozilla Public License |
Alibaba | |
| 社区活跃度 | 高 | 高 | 中 | 低 |
| 文档 | 多 | 多 | 中 | 中 |
| 特点 | 功能齐全，被大量开源项目使用 | 由于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 等 |
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 等接口， |