RocketMQ特性

1、为什么需要消息队列

削峰填谷

程序间解耦

异步处理

数据的最终一致性

2、常见消息队列

消息队列	activeMQ	kafka	rocketMQ
特性	支持多种协议：AMQP、STMOP、MQTT、JMS 消息支持持久化	超高写入速率 端到端耗时毫秒级	万亿级消息支持 万级topic数量支持 端到端耗时毫秒级
管理后台	自带	独立部署	独立部署
多语言支持	支持	支持	java、c++、python、go、c#
数据流支持	不支持	支持	支持
消息丢失	理论上不丢失	理论上不丢失	理论上不丢失
文档完整性	好	极好	极好
商业化公司	国内部分企业	国内很多企业	阿里巴巴为主
容错	无重试机制	无重试机制	支持重试、死信消息
顺序消息	支持	支持	支持
定时消息	不支持	支持	支持
事务消息	不支持	不支持	支持
消息查询	数据库中查询	不支持	支持
宕机	自动切换	主动选主	手动重启

3、生产者

生产者组：一个生产者生产多个topic消息

生产者实例：一个生产者部署多个进程，每个进程都可以称为一个生产者实例

topic：主题名称，一个topic由若干个queue组成

4、消息组成

topic

properties：消息扩展信息，Tag、Keys、延迟级别都保持在这里

Body：消息体，字节数组，需要注解编码格式保持一致，防止消息乱码

setKeys：设置消息的key，可以根据key常见消息的hash索引，帮助快速查询

setTags：设置tag，一个topic可以设置不同的tag

setDelayTimeLevel：设置消息延迟级别

putUserProperty：如果有其他要扩展的信息，可以放在这个Map中

5、消息支持类型

普通消息：性能最好

分区有序消息：一个topic对应多个分区，分区使用FIFO原则

全局有序消息：一个topic对应一个分区

延迟消息：消息发送后一段时间后，消费者才可以被消费掉

事务消息：可以保证多个事务同时成功或者失败，机制时half消息、处理本地事务、提交消息、回滚消息的方式实现优雅的分布式事务

6、生产者高可用

客户端保证

重试机制：rocketMQ支持同步、异步方式，都可以在失败后重试，如果一个broker发生故障，可以找到其他可用的broker

客户端容错：客户端可以选择延迟级别最低的broker进行发送消息

Broker保证

数据同步分为同步复制、异步复制两种。

同步复制是指消息发送到master broker后，同步到slave broker才算发送成功。

异步复制是指消息发送到master broker后就算成功。

如果是多个master slave也是类似的方式。

如果想要保持绝对的高可用，将broker配置的主从同步进行复制即可，只要生产者收到消息保持成功就反馈，消息可定不会丢失。

7、消息发送流程

业务层：直接调用rocketMQ client 发送api的业务代码

消息处理层：rocketMQ client 获取业务发送的消息对象后，进行的一些列参数校验、发送准备、参数包装等操作

通信层：rocketMQ基于netty封装的一个rpc通讯协议

8、延迟消息

支持18个级别，从1S、5S、10S、30S、1M、2、3、4、5、6、7、8、9、10、20、30、1h、2h

9、事务消息

第一步先发送一个half消息到broker，Broker设置queueOffset=0，即对消费者不可见

第二笔用户本地事务提交成功后，发送一个commit到broker，broker修改queueoffset为正数值，达到投递目的，如果本地事务提交失败，则发送一个rollback消息给broker。

broker会定期回查生产者，确认生产者本地事务的执行状态，再决定是提交还是回顾还是删除half消息。

10、发送单向消息

主要是日志传输等消息允许丢失的常见

11、批量消息

消息最好小于1M

同一批消息的topic、waitStoreMsgOk属性必须一致

批量消息不支持延迟消息

12、生产者最佳实践

普通消息：性能最好、单机TPS10万级别，缺点是生产和消费都是无须、适用于大部分场景

分区消息：单机有序、单机TPS万级别、缺点是单点问题、如果broker宕机会导致消息发送失败、适用于大部分有序消息场景

 全局有序消息：类型传统queue、单机TPS千级别、单点问题、如果broker宕机会导致消息发送失败、适用场景极少

延迟消息：rocketMQ自身支持、不需要额外组件、缺点是不能根据任意时间延迟、非精确、延迟级别不够多、使用简单方便

事务消息：rocketMQ自身支持、不需要额外组件、缺点是生产者事务、只有生产者参与，如果消费者处理失败则事务无效、简单事务处理可以使用

13、同步与异步发送

同步发送：最可靠、性能最低、适用于高并发常见

