【消息队列】RocketMQ核心概念名词扫盲

工欲善其事必先利其器~

本文最后更新于2020年11月30日,可能由于时间等因素导致内容失效,请自行辨别或联系作者。

前言

工欲善其事必先利其器,在正式开始学习MQ之前,我们先要了解RocketMQ的架构,以及一些名词的含义。本文可能会比较枯燥,可以先有个印象。

技术架构

RocketMQ架构上主要分为四部分,如上图所示

Producer

消息产生者,负责产生消息。一般由业务系统负责产生。

支持分布式集群方式部署,消息由Producer通过多种负载均衡模式发送到Broker集群,发送低延时,支持快速失败。

会随机选择一个 NameServer 进行长连接,获取 Topic 路由消息。与提供 Topic 服务的 Master 创建长连接,并发送心跳。

有三种方式发送消息:同步、异步和单向。

同步发送:指消息发送方发出数据后,会在收到接收方发回响应之后,才发下一个数据包。一般用于重要通知消息,例如重要通知邮件、营销短信。

异步发送:指发送方发出数据后,不等接收方发回响应,接着发送下个数据包。一般用于可能链路耗时较长而对响应时间敏感的业务场景,例如用户视频上传后通知启动转码服务。

单向发送:指只负责发送消息,而不等待服务器回应且没有回调函数触发。适用于某些耗时非常短但对可靠性要求并不高的场景,例如日志收集。

Comsumer

消息消费者,负责消费消息

支持分布式集群方式部署。

支持以push推,pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费,提供实时的消息订阅机制。

随机选择一个 NameServer 进行长连接,获取 Topic 路由消息。与提供 Topic 服务的 Master、Slave 创建长连接,并发送心跳。

Broker

存储Producer发送过来的消息与相关信息。

单个Broker节点与所有的NameServer节点保持长连接及心跳,并会定时将Topic信息注册到NameServer。

Broker负责消息存储,以Topic为纬度支持轻量级的队列,单机可以支撑上万队列规模,支持消息推拉模型。

官网上有数据显示:具有上亿级消息堆积能力,同时可严格保证消息的有序性。

NameServer

主要负责对于源数据的管理,包括了对于Topic和路由信息的管理。

为Producer或Comsumer路由消息到Broker,是一个非常简单的Topic路由注册中心,支持Broker的动态注册与发现。

每个NameServer节点互相之间是独立的,没有任何信息交互,通过部署多台机器来标记自己是一个伪集群。

NameServer压力不会太大,平时主要开销是在维持心跳和提供Topic-Broker的关系数据。

每个 Broker 在启动的时候会到 NameServer 注册,Producer 在发送消息前会根据 Topic 到 NameServer 获取到 Broker 的路由信息,Consumer 也会定时获取 Topic 的路由信息。

消息领域型模型

Topic(主题)

Topic 可以看做消息的规类,它是消息的第一级类型。比如一个电商系统可以分为:交易消息、物流消息等,一条消息必须有一个 Topic 。

Topic 与生产者和消费者的关系非常松散,一个 Topic 可以有0个、1个、多个生产者向其发送消息,一个生产者也可以同时向不同的 Topic 发送消息。

一个 Topic 也可以被 0个、1个、多个消费者订阅。

Tag(标签)

Tag 可以看作子主题,它是消息的第二级类型,用于为用户提供额外的灵活性。使用标签,同一业务模块 不同目的 的消息就可以用相同 Topic 而不同的 Tag 来标识。比如交易消息又可以分为:交易创建消息、交易完成消息等,一条消息可以没有 Tag 。

标签有助于保持您的代码干净和连贯,并且还可以为 RocketMQ 提供的查询系统提供帮助。

Message(消息)

Message 就是要传输的信息

一条消息必须有一个主题(Topic),主题可以看做是你的信件要邮寄的地址。

一条消息也可以拥有一个可选的标签(Tag)和额处的键值对,它们可以用于设置一个业务 Key 并在 Broker 上查找此消息以便在开发期间查找问题。

Group(分组)

分组,一个组可以订阅多个Topic。

分为ProducerGroup,ConsumerGroup,代表某一类的生产者和消费者,一般来说同一个服务可以作为Group,同一个Group一般来说发送和消费的消息都是一样的。

消费组中包含多个消费者,同一个组内的消费者是竞争消费的关系,每个消费者负责消费组内的一部分消息。如果一条消息被消费者 Consumer1 消费了,那同组的其他消费者就不会再收到这条消息。

Queue(队列)

每个Queue内部是有序的,在RocketMQ中分为读和写两种队列,一般来说读写队列数量一致,如果不一致就会出现很多问题。

Message Queue(消息队列)

Message Queue,主题被划分为一个或多个子主题,即消息队列。

一个 Topic 下可以设置多个消息队列,发送消息时执行该消息的 Topic ,RocketMQ 会轮询该 Topic 下的所有队列将消息发出去。

消息的物理管理单位。一个Topic下可以有多个Queue,Queue的引入使得消息的存储可以分布式集群化,具有了水平扩展能力。

Offset

在RocketMQ 中,所有消息队列都是持久化,长度无限的数据结构,所谓长度无限是指队列中的每个存储单元都是定长,访问其中的存储单元使用 Offset 来访问,Offset 为 java long 类型,64 位,理论上在 100年内不会溢出,所以认为是长度无限。

也可以认为 Message Queue 是一个长度无限的数组,Offset 就是下标。

在 Topic 的消费过程中,由于消息需要被不同的组进行多次消费,所以消费完的消息并不会立即被删除,这就需要 RocketMQ 为每个消费组在每个队列上维护一个消费位置(Consumer Offset),这个位置之前的消息都被消费过,之后的消息都没有被消费过,每成功消费一条消息,消费位置就加一。这个消费位置是非常重要的概念,我们在使用消息队列的时候,丢消息的原因大多是由于消费位置处理不当导致的。

消息消费模式

消息消费模式有两种:Clustering(集群消费)和 Broadcasting(广播消费)。

默认情况下就是集群消费,该模式下一个消费者集群共同消费一个主题的多个队列,一个队列只会被一个消费者消费,如果某个消费者挂掉,分组内其它消费者会接替挂掉的消费者继续消费。

而广播消费消息会发给消费者组中的每一个消费者进行消费。

Message Order(消息顺序)

Message Order有两种:Orderly(顺序消费)和 Concurrently(并行消费)。

顺序消费表示消息消费的顺序同生产者为每个消息队列发送的顺序一致,所以如果正在处理全局顺序是强制性的场景,需要确保使用的主题只有一个消息队列。

并行消费不再保证消息顺序,消费的最大并行数量受每个消费者客户端指定的线程池限制。

参考

冒着期末挂科的风险也要给你看的消息队列和RocketMQ入门总结

《浅入浅出》-RocketMQ

为TA充电
共{{data.count}}人
人已赞赏
消息队列编程语言

【消息队列】本地部署RocketMQ

2020-11-26 22:17:27

消息队列编程语言

【消息队列】SpringBoot集成RocketMQ

2020-12-3 22:13:16

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
今日签到
有新私信 私信列表
搜索