开局先送官方福利!!!
1.免费领资源,好礼拿不停!
首先是猫超卡和社区积分,点点鼠标即可到手(2分钟不到,福利直接拿到手!):
👉👉👉领奖活动直达电梯👈👈👈
👉👉👉领奖活动直达电梯👈👈
2.是兄弟,就来助我!
助力最高拿科沃斯T10扫地机器人:
👉👉👉直达领取扫地机器人👈👈👈
👉👉👉直达领取扫地机器人👈👈👈
视频演示讲解
👉👉👉视频讲解直达!已更新👈👈👈
👉👉👉视频讲解直达!已更新👈👈👈
👉👉👉视频讲解直达!已更新👈👈👈
切入正题
那么什么是消息队列呢?
消息队列(Message Queue),从广义上来讲就是一种消息队列服务中间件,提供一套完善的信息生产、传递、消费的软件系统。如下图
当然,消息队列所涵盖的功能远不止于队列(Queue),其本质是两个进程传递信息的一种方法。两个进程可以分布在同一个或多个不同的机器上。
说了一点理论,大家应该没有明白,那么请大家想象一下12306的业务处理流程,大家都明白12306的业务逻辑非常复杂,需要考虑的方面太多了,下面一张图为12306的部分业务逻辑
像12306这类软件超高并发需求的场景还有很多,那么如何解决呢?就是使用消息队列
消息队列的优点如下:
说到这里,我讲的不如大家实际去看一看由李伟老师编写的《RocketMQ分布式消息中间件》
市面上常见的消息队列
从上面这张图可以很清晰的看到,截至2020年的时候,市面上主流的消息队列组件的对比,Apache RocketMQ在各项功能上来看,妥妥的六边形战士,非常值得一试。
RocketMQ的发展历程
经过上面的简单介绍,大家应该对消息队列有了大致的了解,那么这里咱们介绍一下RocketMQ的发展历程。
RocketMQ前世---MetaQ
RocketMQ发展经历了几个阶段,一开始的时候,和大部分组件产生的原因类似,阿里巴巴内部为了适应淘宝 B2C 的更快、更复杂的业务,2001年启动了“五彩石项目”,阿里巴巴的第一代消息队列服务Notify就是在这个背景下产生的。
2010 年,阿里巴巴内部的 Apache ActiveMQ 仍然作为核心技术被广泛用于各个业务线,而顺序消息、海量消息堆积、完全自主控制消息队列服务,也是阿里巴巴同时期急需的。在这种背景下,2011年,MetaQ诞生。
RocketMQ 云
2011年,LinkedIn将Kafka开源。2012年,阿里巴巴参考Kafka的设计,基于对MetaQ的理解和实际使用,研发了一套通用消息队列引擎,也就是 RocketMQ。自此才有了第一代真正的RocketMQ,2016年阿里云上线云RocketMQ消息队列服务。
自2001年到2012年,11年的实际使用、运维,和业务不断碰撞,才得以抽象并整理出一个真正的行业级产品,技术从来不简单,只是你看不见!
Apache RocketMQ“毕业”
2016年11月,阿里巴巴将RocketMQ捐献给Apache基金会。
Apache社区有一个很重要的理念:社区大于代码。虽然RocketMQ已经开源3年,在国内小有名气,而且在阿里巴巴被广泛应用并有较好的效果,但是依然不能达到 Apache优秀项目的标准。
在RocketMQ被捐献后,通过一系列的修改、评审、调整,悄悄升级至4.0版本,正式进入孵化阶段。
2017年09月25日,RocketMQ成功“毕业”(Apache社区项目孵化成功即为毕业),成为 Apache 顶级项目,它是国内首个互联网中间件在 Apache 的顶级项目,也是继ActiveMQ、Kafka后Apache家族中全新的一代消息队列引擎。
随着不断地更新升级,RocketMQ 的能力也越来越强大,如图所示,这是阿里巴巴双11的消息量的部分统计,可以看出RocketMQ处理的消息量已经在万亿条级别。
RocketMQ经过多年的发展和实践应用,在自身的到现在阿里云存在两大版本可供使用,一个是RocketMQ 4.x,另一个是RocketMQ 5.x,其版本差异如下
差异项 |
4.x |
5.x |
服务端架构 |
存算一体。 |
存储和计算分离,可独立水平扩展。 |
开发接入门槛 |
1. 同时存在多套SDK,功能接口体验不一致。 |
1. 统一使用开源SDK,功能体验一致。 |
存储能力 |
按空间预留,需要做好容量评估避免存储时长不足。 |
根据实际使用量弹性伸缩。 |
计算能力 |
超过TPS规格最大值限流。 |
消息收发计算能力支持预留+突发流量弹性组合,业务方无需为突发流量预留大量Buffer资源。 |
计费项 |
1. 标准版实例:API调用费用、Topic资源占用费。 |
1. 消息收发TPS计算规格 |
售卖形态 |
标准版、铂金版 |
1. 主系列: |
实践出真知
那么经过前面的一系列讲述,大家应该对RocketMQ有了一些认知,并且也了解了产品特性,那么接下来就到了我们的动手实验环节了。在这里为大家演示的是RocketMQ事件驱动场景,所有服务均在阿里云上进行,让大家完整体验阿里云上的业务流程。
为何选择事件驱动场景?
2023年以来,阿里云社区先后推出了多个服务测评活动,其中有函数计算FC,以及不久前的事件桥EventBridge测评活动,直到现在正在测评的RocketMQ消息队列,完美支撑了该业务场景,可谓是温故而知新,将多个服务融合到同一个业务场景中
场景描述
假设有一家小型游戏公司,需要通过使用RocketMQ来收发消息,然后通过阿里云函数计算FC处理后将数据进行存储
业务逻辑图示
业务实现
RocketMQ设置
创建RocketMQ实例
作为演示,本次使用的单节点的标准版RocketMQ实例,规格为rmq.s1.micro,如果您是第一次使用RocketMQ并且是通过活动页面进入,那么您可以领取一个月的免费使用额度。实例的创建大概需要5分钟左右,请您耐心等待,可以向下继续阅读。
创建订阅及Group
创建Group(可选)
表格存储
创建表格存储实例
创建数据表
函数计算FC
设置函数计算FC的环境变量
使用代码
importosfromtablestoreimport*importjsondefhandler(event, context): body=json.loads(event.decode())['data']['body'] # 从环境变量中获取表格存储的连接信息endpoint=os.environ.get('OTS_ENDPOINT', '') accessid=os.environ.get('OTS_ACCESSID', '') accesskey=os.environ.get('OTS_ACCESSKEY', '') instance=os.environ.get('OTS_INSTANCE', '') table_name=os.environ.get('OTS_TABLE_NAME', '') # 创建表格存储客户端client=OTSClient(endpoint, accessid, accesskey, instance) # 定义要写入的数据primary_key= [('id', body['id'])] attribute_columns= [('Name', body['name']), ('Job', body['job']), ('Hero', body['hero'])] row=Row(primary_key, attribute_columns) # 向表格存储写入数据consumed, return_row=client.put_row(table_name, row) return'Data written to Table Store successfully.'
事件总线EventBridge
事件总线EventBridge需要创建自定义的事件总线
步骤一:添加自定义事件源
- 登录事件总线EventBridge控制台。
- 在左侧导航栏,单击事件总线。
- 在顶部菜单栏,选择地域。
- 在事件总线页面,单击已创建的自定义事件总线。
- 在左侧导航栏,单击事件源。
- 在事件源页面,单击添加事件源。
- 在添加自定义事件源面板,输入名称和描述,事件提供方选择消息队列 RocketMQ 版,并选择已创建的消息队列RocketMQ版的资源信息等,然后单击确定。
步骤二:创建事件规则
- 登录事件总线EventBridge控制台,在左侧导航栏,单击事件总线。
- 在顶部菜单栏,选择地域,在事件总线页面,单击目标总线名称。
- 在左侧导航栏,单击事件规则,然后单击创建规则。
- 在创建规则页面,完成以下操作。
- 在配置基本信息配置向导,在名称文本框输入规则名称,在描述文本框输入规则的描述,然后单击下一步。
- 在配置事件模式配置向导,事件源类型选择自定义事件源,事件源选择步骤一添加的自定义事件源,在事件模式内容代码框输入事件模式,然后单击下一步。
a. 在配置事件目标配置向导,配置事件目标,然后单击创建。
b. 服务类型:单击函数计算。
c. 服务:选择已创建的函数计算的服务。
d. 函数:选择已创建的函数计算的函数。
步骤三:设置规则
测试
写在最后
通过本篇的一些简述以及一个小的实验,希望您可以对阿里云RocketMQ消息队列有一个大致的了解,同时也可以看到阿里云各个服务之间的集成协作,使整个业务流程均可以在云上完成。另外通过一个小小的实验,帮助大家回顾之前的社区活动内容同时也将本期知识融合进来,可以更好的帮助到大家真正的去使用阿里云服务,体验云计算的魅力。最后希望大家真正的去体验一下阿里云RocketMQ,毕竟大厂的羊毛必须薅!!!