关于消息中间件RocketMQ的基本概念及功能
作者：叫我二蛋
背景
RocketMQ是阿里巴巴在2012年开发的分布式消息中间件，专为万亿级超大规模的消息处理而设计，具有高吞吐量、低延迟、海量堆积、顺序收发等特点。
2015年，RocketMQ在消息传递方面迎来了一批重量级功能发布，包括事务消息、SQL过滤、轨迹追踪、定时消息、高可用多活等，以满足阿里巴巴日益丰富的业务场景。同年，RocketMQ被捐赠给Apache基金会，并入选孵化器项目，旨在未来为更多开发者服务。
2017年从Apache基金会毕业后，RocketMQ被指定为顶级项目（TLP）。
架构模型
RocketMQ基于kafka的设计使用Java重写，其架构模型如下图：
- NameServer Cluster 可以对应Kafka中的Zookeeper Cluster。
- 多个Broker Master 可以对应Kafka中的分区承载体。
- Broker Slave 可以对应Kafka中的replica承载体。
NameServer 名字服务器
NameServer是一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。主要包括两个功能：
- Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
- 路由信息管理，每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。
NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。
Broker 代理服务器
Broker主要负责消息的存储、投递和查询以及服务高可用保证。
在 Master-Slave 架构中，Master可以部署多个，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。
生产者
生产者用来构建并传输消息到服务端的运行实体。生产者通常被集成在业务系统中，将业务消息按照要求封装成消息并发送至服务端。投递的过程支持快速失败和重试，并且支持以下几个形式：
- 普通消息
- 顺序消息
- 事务消息
- 延迟消息
- 批量消息
主题
主题是消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。 主题的作用主要如下：
- 定义数据的分类隔离： 建议将不同业务类型的数据拆分到不同的主题中管理，通过主题实现存储的隔离性和订阅隔离性。
- 定义数据的身份和权限：消息本身是匿名无身份的，同一分类的消息使用相同的主题来做身份识别和权限管理。
队列
队列是消息存储和传输的实际容器，也是消息的最小存储单元。队列的主要作用如下：
- 存储顺序性：队列天然具备顺序性，即消息按照进入队列的顺序写入存储，同一队列间的消息天然存在顺序关系，队列头部为最早写入的消息，队列尾部为最新写入的消息。消息在队列中的位置和消息之间的顺序通过位点（Offset）进行标记管理。
消息
消息是最小数据传输单元。具备如下特点：
- 消息不可变性：消息本质上是已经产生并确定的事件，一旦产生后，消息的内容不会发生改变。
- 消息持久化：RocketMQ 会默认对消息进行持久化，保证消息的可回溯性和系统故障场景下的可恢复性。
消息标签
消息标签是RocketMQ提供的细粒度消息分类属性，可以在主题层级之下做消息类型的细分。
消息位点
消息是按到达RocketMQ服务端的先后顺序存储在指定主题的多个队列中，每条消息在队列中都有一个唯一的Long类型坐标，这个坐标被定义为消息位点。
消费者
消费者中用来接收并处理消息的运行实体。消费者通常被集成在业务系统中，从服务端获取消息，并将消息转化成业务可理解的信息，供业务逻辑处理。有以下几个功能：
- 支持以推（push），拉（pull）两种模式对消息进行消费。
- 支持集群方式和广播方式的消费。
消费位点
一条消息被某个消费者消费完成后不会立即从队列中删除，RocketMQ会基于每个消费者分组记录消费过的最新一条消息的位点，即消费位点。可以通过重置消费位点来实现一些功能，比如，业务回溯，纠正处理。
消费者分组
消费者分组承载多个消费行为一致的消费者的负载均衡分组。和消费者不同，消费者分组并不是运行实体，而是一个逻辑资源，通过消费者分组初始化多个消费者实现消费性能的水平扩展以及高可用容灾。在消费者分组中，统一定义以下消费行为：
- 订阅关系：消费者分组的粒度管理订阅关系，实现订阅关系的管理和追溯。
- 投递顺序性：服务端将消息投递给消费者消费时，支持顺序投递和并发投递，投递方式在消费者分组中统一配置。
- 消费重试策略： 消费者消费消息失败时的重试策略，包括重试次数、死信队列设置等。具体信息，请参见消费重试。
订阅关系
订阅关系是RocketMQ系统中消费者获取消息、处理消息的规则和状态配置。
由消费者分组动态注册到服务端系统，并在后续的消息传输中按照订阅关系定义的过滤规则进行消息匹配和消费进度维护。通过配置订阅关系，可控制如下传输行为：
- 消息过滤规则：用于控制消费者在消费消息时，选择主题内的哪些消息进行消费。
- 消费状态：消费者分组在服务端注册订阅关系后，当消费者离线并再次上线后，可以获取离线前的消费进度并继续消费。
参考文章
到此这篇关于关于消息中间件RocketMQ的基本概念及功能的文章就介绍到这了,更多相关RocketMQ概念及功能内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！