Kafka、RabbitMQ、RocketMQ、ActiveMQ消息中间件的对比--多年生产经验实践总结

引言

分布式系统中,咱们普遍运用消息中间件进行系统间的数据交换,便于异步解耦。如今开源的消息中间件有不少,前段时间咱们自家的产品 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。

附录：

测试环境

服务端为单机部署，机器配置以下：

 

应用版本：

 

测试脚本

 还有一个rocketmq/rabbitmq/kafka的对比，以下：

 除了上述特性外，rabbitmq和activemq都支持mqtt。activemq还支持ws（不过从tomcat 8开始，ws支持已经足够完善，没有必要为了ws使用rabbitmq或activemq）。

实践总结

这些年来，笔者普遍使用过rabbitmq、rocketmq、kafka，几年前主推rabbitmq，如今切换到主推kafka。

因此若是不追求极致性能的话，2c activemq仍是比较好的，能够同时支持app端mqtt和web端ws。中规中矩的话能够选择rabbtimq，毕竟最正统（这也是在除了日志和数据异步同步场景外使用最普遍的MQ）。若是同时涉及到多种场景，例如日志、同步、异步消息，安装三方库依赖等，推荐使用kafka。

虽然上面没有包含redis，对于一级缓存之间的同步，采用redis消息队列也是一种可接受的方案，即便它不正统，可是某些状况下就是不须要MQ，可是又是集群的时候，redis队列就能够做为退化版MQ使用。

 参考：

kafka学习指南(总结版)

https://www.cnblogs.com/zhjh256/p/6444398.html

activemq支持的各类协议以及性能：http://haoran-10.iteye.com/blog/2259240

异步消息传递技术的比较：JMS、AMQP和MQTT http://blog.csdn.net/yongche_shi/article/details/52116755

web链接activemq ws：D:/apache-activemq-5.15.0/webapps-demo/demo/mqtt/index.html