消息队列 RocketMQ 是阿里巴巴集团自主研发的专业消息中间件。 产品基于高可用分布式集群技术,提供消息订阅和发布、消息轨迹查询、定时(延时)消息、资源统计、监控报警等一系列消息云服务,是企业级互联网架构的核心产品。
对比下其他MQ
图片来源 RocketMQ官网
RabbitMQ:是用 Erlang 语言编写的,并发能力很强,性能极其好,延时很低,吞吐量相对较小,关键是 erlang 语言不懂。
ActiveMQ:主要面向企业级市场,吞吐不是其强项,主要和企业已有基础设施集成起来比较方便,如 EAI,ESB 这种早期企业基础架构。
重点比较 Kafka 和 RocketMQ,参考 RocketMQ与kafka对比(18项差异)
差异项 | Kafka | RocketMQ |
数据可靠性 | 异步刷盘,异步复制/同步复制 | 异步实时刷盘,同步刷盘,异步复制/同步复制 |
性能对比 | 单机写入TPS约在百万条/秒,消息大小10个字节(Producer端将多个小消息合并,批量发向Broker) | 单机写入TPS单实例约7万条/秒,单机部署3个Broker,可以跑到最高12万条/秒,消息大小10个字节 |
单机支持的队列数 | 单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长 | 单机支持最高5万个队列,负载不会发生明显变化 |
消息投递实时性 | 使用短轮询方式,实时性取决于轮询间隔时间,0.8以后版本支持长轮询 | 使用长轮询,同Push方式实时性一致,消息的投递延时通常在几个毫秒 |
失败重试 | 不支持 | 支持定时重试,每次重试间隔时间顺延 |
严格的消息顺序 | 支持消息顺序,但是一台代理宕机后,就会产生消息乱序 | 支持严格的消息顺序,在顺序消息场景下,一台Broker宕机后,发送消息会失败,但是不会乱序 |
定时消息 | 不支持 | 仅支持定时级别 |
分布式事务消息 | 不支持 | 支持 |
消息查询 | 不支持 | 支持根据消息标识查询消息 |
消息回溯 | 按照偏移来回溯消息 | 支持按照时间来回溯消息,精度毫秒,例如从一天之前的某时某分某秒开始重新消费消息 |
消费并行度 | 消费并行度依赖Topic配置的分区数,如分区数为10,那么最多10台机器来并行消费 | 顺序消费方式并行度同 Kafka 完全一致,乱序方式并行度取决于Consumer的线程数,如Topic配置10个队列,10台机器消费,每台机器100个线程,那么并行度为1000 |
消息轨迹 | 不支持 | 支持 |
开发语言 | Scala | Java |
消息过滤 | 不支持代理端的消息过滤 | 支持,表达式过滤和类过滤 |
消息堆积能力 | 强 | 稍弱 |
rocketmq4.5.0 支持分布式事物,消息控制台,系统告警,容灾切换。
RocketMQ:功能齐全,在低延迟,消息重试与追踪,海量 Topic,多租户,一致性多副本,数据可靠性等问题上进行了大量优化,社区活跃度相对 Kafka 较低,适用于基础架构研发实力较强的公司。广泛用在交易,数据同步,缓存同步,IM 通讯,流计算,IoT 等场景。
Kafka:事实性规范,为日志处理而生,自研存储引擎支持海量消息堆积,高效的持久化特性,特殊的日志通道定位,但不能完全满足高频的在线交易场景。Kafka 利用端到端的 Batch、压缩等优秀设计,在同类产品吞吐特性上表现卓越,这种设计也极大地提高了资源利用率。充分发展技术生态,发力重点在流计算,IoT 等领域。
国内一些中大型规模的公司普遍部署了两套消息引擎,一套选择 Apache RocketMQ 用在交易,数据分发等核心链路上,一套选择 Apache Kafka 用在大数据等在线、离线分析链路上。毫无疑问,Kafka 目前在大数据生态建设这块,确实具备一定的先发优势。
RocketMQ 的缺点
- 不能避免消息重复消费。
- 消费线程池自定义支持,开源 RocketMQ 消费端仅有一个消费线程池,多个 topic 的消费会互相影响。另外同一个消费端仅有一个 listener,如果是多个 topic,需要上层业务分发。
本系列源码分析版本 rocketmq4.5.0
为更好的了解 RocketMQ,请先仔细阅读官方文档。