必威体育Betway必威体育官网
当前位置:首页 > IT技术

RocketMQ联合创始人:选择MQ时,要注意的有哪些?

时间:2019-07-28 13:12:09来源:IT技术作者:seo实验室小编阅读:77次「手机版」
 

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环境搭建

在上篇《消息队列选型》中我们通过对目前比较流行的各个MQ产品的对比,结合公司具体业务需求,选择了RocketMQ做为我们的消息中间件,这篇

分享到:

栏目导航

推荐阅读

热门阅读