消息中间件如何选型图解 Kafka vs RabbitMQ vs RocketMQ 的差异

69 阅读 0 评论 46 点赞

我是靠谱客的博主友好百合，最近开发中收集的这篇文章主要介绍消息中间件如何选型图解 Kafka vs RabbitMQ vs RocketMQ 的差异，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

综述

Kafka
- 采用拉取 ( Pull) 方式消费消息，吞吐量相对更高，适合海量数据收集与传递场景，例如日志采集和集中分析
- 缺点
  - Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，load 越高，发送消息延时更长
  - 不支持延迟发送，不支持消息重试
RocketMQ
- 基于 Java 语言开发，天生为金融互联网领域而生，适用于对数据可靠性要求很高、数据实时性要求高、Topic 数量非常多的场景，如订单、交易、充值、流计算等
- 缺点
  - 支持的客户端语言不多，目前是 java c++ Go
RabbitMQ
- 基于 Erlang 语言开发，不利于做二次开发和维护，适用于对路由、负载均衡、数据一致性、稳定性和可靠性要求很高，对性能和吞吐量的要求没那么高的场景，社区活跃度高
- 缺点
  - RabbitMQ 吞吐量会低一些，这是因为他做的实现机制比较重
  - 不支持消息有序、持久化不好、不支持消息回溯、伸缩性一般

对比

功能项目	RocketMQ	Kafka	RabbitMQ
优先级队列	不支持	不支持	支持。建议优先级大小设置在0-10之间
延迟队列	支持	不支持	支持
死信队列	支持（商业版支持）	不支持	支持
消息重试	支持	不支持	不支持
消费模式	支持客户端主动拉取和服务端推送两种方式	客户端主动拉取	支持客户端主动拉取以及服务端推送两种模式
广播消费	支持	支持	支持
消息回溯	支持	支持。Kafka支持按照offset和timestamp两种维度进行消息回溯	不支持。RabbitMQ中消息一旦被确认消费就会被标记删除
消息堆积	支持	支持。考虑吞吐因素，Kafka的堆积效率比RabbitMQ总体上要高	支持
持久化	支持	支持	支持
消息追踪	支持	不支持	支持。采用Firehose或者rabbitmq_tracing插件实现，但开启rabbitmq_tracing插件会影响性能，建议只在定位问题过程中开启
消息过滤	支持	支持	不支持，但可以自行封装
多租户	支持	不支持	支持
多协议支持	兼容RocketMQ协议	只支持Kafka自定义协议	RabbitMQ基于AMQP协议实现，同时支持MQTT、STOMP等协议
跨语言支持	支持多语言的客户端	采用Scala和Java编写，支持多种语言的客户端	采用Erlang编写，支持多种语言的客户端
流量控制	不支持	支持client和user级别，通过主动设置可将流控作用于生产者或消费者	RabbitMQ的流控基于Credit-Based算法，是内部被动触发的保护机制，作用于生产者层面
消息顺序性	单队列（queue）内有序	支持单分区（partition）级别的顺序性	不支持。需要单线程发送、单线程消费并且不采用延迟队列、优先级队列等一些高级功能整体配合，才能实现消息有序
安全机制	支持SSL认证	支持SSL、SASL身份认证和读写权限控制	与Kafka相似
事务性消息	支持	支持	支持