| -- |
-- |
kafka |
RocketMQ |
RabbitMQ |
| 定位 |
设计定位 |
系统间的数据流管道，实时数据处理。
例如：常规的消息系统、网站活性跟踪，监控数据，日志收集、处理等 |
非日志的可靠消息传输。
例如：订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等 |
可靠消息传输。和 RocketMQ 类似。 |
| 基础对比 |
成熟度 |
日志领域成熟 |
成熟 |
成熟 |
| 所属社区／公司 |
Apache |
Alibaba 开发，已加入到 Apache 下 |
Mozilla Public License |
| 社区活跃度 |
高 |
中 |
高 |
| API 完备性 |
高 |
高 |
高 |
| 文档完备性 |
高 |
高 |
高 |
| 开发语言 |
Scala |
Java |
Erlang |
| 支持协议 |
一套自行设计的基于 TCP 的二进制协议 |
自己定义的一套
(社区提供 JMS-- 不成熟) |
AMQP |
| 客户端语言 |
C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP 等 |
Java |
Java、C、 C++、 Python、 PHP、Perl 等 |
| 持久化方式 |
磁盘文件 |
磁盘文件 |
内存、文件 |
| 可用性、可靠性比较 |
顺序消费 |
支持顺序消费
但是一台 Broker 宕机后，就会产生消息乱序 ( 来自网上，尚未找到原因） |
支持顺序消费
在顺序消息场景下，消费失败时消费队列将会暂停 |
支持顺序消费 |
| 定时消息 |
不支持 |
开源版本仅支持定时 Leve |
不支持 |
| 事务消息 |
不支持 |
支持 |
不支持 |
| Broker 端消息过滤 |
不支持 |
支持
通过 tag 过滤，类似于子 topic |
不支持 |
| 消息查询 |
不支持 |
支持
根据 MessageId 查询
支持根据 MessageKey 查询消息 |
不支持 |
| 消费失败重试 |
不支持失败重试
offset 存储在 consumer 中，无法保证。
0.8.2 版本后支持将 offset 存储在 zk 中 |
支持失败重试
offset 存储在 broker 中 |
支持失败重试 |
| 消息重新消费 |
支持通过修改 offset 来重新消费 |
支持按照时间来重新消息 |
-- |
| 发送端负载均衡 |
可自由指定 |
可自由指定 |
需要单独 loadbalancer 支持 |
| 消费并行度 |
消费并行度和分区数一致 |
顺序消费：消费并行度和分区数一致
乱序消费：消费服务器的消费线程数之和 |
可一次抓取多条一起消费。
镜像模式下其实也是从 master 消费 |
| 消费方式 |
consumer pull |
consumer pull ／broker push |
broker push |
| 批量发送 |
支持
默认 producer 缓存、压缩，然后批量发送 |
不支持 |
不支持 |
| 消息清理 |
指定文件保存时间，过期删除 |
指定文件保存时间，过期删除 |
Consumer ack 以后，消息将被标记为删除
可用内存少于 40%（默认），触发 gc，gc 时找到相邻的两个文件，合并 right 文件到 left。 |
| 运维 |
系统维护 |
Scala 语言开发，维护成本高 |
java 语言开发，维护成本低 |
Erlang 语言开发，维护成本高 |
| 部署依赖 |
zookeeper |
nameserver |
Erlang 环境 |
| 管理后台 |
官网不提供，第三方开源管理工具可供使用；不用重新开发 |
官方提供，rocketmq-console |
官方提供 rabbitmqadmin |
| 管理后台功能 |
功能 Kafka Web Conslole
Brokers 列表；Kafka 集群中 Topic 列表，及对应的 Partition、LogSize 等信息；Topic 对应的 Consumer Groups、Offset、Lag 等信息；
生产和消费流量图、消息预览
KafkaOffsetMonitor：
Kafka 集群状态；Topic、Consumer Group 列表；图形化展示 topic 和 consumer 之间的关系；图形化展示 consumer 的 Offset、Lag 等信息
Kafka Manager
管理几个不同的集群；监控集群的状态 (topics, brokers, 副本分布, 分区分布)；产生分区分配(Generate partition assignments) 基于集群的当前状态；重新分配分区 |
Cluster、Topic、Connection、NameServ、Message、Broker、Offset、Consumer |
overview、connections、channels、exchanges、queues、admin |
| 总结 |
优点 |
1、在高吞吐、低延迟、高可用、集群热扩展、集群容错上有非常好的表现；
2、producer 端提供缓存、压缩功能，可节省性能，提高效率。
3、提供顺序消费能力
4、提供多种客户端语言
5、生态完善，在大数据处理方面有大量配套的设施。 |
1、在高吞吐、低延迟、高可用上有非常好的表现；消息堆积时，性能也很好。
2、api、系统设计都更加适在业务处理的场景。
3、支持多种消费方式。
4、支持 broker 消息过滤。
5、支持事务。
6、提供消息顺序消费能力；consumer 可以水平扩展，消费能力很强。
7、集群规模在 50 台左右，单日处理消息上百亿；经历过大数据量的考验，比较稳定可靠。 |
1、在高吞吐量、高可用上较前两者有所不如。
2、支持多种客户端语言；支持 amqp 协议。
3、由于 erlang 语言的特性，性能也比较好; 使用 RAM 模式时，性能很好。
4、管理界面较丰富，在互联网公司也有较大规模的应用; |
| 缺点 |
1、消费集群数目受到分区数目的限制。
2、单机 topic 多时，性能会明显降低。
3、不支持事务 |
1、相比于 kafka，使用者较少，生态不够完善。消息堆积、吞吐率上也有所不如。
2、不支持主从自动切换，master 失效后，消费者需要一定的时间才能感知。
3、客户端只支持 Java |
1、erlang 语言难度较大。集群不支持动态扩展。
2、不支持事务、消息吞吐能力有限
3、消息堆积时，性能会明显降低
|
