为什么选择RocketMQ

消息队列 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，请先仔细阅读官方文档。