| -- | -- | Kafka | RocketMQ | RabbitMQ |
|---|---|---|---|---|
| 定位 | 设计定位 | 系统之间的数据流管道，实时数据处理。例如：常规消息系统、网站活动跟踪、监控数据、日志收集、处理等 | 非日志可靠消息传输。例如：订单、交易、充值、流计算、消息推送、日志流处理、binglog分发等 | 可靠的消息传输。类似于RocketMQ |
| 基本比较 | 成熟度 | 成熟 | 成熟 | 成熟 |
| -- | 社区/公司 | Apache | Alibaba，后Apache | Mozilla Public License |
| -- | 社区活跃度 | 高 | 一般 | 高 |
| -- | API完成性 | 高 | 高 | 高 |
| -- | 文档完成性 | 高 | 高 | 高 |
| -- | 开发语言 | Scala | Java | Erlang |
| -- | 支持协议 | 一套自行设计的基于TCP的二进制协议 | 自定义集(社区提供JMS--未成熟) | AMQP |
| 可用性和可靠性 | 持久化 | 磁盘文件 | 磁盘文件 | 内存、磁盘文件 |
| -- | 部署访问 | 单机、集群 | 单机、集群 | 单机、集群 |
| -- | 集群管理器 | zookeeper/kraft | name server | - |
| -- | Master节点选择策略 | 自动从ISR中选举领导者 | 不支持自动主选。通过设置brokername和brokerId实现，brokername相同，brokerid=0时为master，其他为slave | 最早加入集群的broker |
| -- | 可用性 | 非常高分布式，主从 | 非常高分布式，主从 | 高主从，镜像方式实现，数据量大时可能出现性能瓶颈 |
| -- | 主从切换方式 | 主动切换N个副本，允许N-1个故障；master失败后，自动从ISR中选择一个master | 不支持自动切换master失败，无法向master发送信息。消费者可以感知这个时间大约30s(默认)，然后从slave消费；如果master无法恢复，异步复制过程中可能丢失一些消息。 | 自动切换先加入集群的slave会成为master；因为新添加的slave没有在master之间同步数据，可能会丢失部分数据 |
| -- | 数据可靠性 | 非常好支持生产者单发、同步刷机、同步复制、异步 | 很好的producer单发，broker端支持同步刷盘，异步刷盘，同步双写，异步复制 | 好的生产者支持同步/异步确认。支持队列数据持久化，支持镜像主从同步 |
| -- | 消息写入性能 |
测试10字节：数百万条目/秒 | 测试10字节：单机机器和单个broker约7w/s，单机和3个broker约12w/s | RAM约RocketMQ的1/2，磁盘约RAM的1/3 |
| -- | 性能稳定性 |
队列/分区的性能波动明显，性能明显下降。消息累计时性能稳定 | 多队列，消息堆积时性能稳定 | 消息堆积时，性能不稳定，显著下降 |
| -- | 单台计算机支持的队列数量 | 如果一台机器有超过64个队列/分区，负载将显著增加。队列越多，负载越高，发送消息的响应时间越长 | 单机支持最多50000个队列，负载不会发生显著变化 | 取决于内存 |
| -- | 存储方式 | 非常好，消息存储在日志中，每个分区由一个或多个段日志文件组成 | 很好，所有消息都存储在同一个提交日志中 | 通常，当生产者和消费者正常时，性能时稳定的；当消费者不消费时，性能是不稳定的 |
| -- | 复制备份 | 消息首先被写入领导者的日志。追随者从领导者那里读取数据。提取数据后，将确认领导者，然后将其写入日志。维护与ISR中的领导者同步的列表。落后太多的追随者将被删除 | 同步双写异步复制：从启动线程从主服务器提取数据 | 在正常模式下无副本；在镜像模式下：消息先到达master，然后写入Slave。加入集群之前将不会复制新的从站 |
| -- | 实时消息传递 | 毫秒级别 由消费者的轮询间隔决定 | 毫秒级别 支持拉和推模式，延迟通常毫秒级 | 毫秒 |
| 功能比较 | 顺序消费 | 支持 | 支持，当顺序消费失败时，消费队列将被挂起 | 支持，但是很麻烦 |
| -- | 定时消息 | 不支持 | 开源版本仅支持定时级别 | 不支持 |
| -- | 交易消息 | 不支持 | 支持 | 不支持 |
| -- | Broker Message Filtering | 不支持 | 支持按标签过滤，类似于子主题 | 不支持 |
| -- | Message Query | 不支持 | 支持基于MessageId/MessageKey查询 | 不支持 |
| -- | 消费失败后重试 | 不支持失败的重试。偏移量存储在消费者中，无法保证。在0.8.2版本之后，支持将偏移量存储在zk中 | 支持失败重试，存储在代理中的偏移量 | 支持 |
| -- | 消息重新消费 | 通过修改偏移量支持重复消费 | 支持根据时间重新发送消息 | 支持 |
| -- | 发送方的负载均衡 | 可自由指定 | 可自由指定 | 需要单独的负载均衡器支持 |
| -- | 消费并行性 | 消费并行性与分区数一致 | 顺序消费：消费并行性和分区数相同； 无序消费：消费服务器的消费线程之和 | 可以一次抓取多个物品并一起消费。在镜像模式下，它实际上是从主服务器上消费 |
| -- | 消费模式 | pull | pull/push | push |
| -- | 批量发送 | 支持默认生产者缓存、压缩，然后批量发送 | 支持 | 不支持 |
| -- | 消息清理 | 指定文件保留时间，过期后删除 | 指定文件保留时间，过期后删除 | 消费者确认后，消息将被标记为已删除。可用内存小于40%(默认值)。触发GC时会找到两个相邻文件，并将右侧文件合并到左侧 |
| 操作和维护 | 系统维护 | Scala语言开发，维护成本高 | Java语言开发，维护成本低 | Erlang语言开发，维护成本高 |
| -- | 部署依赖关系 | zk/kraft | name server | Erlang environment |
| -- | 后台管理 | 官方网站不提供，提供第三方开源管理工具；无需重新开发 | 官方提供，消息队列rocketmq-控制台 | 官方提供Rabbitmqadmin |
| -- | 管理后台功能 | kafka web console broker队列；kafka集群主题列表，以及对应的分区、LogSize等信息；与主题对应的消费者组、偏移量、滞后等消息；生产和消费流图，消息预览kafkaOffsetMonitor；kafka集群状态；主题、消费者组列表；主题与消费者关系的图形显示等 | 集群、主题、连接、名称服务器、消息、代理、偏移、消费者 | 概述、连接、渠道、交换、队列、管理 |
| 总结 | 优势 | 1. 高吞吐量、低延迟、高可用性、集群热扩展和集群容错方面具有很好的性能。 2. 生产者提供缓存和压缩功能，以节省性能并提高效率。 3. 提供顺序消费能力 4. 提供多种客服端语言 5. 生态完备，有大量的大数据处理配套设施 | 1. 在高吞吐、低延迟和高可用性方面性能非常好；当消息堆积时性能也非常好。 2. api和系统设计更适合业务处理场景。 3. 支持多种消费方式。 4. 支持代理消息过滤。 5. 支持事务 6. 提供消息顺序消费能力；消费者可以水平扩展，有很强的消费能力。 7. 集群规模约为50台，一天处理数百亿条消息；经历了大数据量的测试，相对稳定可靠 | 1.支持多种客户端语言；支持amqp协议。 2. 由于erlang语言的特点，性能相对较好；当使用RAM模式时，性能非常好。 3. 管理界面丰富，互联网公司也有大规模的应用； |
| -- | 缺点 | 1.消费者集群的数量受分区数量限制。 2. 当一台机器上有很多主题时，性能会大大降低。 3.不支持事务 | 1.与kafka相比，用户更少，生态也不完善。消息的积累和吞吐量也较低。 2.它不支持主从自动切换。在master失败后，消费者需要一定的时间来感知它。 | 1.Erlang语言比较难。集群不支持动态扩展。 2.不支持事务，有限消息吞吐量。 3.当消息堆积时，性能将大大降低 |
MQ选型比较
©著作权归作者所有,转载或内容合作请联系作者
- 文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
- 文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
- 文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
推荐阅读更多精彩内容
- 1.摘要 本文将对Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ从17 个方面综合...
- 为什么使用MQ？MQ的优点 简答 异步处理 - 相比于传统的串行、并行方式，提高了系统吞吐量。 应用解耦 - 系统...
- 文章目录 为什么使用MQ？MQ的优点 消息队列有什么优缺点？RabbitMQ有什么优缺点？ 你们公司生产环境用的是...
- 一、前言 消息队列中间件（简称消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来...
