常见消息队列中间件对比

名称 　特性	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,_eJS等语言
协议支持	OpenWire、 STOMP、 REST, XMPP、AMQP	多协议支持:AMQP, XMPP, SMTP, STOMP	白己定义的一 套(社区提供JMS--不成熟）	自有协议，社区封装了HTTP协议支持
消息批量操作	支持	不支持	支持	支持
消息推拉模式	多协议，Pull/Push均有支持	多协议，Pull/Push均有支持	多协议，Pull/Push均有支持	Pull
HA	基于ZooKeeper+ LevelDB的Master-Slave实现方式	master/slave模式，master供服务，slave仅作备份	支持多Master模式、多Master多 Slave模式，异步 复制模式、多 Master 多 Slave 模式，同步双写	支持replica机制，leader宕掉后，备份自动顶替，并重新选举leader(基于 Zookeeper)
数据可靠性	master/slave(有较低的概率丢失数据)	可以保证数据不丢，有slave用作备份	经过参数优化配置，可以做到0丢失 支持异步实时刷新，同步刷盘，同步复制，异步复制	经过参数优化配置，消息可以做到0丢失 数据可靠,并且有replica机制，有容错容灾能力
单机吞吐量	最差(万级）	其次(万级）	最高(十万级）	次之(十万级）
topic数量对吞吐量的影响	/	/	topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降，topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降	topic从几十个到几百个的时候，吞吐量会大幅度下降，所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
消息延迟	毫秒ms级	微秒μs级（最低）	毫秒ms级（比kafka快）	毫秒ms级
可用性	高，基于主从架构实现高可用性	高，基于主从架构实现高可用性	非常高，分布式架构	非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
持久化能力	内存、文件、数据库	内存、文件，支持数据堆积，但数据堆积反过来影响生产速率	磁盘文件	磁盘文件，只要磁盘容量够，可以做到无限消息堆积
是否有序	可以支持有序	若想有序，只能使用一个Client	有序	多Client保证有序
事务支持	支持	不支持	支持	不支持，但可以通过LOW Level AP保证仅消费一次
集群	支持	支持	支持	支持
负载均衡	支持	支持	支持	支持
管理界面	一般	较好	命令行界面（没有图形化界面）	官方只提供了命令行版，Yahoo幵源自己的Kafka Web管理界面Kafka-Manager
部署方式	独立	独立	独立	独立
使用场景	/	电商、金融 等对事务一致性要求很高的场景		性能要求高的场景（主要适用于日志收集，数据采集）
优势总结	1.非常成熟，功能强大，在业内大量的公司以及项目中都有应用	1.erlang语言开发，性能极其好，延时很低； 2.吞吐量到万级，MQ功能比较完备 3.开源提供的管理界面非常棒，用起来很好用 4.社区相对比较活跃，几乎每个月都发布几个版本分 5.在国内一些互联网公司近几年用rabbitmq也比较多一些	1.接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障 2.日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景 3.阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控	1.仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展 2.kafka最好是支撑较少的topic数量即可，保证其超高吞吐量
劣势总结	1.偶尔会有较低概率丢失消息 2.现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本 3.ActiveMQ主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用	1.RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。 2.erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。 3.rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。	1.社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码 2.阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的	1.kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集