前言
本文将从业内主流的消息队列中选择三种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：可靠消息传输