今天的博客主题
MQ消息中间件 --》RocketMQ --》RocketMQ入门(一)
本文主要了解认识RocketMQ
对于新接触RocketMQ的同学来说 入门篇的五篇文章真的有必要好好看一下去理解它。
我是之前了解过ActiveMQ,只是会应用,没有深入的了解。这个我想达到一个熟悉+的程度
现在工作项目引入RocketMQ,必须深入了解精通,就结合官方的文档及源码来看,更深入的了解它。
会从RocketMQ的简介,核心设计理念,到环境搭建,再到初步的一个使用,API的详解,底层架构的分析,以及管理员集群的操作等这些方面入手。
我是从这些地方参考学习的。
RocketMQ官网地址:https://rocketmq.apache.org/
RocketMQ阿里云地址:https://help.aliyun.com/document_detail/29532.html?spm=a2c4g.11174283.6.542.628f449cbl8R3g
RocketMQ gitHub地址:https://github.com/apache/rocketmq
什么是RocketMQ
RocketMQ 是阿里巴巴集团自主研发的专业消息中间件,基于高可用分布式集群技术,提供消息订阅和发布、消息轨迹查询以及定时(延时)消息、资源统计、监控报警等一系列消息云服务,是企业级互联网架构的核心产品。 消息队列 RocketMQ 历史超过9年,为分布式应用系统提供异步解耦、削峰填谷的能力,同时具备海量消息堆积、高吞吐、可靠重试等互联网应用所需的特性,是阿里巴巴双11使用的核心产品。
在12年的时候,阿里巴巴将RocketMQ捐给了Apache基金会。
协议支持
支持 HTTP 协议:采用 RESTful 标准,方便易用,快速接入,跨网络能力强,并支持七种语言客户端。
支持 TCP 协议:区别于 HTTP 简单的接入方式,提供更为专业、可靠、稳定的 TCP 协议的 SDK 接入。
支持 STOMP 协议:类似于 HTTP 的纯文本的协议机制,常用于脚本语言(如 Ruby、Python、Perl)和消息队列 RocketMQ Broker 进行轻量级交互。
管理工具
Web 控制台:支持 Topic 管理、生产者管理、消费者管理、消息查询、消息轨迹展示和查询、资源报表以及监控报警管理。
OpenAPI:提供 API 便于将消息队列 RocketMQ 管理工具集成到自己的控制台。
mqadmin 命令集:专有云输出提供一套丰富的管理命令集,以命令方式对消息队列 RocketMQ 服务进行管理。
特点
事务消息:实现类似 X/Open XA 的分布事务功能,以达到事务最终一致性状态。
定时(延时)消息:允许消息生产者指定消息进行定时(延时)投递,最长支持 40 天。
大消息:支持最大 4 MB 消息。
消息轨迹:通过消息轨迹,能清晰定位消息从发布者发出,经由消息队列 RocketMQ 服务端,投递给消息订阅者的完整链路,方便定位排查问题。
广播消费:允许同一个 Group ID 所标识的所有 Consumer 都各自消费某条消息一次。
顺序消息:允许消息消费者按照消息发送的顺序对消息进行消费。
重置消费进度:根据时间重置消费进度,允许用户进行消息回溯或者丢弃堆积消息。
死信队列:将无法正常消费的消息储存到特殊的死信队列供后续处理。
全球消息路由:用于全球不同地域之间的消息同步复制,保证地域之间的数据一致性。
名词解释
RocketMQ 涉及的专有名词及术语进行定义和解析,可以更好地理解相关概念并使用消息队列 RocketMQ
Topic(消息主题)
一级消息类型,通过 Topic 对消息进行分类。
Tag(消息标签)
二级消息类型,用来进一步区分某个 Topic 下的消息分类。
Message(消息)
消息队列中传递信息的载体。
Message ID(消息的全局唯一标识)
由消息队列 RocketMQ 系统自动生成,标识某条消息。
Message Key(消息的业务标识)
由消息生产者(Producer)设置,标识某个业务逻辑。
Producer(生产者)
消息生产者,负责生产并发送消息。
Consumer(消费者)
消息消费者,也称为消息订阅者,负责接收消费消息。
Group (组)
一类 Producer 或 Consumer,这类 Producer 或 Consumer 通常生产或消费同一类消息,且消息发布或订阅的逻辑一致。
被称为生产组(producer group)或消费组 (consumer group)
Group ID(组ID)
Group 的标识。
基本概念
消息模型(Message Model)
RocketMQ主要由 Producer、Broker、Consumer 三部分组成,其中 Producer 负责生产消息,Consumer 负责消费消息,Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器,每个 Broker 可以存储多个Topic的消息,每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址,每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。
代理服务器(Broker Server)
消息中转角色,负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据,包括消费者组、消费进度偏移和主题和队列消息等。
名称服务(Name Server)
名称服务充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表。多个Namesrv实例组成集群,但相互独立,没有信息交换。
Producer Group(生产者组)
同一类Producer的集合,这类Producer发送同一类消息且发送逻辑一致。如果发送的是事物消息且原始生产者在发送之后崩溃,则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。
Consumer Group(消费者组)
同一类Consumer的集合,这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面,实现负载均衡和容错的目标变得非常容易。要注意的是,消费者组的消费者实例必须订阅完全相同的Topic。
Pull Consumer(拉取消费)
Consumer消费的一种类型,应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息,应用就会启动消费过程。
Push Consumer(推动消费)
Consumer消费的一种类型,该模式下Broker收到数据后会主动推送给消费端,该消费模式一般实时性较高。
Clustering Consumer(集群消费)
集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息。一个 Group ID 所标识的所有 Consumer 平均分摊消费消息。例如某个 Topic 有 9 条消息,一个 Group ID 有3个 Consumer 实例,在集群消费模式下每个实例平均分摊,只消费其中的 3 条消息。
Broadcasting Consumer(广播消费)
广播消费模式下,相同Consumer Group的每个Consumer实例都接收全量的消息。一个 Group ID 所标识的所有 Consumer 都会各自消费某条消息一次。例如某个 Topic 有 9 条消息,一个 Group ID 有3个 Consumer 实例,在广播消费模式下每个实例都会各自消费 9 条消息。
Normal Ordered Message(普通顺序消息)
普通顺序消费模式下,消费者通过同一个消费队列收到的消息是有顺序的,不同消息队列收到的消息则可能是无顺序的。
Strictly Ordered Message(严格顺序消息)
严格顺序消息模式下,消费者收到的所有消息均是有顺序的。
Message Producer(消息生产者)
负责生产消息,一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式,同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息,单向发送不需要。
Message Consumer(消息消费者)
负责消费消息,一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式:拉取式消费、推动式消费。
Topic(主题)
表示一类消息的集合,每个主题包含若干条消息,每条消息只能属于一个主题,是RocketMQ进行消息订阅的基本单位。
Tag(标签)
为消息设置的标志,用于同一主题下区分不同类型的消息。来自同一业务单元的消息,可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性,并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑,实现更好的扩展性。
Message(消息)
消息系统所传输信息的物理载体,生产和消费数据的最小单位,每条消息必须属于一个主题。RocketMQ中每个消息拥有唯一的Message ID,且可以携带具有业务标识的Key。系统提供了通过Message ID和Key查询消息的功能。
delayed Message (定时消息/延时消息)
Producer 将消息发送到消息队列 RocketMQ 服务端,但并不期望这条消息立马投递,而是在当前时间点之后的某一个时间投递到 Consumer 进行消费,该消息即定时消息。
Transaction Message (事务消息)
消息队列 RocketMQ 提供类似 X/Open XA 的分布事务功能,通过消息队列 RocketMQ 的事务消息能达到分布式事务的最终一致。
Orderly Message (顺序消息)
消息队列 RocketMQ 提供的一种按照顺序进行发布和消费的消息类型, 分为全局顺序消息和分区顺序消息。
全局顺序消息:
对于指定的一个 Topic,所有消息按照严格的先入先出(FIFO)的顺序进行发布和消费。
分区顺序消息:
对于指定的一个 Topic,所有消息根据 sharding key 进行区块分区。同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。
Sharding key 是顺序消息中用来区分不同分区的关键字段,和普通消息的 key 是完全不同的概念。
Message PileUp (消息堆积)
Producer 已经将消息发送到消息队列 RocketMQ 的服务端,但由于 Consumer 消费能力有限,未能在短时间内将所有消息正确消费掉,
此时在消息队列 RocketMQ 的服务端保存着未被消费的消息,该状态即消息堆积。
Message Filter (消息过滤)
消费者可以根据消息标签(Tag)对消息进行过滤,确保消费者最终只接收被过滤后的消息类型。消息过滤在消息队列 RocketMQ 的服务端完成。
Message Trace (消息轨迹)
在一条消息从生产者发出到订阅者消费处理过程中,由各个相关节点的时间、地点等数据汇聚而成的完整链路信息。通过消息轨迹,您能清晰定位消息从生产者发出,经由消息队列 RocketMQ 服务端,投递给消息消费者的完整链路,方便定位排查问题。
Reset Consumer Locus (重置消费位点)
以时间轴为坐标,在消息持久化存储的时间范围内(默认 3 天),重新设置消息消费者对其订阅 Topic 的消费进度,
设置完成后订阅者将接收设定时间点之后由消息生产者发送到消息队列 RocketMQ 服务端的消息。
Dead Letter Queue (死信队列)
死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败,消息队列 RocketMQ 会自动进行消息重试;达到最大重试次数后,若消费依然失败,则表明消费者在正常情况下无法正确地消费该消息,此时,消息队列 RocketMQ 不会立刻将消息丢弃,而是将其发送到该消费者对应的特殊队列中。
消息队列 RocketMQ 将这种正常情况下无法被消费的消息称为死信消息(Dead-Letter Message)
消息队列 RocketMQ 将存储死信消息的特殊队列称为死信队列(Dead-Letter Queue)。
Message Route (消息路由)
消息路由常用于不同地域之间的消息同步,保证地域之间的数据一致性。消息队列 RocketMQ 的全球消息路由功能依托阿里云优质基础设施实现的高速通道专线,可以高效地实现国内外不同地域之间的消息同步复制。
都是从官网摘录的,和读书一样,一个字一个字的码过来,这样记忆更深刻。喜欢码字的过程...
这里就不标原创了,算是翻译过来吧,尊重原创的成果...