异步发送：可靠、性能最高、如果发送失败需要考虑降级、大部分业务场景可以使用

14、常见配置参数

producerGroup生产者分组

消息体数量超过该值则压缩消息

instanceName生产者实例名

maxMessageSize消费体最大值，默认4M

retryXXX异步发送失败的重试次数

retryTimsWhenSendFailed同步发送失败的重试次数

senMsgTimeout发送超时时间

15、消费者概念

消费者组：一个逻辑概念，在使用消费者时要指定一个分组，一个消费者组可以订阅多个topic

消费者实例：一个消费者程序部署多个进程，每个进程都可以称为一个消费者实例

订阅关系：一个消费者组订阅一个topic的某个tag、这种记录被称为订阅关系，消费者分组-topic-tag必须是唯一的

16、消费模式

集群消费与广播消费

集群消费

同一个消费者分组了里的消费者实例，会负载均衡的消费topic

同一个topic会被不同的消费者分组里的消费者实例消费，即1个topic关联多个消费者分组

集群消费的进度保存在broker端，所以即使应用崩溃、消费进度也不会丢失

广播模式

即消费者组中的全部消费者实例将消费整个topic的全部消息

一个消费者分组中的两个消费者实例，每个消费者实例消耗相同数量的topic消息，不会进行负载均衡

17、可靠消息

重试消费（做多16次）、死信机制（超过16次则放入死信队列）

死信队列：命名格式“%DLQ%消费者组名”

18、rebalance机制

重平衡机制，用于在发现broker掉线、topic扩容或者缩容、消费者扩容和缩容等变化时，自动感知并调整自身消费，尽力减少甚至避免消费没有被消费。

19、消费进度保存机制

rocketMQ设计了远程位点管理和本地位点管理两种位点管理方式

集群消费时，位点管理由客户端交给broker管理

广播模式下，位点保存在消费者本地磁盘上（即使丢失了，也可以重复消费）

20、消费方式push与pull

pull方式：用户主动pull消息，自主管理位点，可以灵活掌控消费进度、消费速度，缺点时需要从代码层面精准控制消费

push方式：代码接入简单、排查问题方便、适用于大部分常见，缺点是灵活度差

21、rocketMQ架构

console控制台：创建topic、key查询消费

namesrv：一个无状态的元数据管理、类似与kafka中zookeeper的定位

broker集群：保存消息、处理生产者、消费者的各种请求的代理，包括master和slave两个角色

生产者集群：消费发送方

消费者集群：消息消费方

22、namesrv

部署推荐2~3个节点

23、broker部署方式

单个master、单master单slave、多个master无slave、多个master多个slave异步复制、多个master多个slave同步复制

24、刷盘

消息保持到内存后，可以同步、异步方式写到磁盘上

同步刷盘：生产者等待写入磁盘才返回发送成功

异步刷盘：生产者写入内存就可以返回发送成功

25、namesrv

主要保持管理topic路由信息（topic队列信息、broker信息、集群和broker对应关系、当前在线的broker地址、过滤服务器信息）、各个namesrv是无状态的，多个namesrv之间不需要同步信息、状态

在broker、生产者、消费者启动时，可以轮训全部配置的namesrv节点、拉取路由信息

Topic路由信息决定了topic信息发送到哪个broker，消费者从哪个broker消费消息

26、namesrv与zookeeper

不适用zookeeper的原因是减少依赖，通过简单的namesrv可以承担

27、namesrv流程

broker启动注册到namesrv中

生产者询问namesrv把消息发送到哪里

namesrv告诉消息发送到的broker

生产者发送消息到broker

消费者询问namesrv在哪里可以消费信息

namesrv告诉消费者具体的broker

消费者向指定broker拉取消息

28、namesrv核心组件

topic路由管理模块：信息发送到哪个broker、从哪个broker消费

remoting通讯模块：netty的一个通讯封装

定时任务模块：扫描宕机的broker、定时打印kv配置、定时扫描超时请求

29、路由注册

namesrv获取的topic路由信息来自broker的定时心跳、心跳时broker会将topic信息发送到namesrv。

30、路由剔除

broker主动剔除

namesrv定时扫描已下线的broker

 31、消费过滤

RocketMQ设计了消息过滤：即对于客户端不需要的消息，Broker不会传输给客户端，以避免浪费。

使用Tag进行过滤消息

过滤步骤：

1、用户发送一个带有tag的消息

2、用户订阅一个topic的tag，RocketMQ broker会保持订阅关系

3、在Broker端做tag过滤。消费者pull时RocketMQ broker会根据tag的hashcode进行比较，如果不满足条，不会返回给消费者。

