RocketMQ基础知识

目录

一、基础概念

1、主题（Topic）

2、消息类型（MessageType）

3、消息队列 （MessageQueue）

4、消息 （Message）

5、消息视图（MessageView）

6、消息标签（MessageTag）

7、消息位点（MessageQueueOffset）

8、消费位点（ConsumerOffset）

9、消息索引（MessageKey）

10、生产者（Producer）

11、事务检查器（TransactionChecker）

12、事务状态（TransactionResolution）

13、消费者分组（ConsumerGroup）

14、消费者（Consumer）

15、消费结果（ConsumerResult）

16、订阅关系（Subscription）

二、消息存储机制

1、消息存储三个关键问题

2、消息存储文件结构

三、消息过期清理机制

四、部署模型

1、NameServer（名字服务器）

2、Broker

五、部署方式

---

一、基础概念

1、主题（Topic）

        RocketMQ中消息传输和储存的顶级容器，用于标识同一业务逻辑的消息。主题通过TopicName来做唯一标识和区分

        官网介绍

2、消息类型（MessageType）

        RocketMQ中按照消息传输特性的不同而定义的分类，用于类型管理和安全校验

        普通消息、事务消息、定时/延迟消息、顺序消息

3、消息队列 （MessageQueue）

        队列是消息传输和存储的实际容器，也是消息最小的存储单元。所有主题都有多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。

        队列通过QueueId来做唯一标识和区分

        官网介绍

4、消息 （Message）

        消息是最小的数据传输单元

        生产者将业务数据打包成消息发送到服务端，服务端按照相关配置投递到消费端进行消费

        官网介绍

5、消息视图（MessageView）

        消息视图是面向开发视角提供的一种消息只读接口

        通过消息视图可以读取消息内容，但是不能对消息本身进行修改

6、消息标签（MessageTag）

        标签是更细粒度的分类属性，可以在Topic下做更进一步业务逻辑细分

        消费者通过tag可对消息进行消息过滤

7、消息位点（MessageQueueOffset）

        消息是按照到达服务端的先后顺序存储在指定主题下的多个队列中，每个消息在队列中有一个唯一的Long类型坐标，这个坐标就是消息位点

8、消费位点（ConsumerOffset）

        消息被某个消费者消费后不会立刻从队列中删除，RocketMQ会基于每个消费者分组记录消费过的最新一条消息的位点，这个位点就是消费位点

      （通俗来讲消费位点就是记录当前具体消费到哪条消息了）

9、消息索引（MessageKey）

        通过消息索引可快速查询到消息存储位置

10、生产者（Producer）

        生产者是生产消息的运行实体，一般运行在业务程序中，把业务数据打包成消息发送到服务端

        官网介绍

11、事务检查器（TransactionChecker）

        实物检查器是生产者用来检查本地事务和异常事务恢复的监听器。通过业务测数据状态来检查和判断事务消息的状态

12、事务状态（TransactionResolution）

        事务消息发送过程中，事务提交的状态标识，服务端通过事务状态控制事务消息是否应该提交和投递

        事务状态：事务提交、事务回滚、事务未决

13、消费者分组（ConsumerGroup）

        消费者分组是承载多个消费策略一致的消费者负载均衡分组

        消费者分组不是一个实体，只是一个逻辑资源。通过消费者分组内初始化多个消费者，可实现消费性能的水平拓展和高可用容灾

        同一分组下所有消费者的消费策略和消费重试策略必须一致（5.X同一从消费者分组获取，消费者不需要关注；3.X/4.X版本由消费者定义，需要注意）

        官网介绍

14、消费者（Consumer）

        消费者是接收消息并对消息进行处理的实体，一般是业务程序

        官网介绍

15、消费结果（ConsumerResult）

        PushConsumer消费监听器处理消息完成后返回的结果，用来标识本次消息是否正常处理

        消费结果包含消费成功和失败

16、订阅关系（Subscription）

        订阅关系是消费者获取、处理消息的规则和状态配置

        订阅关系由消费者分组动态注册到服务端系统，并在后续的消息传输中按照订阅关系定义的过滤规则进行消息匹配和消费进度维护

        官网介绍

二、消息存储机制

        消息按照先后到达服务端的顺序进行保存

1、消息存储三个关键问题

                a、消息存储管理粒度：消息的存储时长，并不按照主题或队列粒度

                b、消息存储判断依据：按照存储时长作为判断依据

                c、消息存储是否与消费状态有关：无

2、消息存储文件结构

                存储路径由storePathRootDir参数决定

                commitLog文件夹存储消息物理文件，consumerQueue文件夹存储逻辑队列索引

三、消息过期清理机制

        消息保存时长并不能完整控制消息的实际保存时间，因为消息存储仍然使用本地磁盘，本地磁盘空间不足时，为保证服务稳定性消息仍然会被强制清理，导致消息的实际保存时长小于设置的保存时长。

四、部署模型

1、NameServer（名字服务器）

        是一个简单的Topic路由注册中心，支持Topic、Broker的动态注册与发现

   主要功能：

        1)、 Broker管理：

                a、存储Broker集群的注册信息

                b、提供心跳检测机制，检查Broker是否存活

        2)、路由信息管理：

                存储整个Broker集群的整个路由信息和用于客户端查询的队列信息

    部署架构：

        一般部署多个实例，每个实例之间互不通信，Broker需要向每个NameServer进行注册

2、Broker

        负责消息的存储、投递、查询

        部署架构：

                standalone：单机部署

                Master-Slave：再次部署方式中，Broker分为Master节点和Slave节点，Master和Slave是一对多的方式；通过BrokerName进行指定对应关系；使用BrokerId区分Master和Slave节点，0是Master节点，非0是Slave节点。其中Master也可部署多个

五、部署方式

        官网介绍