RocketMQ基础知识概念解释

RocketMQ 学习

基础概念

• Producer: 消息生产者，负责产生信息，一般由业务系统负责产生消息
• Producer Group: 消息生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组
• Consumer: 消息消费者，负责消费消息，一般是后台系统负责异步消费
• Consumer Group: 消费者组，和生产者类似
• Topic : 主题，用来讲消息按主题做划分，Producer将消息发送到指定Topic，Consumer订阅该Topic就可以收到这条数据
• Message: 消息，每个message必须指定一个topic，Message还有一个可选的Tag设置，以便消费端可以基于Tag进行过滤消息
• Tag: 标签，子主题（二级分类）对topic进一步细化，用于区分同一个主题下的不同业务消息
• Broker: Broker是RocketMQ的核心模块，负责接收并储存消息，同时提供Push/Pull接口来将消息发送给Consumer。Broker

同时提供消息查询的功能，可以通过MessageID和MessageKey来查询消息。Broker会将自己的Topic配置信息实时的同步到NameServer

• Queue: Topic和Queue是 1 对多的关系，一个Topic下可以包含多个Queue，主要用于负载均衡，Queue数量设置建议不要比消费者数少。发送消息时，用户只指定Topic，Producer会根据Topic的路由信息选择具体发到哪个Queue上。Consumer订阅消息时，会根据负载均衡策略决定订阅哪些Queue的消息
• Offset: RocketMQ在存储消息时会为每个Topic下的每个Queue生成一个消息的索引文件，每个Queue都对应一个Offset记录当前Queue中消息条数
• NameServer: NameServer可以看作是RocketMQ的注册中心，它管理两部分数据：集群的Topic-Queue的路由配置；Broker的实时配置信息。其它模块通过NameServer提供的接口获取最新的Topic配置和路由信息；各NameServer 之间不会互相通信， 各 NameServer 都有完整的路由信息，即无状态

结构对应关系如下图：

RocketMQ消费模式

集群消费模式

广播消费模式

RocketMQ高可用机制

集群部署模式

• 单master模式
• 多master模式
• 多master多slave（同步）
• 多master多slave（异步）
  

刷盘与主从同步

• 同步刷盘和异步刷盘

• 同步复制与异步复制

RocketMQ的存储设计

Model结构

• Message
• Topic
• Queue
• Offset
• Group
  

消息存储结构

RocketMQ因为有高可靠性的要求（宕机不丢失数据），所以数据要进行持久化存储，因
此RocketMQ使用文件进行存储

存储文件：

commitlog: 消息存储目录

config: 运行期间一些配置信息

consumerqueue: 消息消费队列存储目录

index：消息索引文件存储目录

abort: 如果存在改文件则Broker非正常关闭

checkpoint：文件检查点，存储commitlog文件最后一次刷盘时间戳、consumerqueue最后一次刷盘时间，index索引文件最后一次刷盘时间戳

CommitLog

CommitLog 以物理文件的方式存放，每台 Broker 上的 CommitLog 被本机器所有ConsumeQueue 共享，文件地址：＄ (user. home)\store${ conmitlog}${ fileName)。在 CommitLog 中，一个消息的存储长度是不固定的，RocketMQ 采取一些机制，尽量向 CoumitLog 中顺序写，但是随机读。commitlog 文件默认大小为1G，可通过在 broker 罝文件中设罝 mappedFilesizeCommitLog 属性来改变默认大小。

CommitLog文件存储的逻辑视图进入下，每条消息的前四个字节存储该消息的总长度，但是一个消息的存储长度是不固定的

每个CommitLog文件的大小为1G, 一般情况下第一个commitLog的起始偏移量为 0 ，第二个CommitLog的起始偏移量为 1073741 824byte = 1G

每台Rocket只会往一个commitLog文件中写，写完一个接着写下一个,indexFile和comsumerQueue中都有消息对应的物理偏移量，通过物理偏移量就可以计算出该消息位于哪个commitLog文件上。

CommitLog负责所有消息的实际存储！！consumeQueue只是存索引！

ConsumeQueue

ConsumeQueue 是消息的逻辑队列，类似数据库的索引文件，存储的是指向物理存储的地址。每个 Topic 下的每个 Message Queue 都有一个对应的ConsumeQueue 文件，文件地址在$ (SstoreRoot) \consumequeue$ {topicName} \ ${ queueld} \ ${filename}

ConsumeQueue 中存储的是消息条目，为了加速 ConsumeQueue 消.息条目的检素速度与节省磁盘空问，每个Consumequeue 条日不会存储消息的全量信息，消息条目如下：

ConstmeQueue 即为 Commitlog 文件的索引文件，其构建机制是 当消息到达 Commitlog文件后 由专门的线程产生消息转发任务，从而构建消息消费队列文件(ConsumeQueue）与下文提到的索引文件。

存储机制这样设计有以下几个好处

1. CommitLog 顺序写，可以大大提商写入效率。
   （实际上，磁盘有时候会比你想象的快很多，有时候也比你想象的慢很多，关键在如何使用，使用得当）

2. 虽然是随机读，但是利用操作系统的 pagecache 机制，可以批量地从磁盘读取，作为 cache 存到内存中，加速后续的读取速度

3. 为了保证完全的顺序写，需要 ConsumeQueue 这个中问结构，因为ConsumeQueue 里只存偏移显信息，所以尺寸是有限的，在实际情况中，大部分的TConsumeoueue 能多放全部读入内存，所以这个中间结构的操作速度很快，可以认为是内存读取的速度。此外为了保证 CommitLog 和 ConsumeQueue的一致性，CommitLog 里存储了 Consume Queues 、 Message key、 Tag 等所有信息，即使 ConsumeQueue 丢失，也可以通过 commitLog 完全恢复出来。

分布式事务

rocketMQ分布式事务方案

先向mq发送半事务消息，此时消费者无法看到 → 再执行本地事务，这个时候还没有提交 → 等到事务回查的时候才进行提交，此时消费者才能看到消息

Broker的启动流程

如图所示：

消息发送者启动流程

心跳报文

目的：确保broker没挂，如果报文出问题 broker挂了 就让slaver去替代master

• producer/consumer 和 broker之间通过心跳报文来维持连接。
• broker 和 namesrv之间通过定时上报来维持连接。
• producer/consumer 和 namesrv之间通过定时拉取Topic路由信息来维持连接。