# 消息中间件对比

对比大类 对比子类 RabbitMQ Apache Kafka Apache RocketMQ
基础对比 设计定位 可靠消息传递 实时数据处理以及日志处理 可靠消息传递、消息严格有序与分布式事务协调
基础对比 成熟度 成熟 日志领域成熟 相对成熟
基础对比 所属社区 Pivotal Apache Apache
基础对比 社区活跃度
基础对比 支持协议 能支持大量协议,如AMQP、STOMP、MQTT、OpenMessaging等等 TCP、JMS、OpenMessaging TCP、JMS, OpenMessaging
基础对比 多租户 支持vhost形式的多租户 2.x.x支持用户权限隔离 支持用户权限隔离
基础对比 开发语言 Erlang Scala,Java Java
高可用对比 部署方式 单点/多活/主备 单点/主备 单点/多主多从
高可用对比 集群管理 独立 强依赖zookeeper 独立,无第三方依赖
高可用对比 主从选主策略 (a) 镜像模式:即Master-Slave模式,由运行时间最久的节点接管Master;(b) 3.8.x支持Raft选举策略的“仲裁队列”,保证高可用和强一致; 基于Zookeeper选出Controller节点进行协调 Master-Slave模式,4.7.x版本支持基于Raft协议的选举策略,保证可用性以及强一致
高可用对比 部署要求 镜像模式2台可集群,仲裁模式至少3台 zookeeper要求至少3台,Kafka可2台 Dledger模式至少3台
高可用对比 持久化方式 内存/磁盘文件 磁盘文件 磁盘文件
性能对比 消息写入性能 内存消息较快,磁盘消息较慢 磁盘顺序写,非常快 磁盘顺序写,很快
单机队列数 依赖内存,队列数无上限控制 单机超过64队列或分区会出现磁盘IO飙高造成抖动 依赖内存,官方宣称可支持百万个队列
topic动态管理 支持 支持 支持
topic优先级 支持 不支持 不支持
消息Topic全局有序 不支持 支持
消息Topic分区有序 支持 支持 支持
监控 支持,且可以RESTful对接 不支持(JMX采集) 支持(RPC调用采集)
单分区/队列多个消费者 支持 不支持 不支持
是否支持JMX 不支持(非java语言编写) 支持 支持
是否支持加密通信 支持 支持 不支持
消息队列协议支持 支持AMQP、MQTT、STOMP协议 仅支持自定义协议 内置协议、MQTT、STOMP
客户端支持语言 JAVA、C、C++、Python、Go、PHP等 Java、C、C++、Python、PHP、Perl、.net等 Java(支持良好)、C++与Golang支持一般
消息追踪Tracking 支持 不支持 支持
消费者推模式 支持 不支持 支持
消费者拉模式 支持 支持 支持
集群订阅 支持 支持 支持
广播订阅 支持 支持 支持
消息回溯 不支持 支持 支持
定时投递 不支持 不支持 支持
延时投递 支持 不支持 支持
消息持久化 支持 支持 支持
海量堆积 不支持 支持 支持
流控限制 有(单队列限制写入速率) 没有 没有
事务提交 支持 支持 支持
消息过滤 不支持 不支持 支持(tag表达式以及SQL92标准)
消息查询 支持查询未消费的消息 支持 支持
消费ACK模式 支持 支持 支持
生产confirm模式 支持 支持 支持
消息压缩 不支持 支持 支持
批量发送 不支持 支持 支持
消息自动清理 阅后即焚模式 支持 支持
Web终端推送 JS 、LUA sdk JS、LUA sdk 不支持
延时级别 毫秒级 毫秒级 毫秒级
网络消耗
内存消耗
磁盘IO
cpu消耗
总结 优点:
1. 支持大量协议,在异步解耦方面具有绝对优势。有大量成功的案例。
2. 可靠的消息传递,结合AMQP协议灵活的消息路由策略,支撑复杂的场景。
3. 客户端语言种类涵盖大部分主流开发语言,开发门槛降低。
4. 功能丰富的Web管控台,完善的配套
5. 3.8.x版本新增仲裁队列模式,有效解决分区问题。
6. 支持vhost数据隔离。
7. 社区活跃,文档丰富。

缺点:
1. 性能相对Kafka、RocketMQ较低,不太适合高性能场景。
2. 消息广播模式采用的是内存复制模式,性能低下,且占用大量内存和CPU,比如行情推送场景不太适合。
3. 镜像模式容易产生分区,造成数据不一致风险高。
4. 有序消费场景下,性能低下,和Kafka相差甚远。
优点:
1. 高吞吐、高性能表现优异,尤其适合大数据场景。
2. 分区有序,且高性能,可以满足特定场景(如数据同步)。
3. 使用 “零拷贝”与磁盘顺序写的特性,对系统CPU和内存资源占用低。
4. 在大数量领域生态完善,有很多成功的案例。
5. 社区活跃,文档丰富。

缺点:
1. 不能支持大量Topic,否则性能会严重下降。对于复杂业务不太使用。
2. 在通用消息功能相对薄弱,不能支持如延时消息、死信队列、消息有效期等特性。很难支持复杂的业务逻辑。
3. 消费Rebalance机制在订阅者数量较多时,耗时较长,甚至失败。
4. 无Web管控台,可以使用第三方。
优点:
1. 高吞吐、高可用、低延时,且在4.7.x版本支持Raft选主,集群容错性以及一致性表现良好。性能虽不如Kafka,但是也非常不俗。
2. 支持全局有序以及分区有序消息,能够支持消费要求严格有序的场景。
3. 支持服务端消息过滤,能减少无用的消息传递,节省资源。
4. 严格意义上的磁盘顺序写,且不受topic数量的影响。
5. 分布式事务消息能协调跨系统间的事务,保证事务一致性(XA)。
6. Java语言编写,受众度广。

缺点:
1. 社区活跃度相对较低,issue处理速度相对较慢。文档不够完善。
2. DLedger模式(Raft)为近期发版的新特性,稳定性有待验证。
3. 客户端在Java以外支持的不是很友好,待优化。
最近更新时间: 2021/10/11 18:28:22