Kafka、RabbitMQ、RocketMQ 之间的区别是什么 ?

布满荆棘的人生 2022-08-28 05:37 338阅读 0赞

Kafka采用拉取（Pull）方式消费消息，吞吐量相对更高，适用于海量数据收集与传递场景，例如日志采集和集中分析。

RabbitMQ在吞吐量方面略有逊色，但支持更多的消息队列功能。

RocketMQ出自 阿里公司的开源产品，用 Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进。在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

以下从性能、数据可靠性、服务可用性、功能等方面给出具体的对比分析，供用户选型参考。

## 性能 ##

消息中间件的性能主要衡量吞吐量，Kafka的吞吐量比RabbitMQ要高出1~2个数量级，RabbitMQ的单机QPS在万级别，Kafka的单机QPS能够达到百万级别。RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节，Kafka如果开启幂等、事务等功能，性能也会有所降低。

## 数据可靠性 ##

Kafka与RabbitMQ都具备多副本机制，数据可靠性较高。RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication。

## 服务可用性 ##

Kafka采用集群部署，分区与多副本的设计，使得单节点宕机对服务无影响，且支持消息容量的线性提升。RabbitMQ支持集群部署，集群节点数量有多种规格。RocketMQ是分布式架构，可用性高。

## 功能 ##

Kafka与RabbitMQ都是比较主流的两款消息中间件，具备消息传递的基本功能，但在一些特殊的功能方面存在差异，RocketMQ在阿里集团内部有大量的应用在使用。

Kafka采用拉取（Pull）方式消费消息，吞吐量相对更高，适用于海量数据收集与传递场景，例如日志采集和集中分析。

RabbitMQ在吞吐量方面略有逊色，但支持更多的消息队列功能。

以下从性能、数据可靠性、服务可用性、功能等方面给出具体的对比分析，供用户选型参考。

## 性能 ##

## 数据可靠性 ##

Kafka与RabbitMQ都具备多副本机制，数据可靠性较高。RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步Replication。

## 服务可用性 ##

## 功能 ##

**关于该问题的一些答复如下：**

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16][]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16 1][] ![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

**Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？**

![ce2a530f83177fa4645434d0cc8eb789.png][]

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16 4][]

**RabbitMQ架构**

RabbitMQ是一个分布式系统，这里面有几个抽象概念。

*  broker：每个节点运行的服务程序，功能为维护该节点的队列的增删以及转发队列操作请求。
 *  master queue：每个队列都分为一个主队列和若干个镜像队列。
 *  mirror queue：镜像队列，作为master queue的备份。在master queue所在节点挂掉之后，系统把mirror queue提升为master queue，负责处理客户端队列操作请求。注意，mirror queue只做镜像，设计目的不是为了承担客户端读写压力。

![5a9eda4943397a0c7f0352103438ebf9.png][]

如上图所示，集群中有两个节点，每个节点上有一个broker，每个broker负责本机上队列的维护，并且borker之间可以互相通信。集群中有两个队列A和B，每个队列都分为master queue和mirror queue（备份）。

**Kafka**

说实话，Kafka我觉得就是看到了RabbitMQ这个缺陷才设计出的一个改进版，改进的点就是：把一个队列的单一master变成多个master，即一台机器扛不住qps，那么我就用多台机器扛qps，把一个队列的流量均匀分散在多台机器上不就可以了么？注意，多个master之间的数据没有交集，即一条消息要么发送到这个master queue，要么发送到另外一个master queue。

这里面的每个master queue 在Kafka中叫做Partition，即一个分片。一个队列有多个主分片，每个主分片又有若干副分片做备份，同步机制类似于RabbitMQ。

![preview][]

如上图，我们省略了不同的queue，假设集群上只有一个queue（Kafka中叫Topic）。每个生产者随机把消息发送到主分片上，之后主分片再同步给副分片。

![963fce4db984d09232d8a5e2586ee183.png][]

队列读取的时候虚拟出一个Group的概念，一个Topic内部的消息，只会路由到同Group内的一个consumer上，同一个Group中的consumer消费的消息是不一样的；Group之间共享一个Topic，看起来就是一个队列的多个拷贝。

所以，为了达到多个Group共享一个Topic数据，Kafka并不会像RabbitMQ那样消息消费完毕立马删除，而是必须在后台配置保存日期，即只保存最近一段时间的消息，超过这个时间的消息就会从磁盘删除，这样就保证了在一个时间段内，Topic数据对所有Group可见（这个特性使得Kafka非常适合做一个公司的数据总线）。队列读同样是读主分片，并且为了优化性能，消费者与主分片有一一的对应关系，如果消费者数目大于分片数，则存在某些消费者得不到消息。

由此可见，Kafka绝对是为了高吞吐量设计的，比如设置分片数为100，那么就有100台机器去扛一个Topic的流量，当然比RabbitMQ的单机性能好。

**总结**

本文只做了Kafka和RabbitMQ的对比，但是开源队列岂止这两个，ZeroMQ，RocketMQ，JMQ等等，时间有限也就没有细看，故不在本文比较范围之内。

所以，别再被这些五花八门的队列迷惑了，从架构上找出关键差别，并结合自己的实际需求（比如本文就只单单从吞吐量一个需求来考察）轻轻松松搞定选型。最后总结如下：

*  吞吐量较低：Kafka和RabbitMQ都可以。
 *  吞吐量高：Kafka。

RocketMQ是一个由阿里巴巴开源的消息中间件， 2012年开源，2017年成为apache顶级项目。RocketMQ在阿里内部应用是非常广泛的，阿里内部的几千个应用都运行在RocketMQ之上，双十一期间需要处理亿万级别的消息，TPS可以达到几十万。目前支持Java、C/C++，Python、Go四种语言访问。

RocketMQ现在有两个版本，一个是社区开源版，一个是商业的云服务版（AliwareMQ）。最新版本：4.8.0（本文演示版本）。

它的核心设计借鉴了Kafka，所以我们在学习RocketMQ的时候，会发现很多和kafka相同的特性，但是在某些功能上和kafka又有较大的差异，它有以下一些特性：

*  支持集群模型、负载均衡、水平扩展能力
 *  亿级别消息堆积能力
 *  采用零拷贝的原理，顺序写盘，随机读
 *  底层通信框架采用Netty NIO
 *  NameServer代替Zookeeper，实现服务寻址和服务协调
 *  消息失败重试机制、消息可查询
 *  强调集群无单点，可扩展，任意一点高可用，水平可扩展
 *  经过多次双十一的考验

作者：华为云开发者社区  
链接：https://www.zhihu.com/question/275090117/answer/1689730565  
来源：知乎  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/08118d26e93d4e058ce9cee0a8ac298b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/987478202bf142e18f7ad1af24ca70ff.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBA6KaB5LqJ5rCU,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/23f16551cc834106adb192325f9bb628.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/b3e37d1e55f442a694ac0d5a9314b732.png
[ce2a530f83177fa4645434d0cc8eb789.png]: /images/20220828/ef7cc523afb24366a3e410dc6a790657.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6KaB5LqJ5rCU_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/bafee1814fb44553b63d013cfba63099.png
[5a9eda4943397a0c7f0352103438ebf9.png]: /images/20220828/04f47549639f41cb8d8aae488f2ad6ec.png
[preview]: /images/20220828/f2381b5427d0431baf4a98ae52f50f08.png
[963fce4db984d09232d8a5e2586ee183.png]: /images/20220828/e9a76904680b46d4b12272022e200a64.png