RocketMQ 是一个高性能、高可靠、可扩展的分布式消息中间件,它是由阿里巴巴开发并贡献给 Apache 软件基金会的一个开源项目。RocketMQ 主要用于处理大规模、高吞吐量、低延迟的消息传递,它是一个轻量级的、功能强大的消息队列系统,广泛应用于金融、电商、日志系统、数据分析等领域。
RocketMQ作为一款纯java、分布式、队列模型的开源消息中间件,支持事务消息、顺序消息、批量消息、定时消息、消息回溯等,总之就是葛大爷的一句话。
消息队列属于最经典的中间件之一,已经有 30 多年的历史,其发展历程可以总结为几个阶段:
RocketMQ 发展的主要历程:
2007年:淘宝实施了“五彩石”项目,“五彩石”用于将交易系统从单机变成分布式,也是在这个过程中产生了阿里巴巴第一代消息引擎——Notify。
2010年:阿里巴巴B2B部门基于ActiveMQ的5.1版本也开发了自己的一款消息引擎,称为Napoli,这款消息引擎在B2B里面广泛地被使用,不仅仅是在交易领域,在很多的后台异步解耦等方面也得到了广泛的应用。
2011年:业界出现了现在被很多大数据领域所推崇的Kafka消息引擎,阿里巴巴在研究了Kafka的整体机制和架构设计之后,基于Kafka的设计使用Java进行了完全重写并推出了MetaQ 1.0版本,主要是用于解决顺序消息和海量堆积的问题。
2012年:阿里巴巴开源其自研的第三代分布式消息中间件——RocketMQ。
经过几年的技术打磨,阿里称基于RocketMQ技术,目前双十一当天消息容量可达到万亿级。
2016年11月:阿里将RocketMQ捐献给Apache软件基金会,正式成为孵化项目。
阿里称会将其打造成顶级项目。这是阿里迈出的一大步,因为加入到开源软件基金会需要经过评审方的考核与观察。
坦率而言,业界还对国人的代码开源参与度仍保持着刻板印象;而Apache基金会中的342个项目中,暂时还只有Kylin、CarbonData、Eagle 、Dubbo和 RocketMQ 共计五个中国技术人主导的项目。
2017 年,RocketMQ 成功通过了 Apache Incubator 的评审,正式成为 Apache 顶级项目(Top-Level Project, TLP) 。这个标志性事件不仅提升了 RocketMQ 在全球开源社区的影响力,也使其获得了更多来自外部社区的支持和贡献。
2017年2月20日:RocketMQ正式发布4.0版本,专家称新版本适用于电商领域,金融领域,大数据领域,兼有物联网领域的编程模型。
2023 年,RocketMQ 发布了 5.x 版本,继续强化其在云原生、容器化环境中的应用,并且在微服务架构中发挥了重要作用。此版本在性能、可扩展性和稳定性方面进行了进一步优化,增强了在异构环境下的跨平台兼容性,并扩展了更多高级特性,如 精准消息投递、更加细粒度的消息过滤 等。
以上就是RocketMQ的整体发展历史,其实在阿里巴巴内部围绕着RocketMQ内核打造了三款产品,分别是MetaQ、Notify和Aliware MQ。
这三者分别采用了不同的模型,MetaQ主要使用了拉模型,解决了顺序消息和海量堆积问题;Notify主要使用了推模型,解决了事务消息;而云产品Aliware MQ则是提供了商业化的版本。
特性 | RocketMQ | Kafka | RabbitMQ | ActiveMQ | NATS |
---|---|---|---|---|---|
开发背景 | 阿里巴巴开发,2010 年开源,现为 Apache 顶级项目 | LinkedIn 开发,2011 年开源,现为 Apache 顶级项目 | Pivotal(现 VMware)开发,开源项目 | Apache 软件基金会开发,支持多协议的消息队列 | 开源项目,初衷为轻量级实时消息传递 |
消息协议 | 自定义协议,兼容 MQTT、OpenMessaging 等 | 自定义协议(Kafka 协议) | 支持 AMQP、STOMP、MQTT 等多种协议 | 支持 AMQP、OpenWire、MQTT 等多种协议 | NATS 协议,专注于简单的 Pub/Sub 模型 |
性能与吞吐量 | 高吞吐量,低延迟,适用于高并发场景 | 主要侧重吞吐量,适用于大数据流处理 | 吞吐量较低,适用于中小型企业 | 吞吐量较低,适合中小型企业应用 | 极低的延迟和极高的吞吐量,专注于实时性 |
消息模型 | 支持点对点(P2P)和发布/订阅(Pub/Sub)模式 | 主要是发布/订阅(Pub/Sub)模型 | 支持点对点(P2P)和发布/订阅(Pub/Sub)模型 | 支持点对点(P2P)和发布/订阅(Pub/Sub)模型 | 支持 Pub/Sub 模型 |
消息存储 | 顺序写入,支持高效的消息持久化 | 顺序写入,按日志存储,支持高效的消息持久化 | 使用内存/磁盘存储,支持消息持久化 | 使用内存/磁盘存储,支持消息持久化 | 存储较为简单,不强调持久化 |
扩展性 | 支持分布式部署,高可用,支持水平扩展 | 高扩展性,支持分布式部署和多副本机制 | 集群模式,但扩展性不如 RocketMQ 和 Kafka | 支持集群模式,扩展性相对较差 | 高扩展性,适用于大规模水平扩展 |
高可用性 | 支持主从复制,集群模式,容错性高 | 多副本机制,较强的容错性 | 支持镜像队列和集群模式,容错性较好 | 支持主从复制和集群模式,容错性一般 | 支持集群模式和多节点部署,容错性较好 |
事务消息 | 原生支持事务消息和分布式事务 | 不支持原生事务消息,需自行实现 | 支持事务消息,但性能不如 RocketMQ | 支持事务消息,但一致性和性能较差 | 不支持事务消息 |
顺序消息 | 支持严格顺序消费,适合高并发场景 | 支持分区内的顺序消费,但需要手动控制分区的数量和分布 | 支持顺序消费,但通常不如 RocketMQ 强大 | 支持顺序消费,但不如 RocketMQ 强大 | 不强调顺序消息处理 |
延迟 | 在高并发场景下延迟较低,适用于实时消息传递 | 吞吐量优先,延迟相对较高 | 在高负载时延迟较高 | 延迟较高,尤其在负载较重时 | 延迟极低,适用于实时性要求较高的场景 |
适用场景 | 高吞吐量、大规模分布式系统、事务消息、顺序消息等场景 | 日志聚合、流数据处理、大数据平台 | 企业消息传递、支持 AMQP 协议的系统 | 中小规模企业消息传递、企业级应用 | 实时数据流、IoT、微服务架构等高性能、低延迟场景 |
社区与生态 | Apache 社区支持,活跃且发展迅速 | Apache 社区支持,社区活跃 | 社区活跃,广泛应用于企业级应用 | Apache 社区支持,但活跃度和扩展性相对较弱 | 开源社区活跃,适用于微服务和高并发场景 |
总结:
以下是一些典型的 RocketMQ 应用场景:
随着微服务架构的流行,服务之间的关系梳理非常重要。异步解耦可以降低服务之间的耦合程度,同时也能提高服务的吞吐量。
使用异步解耦的业务场景非常多,因为每个行业的业务都会不太一样,以一些比较通用的业务来说明相信大家都能理解。
比如电商行业的下单业务场景,以最简单的下单流程来说,下单流程如下:
我们以下单成功后,用户进行支付,支付完成会有个逻辑叫支付回调,在回调里面需要去做一些业务逻辑。首先来看下同步处理需要花费的时间,如下图:
同步流程
上面的下单流程从 3 到 5 都是可以采用异步流程进行处理,对于用户来说,支付完成后他就不需要关注后面的流程了。后台慢慢处理就行了,这样就能简化三个步骤,提高回调的处理时间。
异步流程
削峰填谷指的是在大流量的冲击下,利用 RocketMQ 可以抗住瞬时的大流量,保护系统的稳定性,提升用户体验。
在电商行业,最常见的流量冲击就是秒杀活动了,利用 RocketMQ 来实现一个完整的秒杀业务还是与很多需要做的工作,不在本文的范围内,后面有机会可以单独跟大家聊聊。想告诉大家的是像诸如此类的场景可以利用 RocketMQ 来扛住高并发,前提是业务场景支持异步处理。
削峰填谷
众所周知,分布式事务有 2PC,TCC,最终一致性等方案。其中使用消息队列来做最终一致性方案是比较常用的。
在电商的业务场景中,交易相关的核心业务一定要确保数据的一致性。通过引入消息队列 RocketMQ 版的分布式事务,既可以实现系统之间的解耦,又可以保证最终的数据一致性。
数据分发指的是可以将原始数据分发到多个需要使用这份数据的系统中,实现数据异构的需求。最常见的有将数据分发到 ES, Redis 中为业务提供搜索,缓存等服务。
除了手动通过消息机制进行数据分发,还可以订阅 Mysql 的 binlog 来分发,在分发这个场景,需要使用 RocketMQ 的顺序消息来保证数据的一致性。
数据分发
RocketMQ 的架构主要包括以下几个核心组件:
通过本文的介绍,我们可以看到 RocketMQ 作为一款高效的分布式消息中间件,无论你是正在考虑在项目中引入 RocketMQ,还是已经在使用它的开发者,掌握 RocketMQ 的核心特性和最佳实践对于提升系统的可靠性和性能至关重要。后续将分享RocketMQ的部署,及开发使用流程。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。