一、RocketMQ消息核心定义与基础结构

1.1 消息定义

RocketMQ消息是分布式系统中业务数据传输的最小载体单元，是生产者向Broker投递、消费者拉取处理的核心数据实体，用于跨服务、跨模块异步传递业务信息，实现系统解耦、异步通信、流量削峰等分布式能力。所有RocketMQ的发送、消费、重试、事务、过滤等机制，全部基于消息实体展开。

1.2 消息核心组成结构

一条标准的RocketMQ消息由基础属性、业务载荷、扩展属性三部分组成，也是所有高级消息特性的实现基础：

• Topic（主题）：消息的分类标识，是消息的第一级路由维度，生产者按Topic发送消息，消费者按Topic订阅消费，用于区分不同业务消息。

• Body（消息体）：核心业务数据载荷，支持字符串、JSON、字节数组等二进制数据，是业务真正需要处理的内容，无格式限制。

• Tag（消息标签）：Topic下的二级分类标签，用于同一主题内细分业务类型，实现轻量消息过滤，不影响集群性能。

• Keys（消息唯一键）：业务自定义唯一标识，用于消息精准查询、轨迹追踪、问题定位，建议每个业务消息配置唯一Key。

• 自定义属性（UserProperty）：消息扩展字段，可自定义键值对，用于SQL过滤、事务回查、延迟标识、业务透传参数等高级能力。

• 系统内置属性：包含消息存储时间、投递次数、队列偏移量、延迟等级、事务状态等，由Broker自动维护，用于消息重试、位点管理、生命周期管控。

1.3 消息核心特性

• 持久化特性：消息投递至Broker后落地磁盘持久化，默认保留72小时，不会随服务重启丢失；

• 不可篡改：消息存储后内容不可修改，仅能删除或过期清理，保证数据一致性；

• 可追溯：依托offset位点与Keys索引，支持消息查询、轨迹回溯、故障复盘；

• 高可靠投递：依托确认、重试、死信机制，保障消息至少一次成功投递。

二、RocketMQ 生产者 & 消费者核心模型

2.1 Producer 生产者详解

生产者是消息的发起方，负责业务消息的创建、投递，依托 NameServer 完成路由负载均衡，将消息发送至 Broker 集群。

核心发送模式

• 同步发送（Sync）：发送消息后阻塞等待 Broker 响应，拿到发送结果，可靠性最高，适合支付、订单等核心业务。

• 异步发送（Async）：发送后立即返回，通过回调函数接收结果，吞吐量高，适合高并发非核心业务。

• 单向发送（OneWay）：只发送不等待响应、无回调，极致高性能，适合日志、埋点、统计类无关紧要消息。

• 事务发送：专属事务消息发送模式，基于两阶段提交保证分布式一致性。

生产者核心特性：自带失败重试、路由自动刷新、负载均衡投递、消息容错机制。

2.2 Consumer 消费者详解

消费者是消息的处理方，RocketMQ 采用消费者主动拉取（Pull）模式，区别于 RabbitMQ 推模式，流量完全可控、稳定性更强。

两大消费模式

• 集群消费（默认）：同一消费组内多条消费者均分消息，一条消息只会被组内一个消费者消费，天然负载均衡，适配绝大多数业务。

• 广播消费：同一消费组内所有消费者全部接收全量消息，每条消息对组内所有节点投递一次，适配全局配置同步、缓存刷新场景。

消费者核心能力：位点偏移维护、失败重试、死信投递、幂等适配、消息回溯。

---

三、RocketMQ 消息确认机制（可靠性核心）

3.1 投递语义：At-Least-Once 至少一次投递

RocketMQ 官方保障：消息绝对不会丢失，允许重复消费。核心依托完善的消息确认与位点机制实现。

3.2 生产者发送确认机制

• 同步/异步发送必须收到 Broker SEND_OK 确认，才判定发送成功；

• 网络超时、Broker 异常、响应失败，生产者自动重试投递；

• 重试次数耗尽仍失败，业务捕获异常做降级兜底。

3.3 消费者消费确认机制（核心）

RocketMQ 无手动 ack，采用自动位点提交 + 异常反向重试机制：

• 消费成功：业务正常执行无异常，消费者定时/批量提交 offset 位点，标记消息已消费，不会再次投递；

