rocketmq
rocketmq 是一个来自阿里巴巴的分布式消息中间件，于 2012 年开源，并在 2017 年正式成为 Apache 顶级项目。据了解，包括阿里云上的消息产品以及收购的子公司在内，阿里集团的消息产品全线都运行在 RocketMQ 之上，并且最近几年的双十一大促中，RocketMQ 都有抢眼表现。
谈起消息系统中间件，就开源项目而言，用户的选择其实很多，包括 activemq、ZeroMQ、Kafka 等。那到底 RocketMQ 又有什么优势？未来它的演进方向会是怎么样？去年由 RocketMQ 牵头推出的全球消息领域标准 OpenMessaging 进展又如何？带着这些问题，InfoQ 记者采访了 RocketMQ 联合创始人冯嘉。
另外，在 4 月 20 日举办的 QCon 全球软件开发大会上，冯嘉也将会独家揭秘 RocketMQ 消息引擎背后的设计奥秘，感兴趣的同学可以点击阅读原文了解详情。
InfoQ：之前 InfoQ 记者其实也有采访过 RocketMQ 好几次 [0]，我们也有聊到阿里巴巴消息系统的演进历史。不过我觉得之前那篇没有讲得特别清楚，不知道还可不可以再谈谈你们消息系统的演进情况？
冯嘉：在阿里巴巴技术发展初期，伴随着淘宝业务的快速发展，网站流量呈现几何级增长。单体巨无霸式的应用无法跟上快速迭代的研发要求，上百工程师每天对着同一套系统，代码不断的迁入迁出，发布、交付成本也非常之高。
这个时候，公司内部从业务、组织层面进行了一次大的水平与垂直切分，拆分出用户中心，商品中心，交易中心，评价中心等平台型应用，分布式电商系统的雏形由此诞生。
阿里第一代消息引擎 Notify 就是在这样的背景下设计出来的，主要解决的核心问题是交易下单链路的异步解耦。当然，这背后，需要我们严肃考虑分布式系统的可扩展性，比方说它的服务发现节点，存储节点，broker 节点都是支持水平扩展，面对淘宝高峰流量，比较好地起到了削峰填谷的作用。
放眼全球，当时业界的消息引擎，如 Apache ActiveMQ 以及其它 AMQP 实现，在后端有超大规模消费者，尤其是各消费能力不均衡的前提下，经常会出现堆积，这种影响被传递到上游生产者，进而影响交易核心业务，系统卡顿，宕机现象不在少数。如何能够更好的削峰填谷，这也是 Notify 最早面临的难题之一。
再后来，随着 2011 年 Kafka 从 Apache 顶级项目毕业，其自研存储引擎带来的海量消息堆积，高效的持久化特性走入我们的视野。但它特殊的日志通道定位，是不能完全满足阿里巴巴高频的在线交易场景，为此团队设计并研发了新一代消息引擎 RocketMQ（内部叫 MetaQ），从最初的日志传输领域到后来阿里集团全维度在线业务的支撑，RocketMQ 被广泛用在交易，数据同步，缓存同步，IM 通讯，流计算，IoT 等场景。
关于这些 Use Case，我们在 OpenMessaging 项目里有个简单总结，大家可以参考这里 [1]。
InfoQ：谈谈 2017 年双十一中，RocketMQ 的一些数据情况？现在阿里就只有用 RocketMQ 吗？目前开源出去了，内部和外部的版本是一一对应的吗？未来怎么打算呢？
冯嘉：目前，包括阿里云上的消息产品以及收购的子公司在内，阿里集团的消息产品全线跑在 RocketMQ 4 的内核上面。今年会全面拥抱 OpenMessaging 的第一个标准实现 RocketMQ 5.0，这其中也包括我们为千万中小企业定制的商业化版本的 RocketMQ - Aliware MQ（ONS）。所有消息产品都围绕着 RocketMQ 唯一内核打造，一个版本，丰富的可插拨组件，这个思路是团队一直坚持的，而且会持续走下去。
说起数据表现，RocketMQ 在 2017 年双十一当天的万亿级数据洪峰下，做到了 99.996% 的毫秒级响应，每秒支撑千万级消息发布，每条消息发布平均响应时间不超过 3 毫秒，最大不超过 20 毫秒，而核心交易链路平均 response Time 仅 3ms，在全球 Messaging 领域做到了领先水平。
随着我们在 OpenMessaging 标准里的 benchmark[2] 项目陆续发布，开源消息领域的主流产品都会被拿来评测，我们希望它能成为这个领域的基准平台，既有对 OpenMessaging Features 支持程度的评价，又有在不同 Workload 下的性能评估，还能像据库领域的 DB-Engines 一样，对全球消息产品有个 Ranking。
InfoQ：从你的经验，来谈谈在消息中间件选型时，大家应该注意些什么？需要从哪几个维度考虑？
冯嘉：全球主流的开源分布式消息引擎，除了 RabbitMQ，基本上都在 Apache 上了。Apache ActiveMQ 以及旗下的各个子项目，主要面向企业级市场，吞吐不是其强项，主要和企业已有基础设施集成起来比较方便，如 Eai，ESB 这种早期企业基础架构。
Apache Kafka 为日志处理而生，目前从社区来看，发力重点在流计算，IoT 等领域，和 Apache Spark Streaming，Apache Flink，Apache Storm 等一站式流计算平台不同，它从 Apache Samza 这种轻量级方案汲取了养分，提供给用户的是一个异步编程框架，用户基于类库编程，不需要考虑分发，部署，调度等一系列传统流计算框架带来的繁琐工作。这种轻量级的解决方案在一些日志处理，ETL 等场景更受大家欢迎。
如果是应对一些高并发，高可靠以及高可用比较苛刻的场景，Apache RocketMQ 是一个不错的选择。最近留意到一个有趣的现象，国内一些中大型规模的公司普遍部署了两套消息引擎，一套选择 Apache RocketMQ 用在交易，数据分发等核心链路上，一套选择 Apache Kafka 用在大数据等在线、离线分析链路上。毫无疑问，Kafka 目前在大数据生态建设这块，确实具备一定的先发优势。
RocketMQ 作为承载了阿里巴巴双十一万亿级数据体量的消息引擎，在电商，金融领域的优势也是比较明显的。目前，国内很多金融领域的领军企业在构建自己的分布式金融体系时，也都不约而同地选择了 RocketMQ。
另外，自从 RocketMQ 进入 Apache 基金会后，团队大力发展社区生态，包括和 Apache Spark，Apache Flink，Apache Storm，Apache Ignite 等顶级开源产品有了更多的生态连接与整合能力。未来一两年，我们也希望 RocketMQ 能在大数据，流计算领域取得更多的创新突破。
InfoQ：我看到社区里做的几个性能对比，发现其实 RocketMQ 都不是性能最高的，那你认为和其他几个选项对比（Kafka、RabbitMQ、ZeroMQ），RocketMQ 最大的优点是什么？
冯嘉：哈哈，大家看到的数据可能比较老了。开个玩笑，其实不光在阿里，在 Google 一样，软件产品都以满足核心场景为最高优先级。就像这里提到的，社区里对比各种消息引擎，我大致看下来，大家主要关心的还是吞吐（延迟这个指标，大家关心的较少，对于在线业务，Latency 影响还是蛮大的）这个指标。
ZeroMQ 不是一个 MQ，所以这里不提了。Kafka 为大数据吞吐为王的日志处理而生，早先在 BATch 模式下，具有碾压其它同类产品的品质。这两年，在满足了阿里集团核心消息诉求后，我们先后两次对 RocketMQ 进行了革命式优化，前年主要做了双十一交易链路的长尾慢请求优化，在延迟方面已经超越 Kafka。具体的数据可以参考这篇文章 [3]。
吞吐方面，在小包非批量以及大量分区的场景下（现实应用更广泛的场景），RocketMQ 更能充分利用磁盘的 IO 能力达到更高的 TPS（领先 Kafka 一倍左右）。在大包和批量的场景下，RocketMQ 和 Kafka 目前已经相差无几，此时的瓶颈已经转移到磁盘的吞吐能力上。
为了能够更客观地反映全球消息领域的各家产品的性能，帮助大家更好的选型，在 OpenMessaging 的 Benchmark 子项目里，我们专门设计了全维度的 Workload 基准测试，所有产品拉到同一个基准平台，同一套负载下，性能孰优孰劣，高下立判。今年晚些时候，我们也会在国际 InfoQ 上公布我们的数据以及优化经验，欢迎大家来亲测。
InfoQ：你怎么看 Kafka？
冯嘉：Apache Kafka 是一款优秀的开源产品，这一点毋庸置疑，对于同行卓越的努力我们需要心怀敬畏。Kafka 利用端到端的 Batch、压缩等优秀设计，在同类产品吞吐特性上表现卓越，这种设计也极大地提高了资源利用率。在此基础上，Kafka 充分发展技术生态，占据了在大数据与流处理领域的先发优势。
相比而言，RocketMQ 在低延迟，消息重试与追踪，海量 topic，多租户，一致性多副本，数据可靠性等问题上进行了大量优化，对电商，金融领域的用户来说，是一大利好。
InfoQ：OpenMessaging 是由阿里巴巴发起的与厂商无关、平台无关的分布式消息及流处理领域的应用开发标准，目前我理解是想统一目前这些消息中间件的客户端标准，以简化用户的学习成本。现在 OpenMessaging 也已经正式入驻 linux 基金会，目前进展如何？我理解他的成本需要其他一些消息框架也加入进来？不知道在这块其他几家怎么看？
冯嘉：OpenMessaging 自去年 10 月进入 Linux 基金会以来，受到了全球同行的广泛关注。很多分布式领域的专家在 Issue 上，邮件列表里和我们进行了激烈探讨，整个模型也是在不断的打磨，优化。
目前除了初创的成员，我们还在考虑吸纳来自全球其它互联网，金融领域的大咖企业，启动一个类似 Linux 基金会的 Funding Program，欢迎国内有自主消息引擎的厂商加入我们，也非常欢迎积极拥抱标准化战略的同行企业加入进来，共同打造消息领域的事实标准。整个标准的第一个正式版本（非 Alpha 版本），初步计划在今年 4 月份发布，而阿里云 MQ 会成为 OpenMessaging 全球第一个云厂商标准实现，并于今年晚些时候发布。
OpenMessaging 在我们初步蹦出这个想法的时候，就跟 Apache 社区包括 RabbitMQ 团队的同行们聊过，大家反响普遍还是很热烈的。毕竟这块业界还是个空缺，在 java 生态里，JMS 2.1 在 Java EE 体系里被推迟了又推迟，Spring 社区也忍不住自己设计了一套类似的编程框架。但放眼多语言领域这块就显得贫瘠了。
业界迫切需要一套类似数据库领域的 sql 这样的编程标准，而在整个标准的演进过程中，像 Apache ActiveMQ， Apache Pulsar，包括 Apache RocketMQ 社区都给出了很多积极的回应。在第一个标准版本实现中，大家也会看到其它几家顶级开源消息引擎的 OpenMessaging 实现。
除此之外，在 Spring Cloud，AMQP，MQTT，Serverless 等领域，OpenMessaging 也会寻求积极探索与合作。准确一点讲，OpenMessaging 已经不是一个传统意义上的 API 标准，它更像是一个生态，一个围绕着 Messaging 运转的全域开源生态。
InfoQ：RocketMQ 5.0 有什么重磅的特性会发布？你在 QCon 上着重和大家分享哪些观点？
冯嘉：对了，和大家再预告下，阿里巴巴第 4 届中间件性能挑战大赛 4 月份就要和大家见面了。今年围绕着 RocketMQ 5.0，我们设计了一道跟 RocketMQ 存储引擎相关的题目，欢迎大家报名参赛。说到 RocketMQ 5.0，整体定位依旧是高吞吐，低延迟，任意堆积并且是 Cloud Native。关于这些特性，我会在接下来的北京 QCon 上和大家分享，非常期待和大家的现场交流，也希望大家继续关注 RocketMQ，关注 OpenMessaging。
相关阅读
在上篇《消息队列选型》中我们通过对目前比较流行的各个ＭＱ产品的对比，结合公司具体业务需求，选择了RocketMQ做为我们的消息中间件，这篇