4、客户端tag过滤，由于hashcode存在碰撞问题，所以还以在客户端进行字符串比较

32、消息问题排查

1、topic是否一致：生产者、消费者、控制台

2、订阅关系是否一致

3、消费者是否抛出了异常，如果没有抛出异常，消息不会进行重试

4、消费者服务器与namesrv或者broker是否网络通畅

33、Broker存储机制

Broker主要负责处理各种tcp请求和存储消息

Broker分为master和slave，master主要提供服务，slave在master宕机后提供消费服务。

34、Broker存储目录结构

commitlog：目录下有多个文件，文件名有该文件保存消息的最大物理offset值在高位补0组成。文件大小一般1G。

consumequeue：目录下包含该broker上所有的topic对应的消费队列文件信息。

Index：目录下的全部文件都是按照消息key创建的hash索引。

config：目录保存了当前Broker中全部topic、订阅关系和消费进度。

35、Broker启动与停止

第一步：初始化启动环境，包括启动./bin/mqbroker和./bin/runbroker.sh两个脚本，设计到JAVA_HOME、ROCKETMQ_HOME环境变量。

第二步：初始化BrokerController：RocketMQ命令行解析、Broker各个模块配置参数解析、Broker各个模块初始化、进程关机hook初始化等过程。

第三步：启动RocketMQ的各个组件：存储服务、普通请求处理服务、VIP请求处理服务、Broker访问对外接口的封装对象、Pull长轮训服务、清理心跳超时的生产者和消费者和过滤服务、过滤服务器。

36、Broker存储机制

消息会存储到commitlog中，为了方便保存和读取会把commitlog切分为多个文件

Broker按照时间和物理的offset顺序写commitlog文件，每次写的时候需要加锁。

37、为什么写文件很快

参考了kafka的设计

Page Cache：分页读取文件、整页读取可以进行预读

VM：虚拟内存，把暂时不需要的数据保存到磁盘（虚拟内存）

零拷贝与Java文件映射：Java进程可以直接读取到内核态的数据，不需要经过用户态转换

38、Broker消息存储流程

业务系统发送信息

->broker接收到客户端消息进行预处理：解析参数、执行发送处理前的hook、调用保存方法存储消息、执行发送处理后的hook。

->broker存储前进行预处理：设置请求处理返回对象标识

->执行putMessage方法进行消息校验和存储模块检查：存储模块是否已关闭、Broker是否是slave、存储模块运行标识、topic长度、扩展信息长度等

39、文件刷盘机制

同步与异常刷盘：内存数据保持到磁盘

同步刷盘：有一个后台线程服务

异步刷盘：如果broker配置了读写分离，则异步刷盘过程包含异步转存数据和真正的异步刷盘操作。

40、Broker读写分离

master与slave读写分离

直接写内存与读PageCache分离

41、Broker commitlog索引机制

Broker有两个索引：consumer queue和Index File

consumer queue：消费者队列，用于消费者拉取信息、更新消费点

Index File：是一个RocketMQ实现的hash索引，用于用户根据key查询消息

42、Broker过期文件删除机制

commitlog文件删除：当前时间大于已经配置的过期时间、磁盘使用空间超过85%、手动执行删除

步骤一：克隆全部commitlog文件，为了防止有数据写入

步骤二：检查每个commitlog是否过期

43、broker主从同步机制

第一：broker服务高可用，一般生产环境部署两个master、两个slave节点，一个master宕机后，另个一master会继续工作。

第二：提供服务性能，如果消费者发现行master拉取信息时，拉取的offset和commitlog物理offset相差太多，会转向slave拉取消息。

同步复制、同步刷盘

44、生产者启动流程

创建一个生产者实例，设置各种参数，比如namesrv地址、生产者组名等，调用star()方法创建生产者实例。

判断当前生产者的服务状态，默认状态为CREATE_JUST

执行checkConfig方法

执行changeInstanceNameToPID方法

执行getAndCreateMQClientInstance方法

45、消息发送流程

调用defaultMQProducer.send()方法

设置超时时间

设置同步发送

发送前check：生产者状态、消息、消息内容

选择topic、queue发送：获取topic路由信息

计算信息发送的重试次数，同步重试或者异步重试

执行sendKernel方法

46、消费者启动机制

调用DefaultMQPullConsumer的start()方法

检查消费者的配置，消费者组名、消费类型、Queue分配策略

检验消费者实例名

获取一个MQClientInstance

设置rebalance对象消费者组、消费类型、Queue分配策略等

对Broker api的封装类进行初始化

初始化位点管理器，并加载位点信息

本地注册消费者实例

启动MQClientInstance