• 消费失败：抛出异常/返回重试状态码，不提交位点，Broker 判定消费失败，自动将消息送入重试队列；

• 重试耗尽：默认16次重试失败后，消息转入死信队列，人工排查处理。

生产注意：必须做消费幂等，应对重复投递问题。

---

四、广播消息机制

4.1 原理

广播消费模式下，Broker 会将同一条消息投递到消费组内所有消费者实例，每个节点都会完整接收并消费消息。

4.2 核心特点

• 无负载均衡、消息全量复制投递；

• 不支持重试机制：广播消费失败不会进入重试队列，避免集群重复异常刷屏；

• 消费位点单节点独立维护，互不干扰。

4.3 适用场景

• 全局配置刷新、系统开关更新；

• 全服务缓存预热、本地缓存清空；

• 集群所有节点同步执行的轻量任务。

---

五、顺序消息机制

5.1 核心原理

RocketMQ 顺序消息核心规则：同一队列内的消息严格先进先出（FIFO），不同队列消息无序。

实现关键：生产者将同一业务有序消息（同一订单、同一用户）固定发送到同一个 MessageQueue，消费者单线程消费该队列，保证顺序。

5.2 两类顺序消息

• 分区有序（局部有序，常用）：同一业务维度消息有序，不同业务无序，性能高、生产首选；

• 全局有序（极少用）：整个 Topic 仅一个队列，所有消息全局有序，性能极差，仅适用于极小流量场景。

5.3 优缺点

• 优点：完美保障业务时序，满足订单状态流转、流程递进场景；

• 缺点：单队列单线程消费，无法并行，吞吐量大幅下降；故障影响单一业务队列。

5.4 适用场景

适合有状态流转的业务场景,例如:订单创建→支付→发货→完成、状态机流转、流程型有序业务。

---

六、延迟消息机制

6.1 原理

消息发送至 Broker 后，不会立即投递，而是存入延迟队列，等待指定时长后再转入普通队列供消费者消费。

实现方法：

• 支持18个固定延迟等级（1s~2h）。
• 支持指定时间点的延迟消息，RocketMQ是通过时间轮算法实现的。

6.2 核心流程

1. 生产者指定 delayLevel 发送延迟消息；

2. Broker 接收后存入系统延迟队列，不立即投递；

3. 倒计时结束，消息路由至目标 Topic 普通队列；

4. 消费者正常拉取消费。

6.3 适用场景

• 订单超时未支付自动关闭；

• 售后超时自动确认、任务超时提醒；

• 定时重试、延后执行的异步任务。

---

七、批量消息机制

7.1 原理

将多条同类型消息合并为一次网络请求发送至 Broker，大幅减少网络 IO 次数、降低连接开销，极致提升吞吐量。

7.2 核心规则

• 批量消息必须为同一Topic、相同发送配置；

• 默认限制单批次消息总大小不超过 4MB；

• 批量发送整体成功/整体失败，不支持部分成功。

• 不支持延迟消息、事务消息

7.3 优缺点

• 优点：极大降低网络IO压力，高并发场景吞吐量翻倍；

• 缺点：单条消息失败会导致整批重发，小概率造成批量重复消费；消息延迟堆积。

7.4 适用场景

日志上报、行为埋点、批量数据同步、统计类高吞吐无序消息。

---

八、消息过滤机制

RocketMQ 支持服务端过滤，消费者只接收匹配条件的消息，减少无效消息拉取，节省网络与CPU资源，分为Tag过滤和SQL过滤两种。

8.1 Tag 标签过滤（简单过滤，生产常用）

生产者发送消息绑定 Tag，消费者订阅指定 Tag，实现消息精准筛选，基于字符串匹配，性能极高、无性能损耗。

优点：轻量、高性能、无额外开销；

缺点：仅支持简单匹配，无法做数值、范围、多条件复杂筛选。

8.2 SQL92 高级过滤（复杂过滤）

基于消息自定义属性，支持 SQL92 表达式筛选，可实现大于、小于、区间、多条件组合判断。

适用：按用户等级、地区、渠道、数值范围筛选消息；

缺点：Broker 需解析表达式，有一定性能开销，高并发场景慎用。

---

九、事务消息机制

9.1 核心作用

