前言
本文将从业内主流的消息队列中选择三种Kafka、RocketMQ、RabbitMQ,分别从基础项、可用性,可靠性、功能对比来分析一下三者的优缺点;
正文
基础项对比
对比项 |
kafka |
RocketMQ |
RabbitMQ |
成熟度 |
日志领域应用广泛@1 |
成熟 |
成熟 |
公司/社区 |
Apache |
Apache |
Mozilla PublicLicense |
活跃程度 |
高 |
高 |
高 |
API完备性 |
高 |
高 |
高 |
文档完备性 |
完善 |
完善 |
完善 |
客户端语言 |
Java、C++、Python、Go |
Java |
Java、C++、Python |
解释说明
@1 ELK的玩法由flume收集日志发往kakfa集群,然后给logstash,最后发往es,在kibana展示出来
可用性、可靠性对比
对比项 |
kafka |
RocketMQ |
RabbitMQ |
部署方式 |
集群 |
集群 |
集群 |
集群管理 |
Zookeeper |
name server@1 |
Erlang天然支持 |
选主方式 |
自动选举 |
不支持 |
最早加入的节点 |
主从切换 |
自动切换 |
不支持自动切换 |
自动切换 |
数据可靠性 |
高 |
高 |
高 |
性能 |
非常高@2 |
高 |
中 |
可用性 |
分布式、主从 |
分布式、主从 |
主从@3 |
堆积能力@4 |
非常好 |
非常好 |
一般 |
解释说明
- @1 自研的一款组件,代码只有千行左右。
- @2 kafka的亮点,单机在百万左右,rocketMQ单机在10万级别,Rabbit吞吐量在万级别
- @3 rabbit 不支持分布式
- @4 堆积能力指的是下游不消费消息了MQ能不能堆积这些消息
功能对比
对比项 |
Kafka |
RocketMQ |
RabbitMQ |
顺序消息@1 |
支持 |
支持 |
支持 |
延时消息 |
不支持 |
只支持特定Level@2 |
不支持@3 |
事务消息 |
不支持 |
支持 @4 |
不支持 |
消息过滤@5 |
支持 |
支持 |
不支持 |
消息查询 |
不支持@6 |
支持 |
不支持 |
消费失败重试 |
不支持 |
支持 |
支持 |
批量发送 |
支持 |
支持 |
不支持 |
-
解释说明
- @1 顺序消息:生产顺序和消费顺序一致;举例S1和S2 分别生产了 AB、CD、那么消费者C3 消费的消息的顺序就是ABCD;如何达到这个目的呢?
- 生产方只有一个生产者
- MQ内部使用一个队列存放
- 消费方只能有一个,且必须是单线程消费
- 消费消息的时候C失败了,D就不能消费了,那么C3就卡住了,所以很多MQ声称支持顺序消息,关键在于你怎么去用。
- @2 只支持特定的level:messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h 6h 12h
- @3 可以通过rabbitmq-delayed-message-exchange 这种插件方式或者死信队列的方式去解决
- @4 虽然支持但是对业务侵入性较大
- @5 消息过滤 P1生产了100万条消息,但是C2 只对其中的1万感兴趣,如果直接打过来100万,其中99万会浪费带宽,那么久在MQ进行消息过滤,指给C2 1万的消息
- @6 kafka 高吞吐量就是打包生产消息,高消费
-
同样是消息队列,差异如此之大?
- Kafka:系统间的数据流通道,大数据的适合OLAP
- RocketMQ:高性能可靠消息传输,适合OLTP
- RabbitMQ:可靠消息传输