对比
参数项
| 对比项 | kafka | rabbitmq |
|---|---|---|
| 开发语言 | scala, Java | erlang |
| 是否支持多租户 | 2.x.x 支持多租户 | 支持多租户 |
| 是否支持 topic 优先级 | 不支持 | 支持 |
| 是否支持消息全局有序 | 不支持 | 支持 |
| 是否支持消息分区有序 | 支持 | 支持 |
| 是否内置监控 | 无内置监控 | 内置监控 |
| 是否支持多个生产者 | 一个 topic 支持多个生产者 | |
| 是否支持多个消费者 | 一个 topic 支持多个消费者 | |
| 是否支持一个分区多个消费者 | 不支持 | 不支持 |
| 是否支持 JMX | 支持 | 不支持(非 Java 语言编写) |
| 是否支持加密 | 支持 | 支持 |
| 消息队列协议支持 | 仅支持自定义协议 | 支持 AMQP、MQTT、STOMP 协议 |
| 客户端语言支持 | 支持多语言客户端 | 支持多语言客户端 |
| 是否支持消息追踪 | 不支持 | 支持 |
| 是否支持消费者推模式 | 不支持 | 支持 |
| 是否支持消费者拉模式 | 支持 | 支持 |
| 是否支持广播消息 | 支持 | 支持 |
| 是否支持消息回溯 | 支持消息回溯，因为消息持久化，消息被消费后会记录 offset 和 timstamp | 不支持，消息确认被消费后，会被删除 |
| 是否支持消息数据持久化 | 支持 | 支持 |
| 是否支持消息堆积 | 支持消息堆积，并批量持久化到磁盘 | 支持阈值内的消息对接，无法支持较大的消息堆积 |
| 是否支持流量控制 | 支持控制用户和客户端流量 | 支持生产者的流量控制 |
| 是否支持事务性消息 | 支持 | 不支持 |
| 元数据管理 | 通过 zookeeper 进行管理 | 支持消息数据持久 |
| 默认服务端口 | 9200 | 5672 |
| 默认监控端口 | kafka web console 9000;kafka manager 9000; | 15672 |
| 网络开销 | 相对较小 | 相对较大 |
| 内存消耗 | 相对较小 | 相对较大 |
| cpu 消耗 | 相对较大 | 相对较小 |
功能项
| 对比项 | Kafka | rabbitmq |
|---|---|---|
| 模型架构 | 遵从一般的 MQ 结构，producer, broker, consumer，以 consumer 为中心，消息的消费信息保存的客户端 consumer 上，consumer 根据消费的点，从 broker上批量 pull 数据。 | 遵循 AMQP 协议，RabbitMQ 的 broker 由 Exchange, Binding, Queue组成，其中 Exchange 和 Binding 组成了消息的路由键；客户端 Producer 通过连接 Channel 和 server 进行通信，Consumer 从 Queue 获取消息进行消费（长连接，Queue 有消息会推送到 consumer 端，consumer 循环从输入流读取数据）。rabbitMQ 以 broker 为中心。 |
| 消息确认机制 | 不具有应答机制。 | 具有生产者 confirm 机制以及消费者的消息应答机制 ack。 |
| 消息的顺序 | 在同一个 partition 中消息是有序的，但是生产者 put 到 Kafka 中数据会分布在不同的 partition 中，所有总体是无序的。 | 在一个队列里面，rabbitmq 的消息是严格顺序的，按照先进先出。 |
| 吞吐量 | 具有巨大的吞吐量，数据的存储以及获取是本地磁盘的批量处理，可以达到百万/s。 | 根据测试，在不使用ACK机制的，Msg 大小为 1K 的情况下，QPS 可达6W＋。在双方 ACK 机制，Msg大小为1K的情况下，QPS 瞬间降到了 1W＋。 |
| 可靠性 | Kafka 的 broker 支持主备模式。 | 使用了 MirrorQueue 的机制，也可以做到多个机器进行热备。 |
实际场景选择
在实际生产应用中，通常会使用 kafka 作为消息传输的数据管道，rabbitmq 作为交易数据作为数据传输管道，主要的取舍因素则是是否存在丢数据的可能；rabbitmq 在金融场景中经常使用，具有较高的严谨性，数据丢失的可能性更小，同事具备更高的实时性；而 kafka 优势主要体现在吞吐量上，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如 rabbitmq；而且由于 kafka 保证每条消息最少送达一次，有较小的概率会出现数据重复发送的情况。
rabbitmq
- RabbitMQ 的消息应当尽可能的小，并且只用来处理实时且要高可靠性的消息。
- 消费者和生产者的能力尽量对等，否则消息堆积会严重影响RabbitMQ的性能。
- 集群部署，使用热备，保证消息的可靠性。
Kafka
- 应当有一个非常好的运维监控系统，不单单要监控 Kafka 本身，还要监控 Zookeeper。（ kafka 强烈的依赖于 zookeeper，如果 zookeeper 挂掉了，那么 Kafka 也不行了）
- 对消息顺序不依赖，可以作为一个准实时的系统。
- 对消息丢失并不那么敏感的系统。
- 从 A 到 B 的流传输，无需复杂的路由，最大吞吐量可达每秒 100k 以上。