Kafka与RabbitMQ的差异
Kafka采用拉取（Pull）方式消费消息，吞吐量相对更高，适用于海量数据收集与传递场景，例如日志采集和集中分析。RabbitMQ在吞吐量方面略有逊色，但支持更多的消息队列功能。
以下从性能、数据可靠性、服务可用性、功能等方面给出具体的对比分析，供用户选型参考。
性能
消息中间件的性能主要衡量吞吐量，Kafka的吞吐量比RabbitMQ要高出1~2个数量级，RabbitMQ的单机QPS在万级别，Kafka的单机QPS能够达到百万级别。
Kafka如果开启幂等、事务等功能，性能也会有所降低。
数据可靠性
Kafka与RabbitMQ都具备多副本机制，数据可靠性较高。
服务可用性
Kafka采用集群部署，分区与多副本的设计，使得单代理宕机对服务无影响，且支持消息容量的线性提升。
功能
Kafka与RabbitMQ都是比较主流的两款消息中间件，具备消息传递的基本功能，但在一些特殊的功能方面存在差异，以下给出Kafka与RabbitMQ两个开源社区版本的比较。
|
功能项 |
Kafka（1.1.0/2.3.0版本） |
RabbitMQ（3.7.17版本） |
|---|---|---|
|
优先级队列 |
不支持 |
支持。建议优先级大小设置在0-10之间。 |
|
延迟队列 |
不支持 |
支持 |
|
死信队列 |
不支持 |
支持 |
|
重试队列 |
不支持 |
不支持 |
|
消费模式 |
客户端主动拉取 |
支持客户端主动拉取以及服务端推送两种模式。 |
|
广播消费 |
支持 |
支持 |
|
消息回溯 |
支持。Kafka支持按照offset和timestamp两种维度进行消息回溯。 |
不支持。RabbitMQ中消息一旦被确认消费就会被标记删除。 |
|
消息堆积 |
支持。考虑吞吐因素，Kafka的堆积效率比RabbitMQ总体上要高。 |
支持 |
|
持久化 |
支持 |
支持 |
|
消息追踪 |
不支持 |
支持。RabbitMQ中可以采用Firehose或者rabbitmq_tracing插件实现，但开启rabbitmq_tracing插件会影响性能，建议只在定位问题过程中开启。 |
|
消息过滤 |
支持 |
不支持，但可以自行封装。 |
|
多租户 |
不支持 |
支持 |
|
多协议支持 |
只支持Kafka自定义协议。 |
RabbitMQ基于AMQP协议实现，同时支持MQTT、STOMP等协议。 |
|
跨语言支持 |
采用Scala和Java编写，支持多种语言的客户端。 |
采用Erlang编写，支持多种语言的客户端。 |
|
流量控制 |
支持client和user级别，通过主动设置可将流控作用于生产者或消费者。 |
RabbitMQ的流控基于Credit-Based算法，是内部被动触发的保护机制，作用于生产者层面。 |
|
消息顺序性 |
支持单分区（partition）级别的顺序性。 |
不支持。需要单线程发送、单线程消费并且不采用延迟队列、优先级队列等一些高级功能整体配合，才能实现消息有序。 |
|
安全机制 |
支持SSL、SASL身份认证和读写权限控制。 |
与Kafka相似 |
|
幂等性 |
支持单个生产者单分区单会话的幂等性。 |
不支持 |
|
事务性消息 |
支持 |
支持 |
以上对比内容仅代表开源版本间的比较。
分布式消息服务提供的Kafka与RabbitMQ，在兼容开源协议的基础上，对版本特性做了部分支持或者增强。
