综述
-
Kafka
- 采用拉取 ( Pull) 方式消费消息，吞吐量相对更高，适合海量数据收集与传递场景，例如日志采集和集中分析
- 缺点
- Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息延时更长
- 不支持延迟发送，不支持消息重试
-
RocketMQ
- 基于 Java 语言开发，天生为金融互联网领域而生，适用于对数据可靠性要求很高、数据实时性要求高、Topic 数量非常多的场景，如订单、交易、充值、流计算等
- 缺点
- 支持的客户端语言不多，目前是 java c++ Go
-
RabbitMQ
- 基于 Erlang 语言开发，不利于做二次开发和维护，适用于对路由、负载均衡、数据一致性、稳定性和可靠性要求很高，对性能和吞吐量的要求没那么高的场景，社区活跃度高
- 缺点
- RabbitMQ 吞吐量会低一些，这是因为他做的实现机制比较重
- 不支持消息有序、持久化不好、不支持消息回溯、伸缩性一般
对比
| 功能项目 | RocketMQ | Kafka | RabbitMQ |
|---|---|---|---|
| 优先级队列 | 不支持 | 不支持 | 支持。建议优先级大小设置在0-10之间 |
| 延迟队列 | 支持 | 不支持 | 支持 |
| 死信队列 | 支持（商业版支持） | 不支持 | 支持 |
| 消息重试 | 支持 | 不支持 | 不支持 |
| 消费模式 | 支持客户端主动拉取和服务端推送两种方式 | 客户端主动拉取 | 支持客户端主动拉取以及服务端推送两种模式 |
| 广播消费 | 支持 | 支持 | 支持 |
| 消息回溯 | 支持 | 支持。Kafka支持按照offset和timestamp两种维度进行消息回溯 | 不支持。RabbitMQ中消息一旦被确认消费就会被标记删除 |
| 消息堆积 | 支持 | 支持。考虑吞吐因素，Kafka的堆积效率比RabbitMQ总体上要高 | 支持 |
| 持久化 | 支持 | 支持 | 支持 |
| 消息追踪 | 支持 | 不支持 | 支持。采用Firehose或者rabbitmq_tracing插件实现，但开启rabbitmq_tracing插件会影响性能，建议只在定位问题过程中开启 |
| 消息过滤 | 支持 | 支持 | 不支持，但可以自行封装 |
| 多租户 | 支持 | 不支持 | 支持 |
| 多协议支持 | 兼容RocketMQ协议 | 只支持Kafka自定义协议 | RabbitMQ基于AMQP协议实现，同时支持MQTT、STOMP等协议 |
| 跨语言支持 | 支持多语言的客户端 | 采用Scala和Java编写，支持多种语言的客户端 | 采用Erlang编写，支持多种语言的客户端 |
| 流量控制 | 不支持 | 支持client和user级别，通过主动设置可将流控作用于生产者或消费者 | RabbitMQ的流控基于Credit-Based算法，是内部被动触发的保护机制，作用于生产者层面 |
| 消息顺序性 | 单队列（queue）内有序 | 支持单分区（partition）级别的顺序性 | 不支持。需要单线程发送、单线程消费并且不采用延迟队列、优先级队列等一些高级功能整体配合，才能实现消息有序 |
| 安全机制 | 支持SSL认证 | 支持SSL、SASL身份认证和读写权限控制 | 与Kafka相似 |
| 事务性消息 | 支持 | 支持 | 支持 |
一张图
参考
Why choose RocketMQ
Comparing RocketMQ, Kafka, and RabbitMQ