解决本地事务执行与消息发送的分布式一致性问题，实现「本地事务成功则消息一定投递、本地事务失败则消息不投递」，是电商支付、订单核心依赖能力。

9.2 事务消息核心定义

RocketMQ事务消息是为解决本地数据库事务与消息发送一致性设计的高级消息模型，核心实现 半消息预提交 + 本地事务执行 + 状态确认 + 超时回查兜底 的两阶段提交机制，彻底解决「先发消息后事务失败」或「事务成功未发消息」的数据不一致问题。

9.3 两阶段提交完整文字流程（超详细）

整个事务消息流程分为 预提交阶段、事务执行阶段、状态确认阶段、超时回查兜底阶段 四步，全程无数据不一致：

阶段一：半消息预提交（第一阶段）

生产者不会直接发送业务消息，而是先向Broker发送一条半消息（Half Message）。该消息会正常持久化到Broker，但是对所有消费者不可见、不可消费，仅作为事务预提交凭证，避免消息提前投递导致业务错乱。

阶段二：执行本地事务

Broker持久化半消息成功后，返回响应给生产者，生产者立刻执行自身的本地数据库事务（如订单创建、库存扣减、支付记录写入等核心业务）。

阶段三：提交/回滚确认（第二阶段）

生产者根据本地事务执行结果，向Broker发送最终指令：

• Commit提交：本地事务执行成功，Broker将半消息转为正式业务消息，对消费者可见，正常投递消费；

• Rollback回滚：本地事务执行失败，Broker直接删除半消息，消息永久丢弃，不进行任何投递；

阶段四：超时回查兜底（故障容错）

若生产者宕机、网络超时、程序卡死，导致Broker长时间（默认60s）未收到Commit/Rollback指令，Broker会主动发起事务回查，回调生产者接口查询本地事务最终状态：

• 事务成功 → Broker提交消息，正常投递；

• 事务失败 → Broker回滚删除消息；

• 事务未知 → 持续回查，直至拿到明确状态。

9.4 事务消息完整流程图

流程图注解：事务消息核心闭环在于两阶段锁定+超时回查，无论正常流程还是异常宕机场景，都能保证「事务成功消息必发、事务失败消息不发」，实现分布式最终一致性。

9.5 优缺点

• 优点：极致保证分布式最终一致性，无消息丢失、无错发；

• 缺点：流程复杂、开发成本高、回查逻辑需要自行实现。

9.6 适用场景

订单创建与消息通知、支付结果同步、积分发放、库存扣减等需要事务一致的核心业务。

---

十、ACL 权限控制机制

10.1 什么是ACL

ACL（Access Control List）访问控制列表，是 RocketMQ 官方提供的资源级权限管控机制，用于管控不同客户端对 Topic、集群资源的读写权限，防止越权访问、误操作、恶意调用，保障消息集群安全。

10.2 核心组成

• 访问凭证：AccessKey（账号）+ SecretKey（密钥），客户端签名认证；

• 权限规则：针对 Topic 配置 只读、只写、读写、禁止访问四种权限；

• IP白名单：限制指定IP段才可接入集群，提升安全性；

• 服务端配置：Broker 通过 plain_acl.yml 统一管理权限策略。

10.3 认证授权流程

1. 客户端连接 Broker 时，携带 AK/SK 生成签名；

2. Broker 校验签名合法性、匹配权限规则；

3. 校验通过允许生产/消费，校验失败直接拒绝连接并报错；

4. 支持动态权限更新，无需重启集群。

10.4 核心作用与场景

• 环境隔离：测试、预发、生产环境权限隔离，防止误操作；

• 多业务隔离：不同业务团队仅可操作自身 Topic，互不干扰；

• 安全防护：防止未授权客户端接入、恶意刷消息、误删数据；

• 精细化管控：区分生产者写权限、消费者读权限，最小权限原则落地。

十一、生产必须注意的核心问题

• 幂等性：RocketMQ至少一次投递，业务必须根据消息Key做幂等去重；

• 异常处理：禁止try-catch吞异常，异常抛出自动进入重试队列；

• 事务回查：事务消息必须实现回查接口，防止消息悬挂；

• 大消息控制：单消息不超过4MB，避免大Key阻塞；

• 消费组唯一：不同业务禁止共用同一个消费组，避免消费错乱。