# 消息中间件对比
| 对比大类 | 对比子类 | 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以外支持的不是很友好，待优化。 |