引言
分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,目前对Kafka、RabbitMQ、RocketMQ这三个消息中间件做下对比分析。
- | - | kafka | RocketMQ | RabbitMQ | 数据来源 | 相关文章 |
定位 | 设计定位 | 系统间的数据流管道,实时数据处理。 例如:常规的消息系统、网站活性跟踪,监控数据,日志收集、处理等 |
非日志的可靠消息传输。 例如:订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等 |
可靠消息传输。和RocketMQ类似。 | ||
基础对比 | 成熟度 | 日志领域成熟 | 成熟 | 成熟 | ||
所属社区/公司 | Apache | Alibaba开发,已加入到Apache下 | Mozilla Public License | |||
社区活跃度 | 高 | 中 | 高 | 来源于网络 | ||
API完备性 | 高 | 高 | 高 | |||
文档完备性 | 高 | 高 | 高 | 来源于网络 | ||
开发语言 | Scala | Java | Erlang | |||
支持协议 | 一套自行设计的基于TCP的二进制协议 | 自己定义的一套 (社区提供JMS--不成熟) |
AMQP | |||
客户端语言 | C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP等 | Java | Java、C、 C++、 Python、 PHP、Perl 等 | |||
持久化方式 | 磁盘文件 | 磁盘文件 | 内存、文件 | |||
可用性、可靠性比较 | 部署方式 | 单机/集群 | 单机/集群 | 单机/集群 | ||
集群管理 | zookeeper | name server | ||||
选主方式 | 从ISR中自动选举一个leader | 不支持自动选主。通过设定brokername、brokerId实现,brokername相同,brokerid=0时为maser,其他为slave | 最早加入集群的broker | |||
可用性 | 非常高 分布式、主从 |
非常高 分布式、主从 |
高 主从,采用镜像模式实现,数据量大时可能产生性能瓶颈 |
rabbitMQ集群部署 http://www.cnblogs.com/knowledgesea/p/6535766.html RabbitMQ可用性、可靠性分析 http://blog.csdn.net/cadem/article/details/53422912?utm_source=itdadao&utm_medium=referral |
||
主从切换 | 自动切换 N个副本,允许N-1个失效;master失效以后自动从isr中选择一个主; |
不支持自动切换 master失效以后不能向master发送信息,consumer大概30s(默认)可以感知此事件,此后从slave消费;如果master无法恢复,异步复制时可能出现部分信息丢失 |
自动切换 最早加入集群的slave会成为master;因为新加入的slave不同步master之前的数据,所以可能会出现部分数据丢失 |
|||
数据可靠性 | 很好 支持producer单条发送、同步刷盘、同步复制、异步。 |
很好 producer单条发送,broker端支持同步刷盘、异步刷盘,同步双写,异步复制。 |
好 producer支持同步/异步ack。支持队列数据持久化,镜像模式中支持主从同步 |
kafka也同步刷盘,但是效率较低 http://jm.taobao.org/2016/04/28/kafka-vs-rocktemq-4/ |
||
消息写入性能 | 非常好 每条10个字节测试:百万条/s |
很好 每条10个字节测试:单机单broker约7w/s,单机3个broker约12w/s |
RAM约为RocketMQ的1/2, Disk的性能约为RAM性能的1/3 |
数据来源于网络 单条消息的数据量越小,性能对比时kafka表现越好 |
kafka vs RocktMQ: https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines kafka vs RocktMQ VS RabbitMQ http://www.cnblogs.com/felixzh/p/6198070.html http://ju.outofmemory.cn/entry/177937 |
|
性能的稳定性 | 队列/分区多时性能不稳定,明显下降。 消息堆积时性能稳定 |
队列较多、消息堆积时性能稳定 | 消息堆积时,性能不稳定、明显下降 | |||
单机支持的队列数 | 单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长 | 单机支持最高5万个队列,Load不会发生明显变化 | 依赖于内存 | 数据来源于网络测评 kafka新能降低是因为topic增多时,顺序写变成了随机写 |
Kafka vs RocketMQ: Topic数量对单机性能的影响 http://jm.taobao.org/2016/04/07/kafka-vs-rocketmq-topic-amout/?utm_source=tuicool&utm_medium=referral |
|
堆积能力 | 非常好 消息存储在log中,每个分区由一个或多个segment log文件 |
非常好 所有消息存储在同一个commit log中 |
一般 生产者、消费者正常时,性能表现稳定;消费者不消费时,性能不稳定 |
http://www.cnblogs.com/purpleraintear/p/6033136.html | ||
复制备份 | 消息先写入leader的log,followers从leader中pull数据,pull到数据以后先ack leader,然后写入log中。 ISR中维护与leader同步的列表,落后太多的follwer会被删除掉 |
同步双写 异步复制:slave启动线程从master中拉数据 |
普通模式下不复制; 镜像模式下:消息先到mster,然后写到slave上。加入集群之前的消息不会被复制到新的slave上。 |
|||
消息投递实时性 | 毫秒级 具体由consumer轮询间隔时间决定 |
毫秒级 支持pull、push两种模式,延时通常在毫秒级 |
毫秒级 | |||
功能对比 | 顺序消费 | 支持顺序消费 但是一台Broker宕机后,就会产生消息乱序(来自网上,尚未找到原因) |
支持顺序消费 在顺序消息场景下,消费失败时消费队列将会暂停 |
支持顺序消费 | ||
定时消息 | 不支持 | 开源版本仅支持定时Level | 不支持 | |||
事务消息 | 不支持 | 支持 | 不支持 | |||
Broker端消息过滤 | 不支持 | 支持 通过tag过滤,类似于子topic |
不支持 | |||
消息查询 | 不支持 | 支持 根据MessageId查询 支持根据MessageKey查询消息 |
不支持 | |||
消费失败重试 | 不支持失败重试 offset存储在consumer中,无法保证。 0.8.2版本后支持将offset存储在zk中 |
支持失败重试 offset存储在broker中 |
支持失败重试 | |||
消息重新消费 | 支持通过修改offset来重新消费 | 支持按照时间来重新消息 |
首页 上一页 1 2 下一页 尾页 1/2/2 | |
【大 中 小】【打印】 【繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部】 | |
上一篇:如何理解低耦合AND高内聚?[转] | 下一篇:为你揭秘小程序音视频背后的故事... |