【技术选型】ActiveMQ、RocketMQ、RabbitMQ、Kafka对比

概述

MQ(Message Queue)，即消息队列。早已成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的MQ，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。

几种MQ的对比

下面我们先看下主流的几种MQ的对比，如下表格：

比较项	ActiveMQ	RabbitMQ	RocketMQ	Kafka
所属社区/公司	Apache	Mozilla Public License	阿里巴巴	Apache
成熟度及授权	成熟/开源	成熟/开源	比较成熟/开源	成熟/开源
开发语言	java	Erlang	java	Scala&java
客户端支持语言	Java、C/C++、Python、PHP、Perl、.net等	官方支持Erlang，java，Ruby等，社区产出多种语言API，几乎支持所有常用语言	Java、C++	官方支持java，开源社区有多语言版本，如PHP，Python，Go，C/C++，Ruby等
协议支持	OpenWire、STOMP、REST、XMPP、AMQP	多协议支持:AMQP，XMPP，SMTP，STOMP	自己定义的一套(社区提供JMS–不成熟)	自有协议，社区封装了HTTP协议支持
HA	基于ZooKeeper + LevelDB的Master-Slave实现方式	master/slave模式，master提供服务，slave仅作备份(冷备)	支持多Master模式，多Master多Slave模式，异步复制模式、同步双写	支持replica机制，leader宕掉后，备份自动顶替，并重新选举leader(基于Zookeeper)
数据可靠性	Master/slave，有较低的概率丢失数据	可以保证数据不丢，有slave用作备份	支持异步实时刷盘，同步刷盘，同步复制，异步复制	数据可靠，且有replica机制，有容错容灾能力
单机吞吐量	万级	万级	十万级，支撑高吞吐	十万级，高吞吐，一般配合大数据类的系统进行实时数据计算、日志采集等场景
消息延迟	毫秒级	微秒级	毫秒级	毫秒级以内
流量控制		基于Credit-Based算法，是内部被动触发的保护机制，作用于生产者层面。		支持client和user级别，通过主动设置可将流控作用于生产者或消费者。
持久化能力	默认内存，正常关闭时将内存中未处理的消息持久化文件，如果使用JDBC策略，则入数据库	内存、文件，支持数据堆积。但堆积反过来影响吞吐量	磁盘文件	磁盘文件。只要磁盘容量够，可以做到无限消息堆积
负载均衡	支持	支持	支持	支持
管理界面	一般	较好	命令行界面	官方只提供命令行版，yahoo开源自己的web管理界面
部署方式及难易	独立/容易	独立/容易	独立/容易	独立/容易
功能支持	MQ领域的功能较为完备	基于Erlang开发，并发能力很强，性能极好，时延很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集方面被大规模使用

综合以上对比后，有如下建议：

• 通常早期大家都使用ActiveMQ，现在使用的不多，毕竟没有经历过大规模吞吐量场景的验证，并且目前社区也不够活跃，不推荐使用。
• 而RoceketMQ来自阿里出品，目前有越来越多的公司尝试使用，反映确实不错。但社区活跃度不高，那些对自身公司技术实力信心满满的可以考虑。
• 而Kafka名声在外，之前在一家国产数据库公司时，当时的总架就讲解、推荐过。但目前来看，大数据领域的实时计算、日志采集等场景，kafka是业内标准，社区活跃度极高。有这方面的需求的，可以优先考虑。
• 最后对于RabbitMQ，无论从软件成熟度，社区活跃度(最新的release版是2019年12月的)，还是基本的吞吐能力，以及低时延，界面管理等方面，对于技术实力一般，技术挑战不是很高的公司，可以考虑。RabbitMQ是个不错的选择。
• 最后，没有完美的产品，只有合适的软件。技术选型毕竟还是要满足业务需求的，满足功能即可。