RocketMQ常见问题梳理
一、MQ如何保证消息不丢失？
1 生产阶段
消息丢失的场景
单向发送：同步发送后不检查
SendResult，失败也当成功。同步发送后不检查
SendResult，失败也当成功。
解决措施
这个阶段的目标是确保消息从客户端成功发送到 Broker。
同步发送：
producer.send(msg)阻塞等待结果，明确消息发送成功/失败配置合理重试：
retryTimesWhenSendFailed=3，网络抖动时自动重试事务消息：半消息+本地事务确认，保证生产端与业务操作原子性
2 存储阶段
消息丢失的场景
- 异步刷盘：消息只写内存PageCache，断电瞬间消失。
- 异步复制：主节点返回成功时从节点还没收到，主节点一宕机消息就丢失。
- 单主部署：没有副本，磁盘坏了消息全没。
解决措施
这个阶段是保证消息不丢失的核心，目标是确保消息被安全持久化，不会因为 Broker 宕机或重启而丢失。
刷盘机制：同步刷盘（SYNC_FLUSH）
Broker 收到消息后，必须将数据同步写入物理磁盘成功，才会向生产者返回成功确认。这能防止消息仅停留在内存中时因 Broker 断电或重启而丢失。主从复制：同步复制（SYNC_MASTER）
在 Master-Slave 架构下，Master 节点必须等待消息成功同步到至少一个 Slave 节点后，才会返回成功确认。这能防止因 Master 节点宕机且无法恢复导致的消息丢失。多副本部署
至少Master-Slave架构，推荐DLedger（Raft）多数派确认
性能权衡：开启同步刷盘和同步复制会显著降低系统吞吐量。对于可靠性要求极高的核心业务，这是必要的权衡；对于允许少量丢失的非核心业务，可采用异步模式以换取更高性能。
3 消费阶段
消息丢失的场景
- 自动确认：消息刚拉下来就自动确认，业务还没处理完。
- 批量部分失败：拉10条只成功5条，却告诉Broker全消费完了。
- 位点提交错误：手动提交offset时，提交的位置超过了实际处理进度。
解决措施
这个阶段的目标是确保消息被业务方成功处理，防止因处理失败而"逻辑丢失"。
核心机制：手动确认（ACK）
业务处理成功后显式返回CONSUME_SUCCESS，失败返回RECONSUME_LATER逐条确认
批量消费时逐条处理，每条单独返回状态兜底方案：重试队列与死信队列（DLQ）
重试队列：对于消费失败的消息，Broker 会将其放入重试队列，并按照指数退避或固定延迟策略（如 1s, 5s, 10s...）进行最多 16 次重试。
死信队列（DLQ）：当消息达到最大重试次数后仍消费失败，消息将被移入死信队列。业务系统需要单独监控和消费死信队列，进行人工介入或数据补偿，这是防止消息丢失的最后一道防
线。
| 阶段 | 最危险的场景 | 最有效的解决方案 |
|---|---|---|
| 生产 | 单向发送 | 同步发送 + 校验结果 |
| 存储 | 异步刷盘 | 同步刷盘 + 同步复制 |
| 消费 | 自动确认 | 手动ACK + 失败重试 |
4 MQ服务全挂了，如何保证消息不丢失？
NameServer全挂时客户端靠本地缓存能撑一会儿，Broker全挂时则完全无法收发，必须靠降级落盘+事后补偿兜底，同时通过集群化+跨AZ部署尽可能避免“全挂”的发生。
降级落盘
生产者的同步发送会立刻失败，放弃发送到 MQ，转而将消息保存到业务应用本地可靠的存储中（磁盘、数据库、缓存），防止数据丢失。事后补偿
当 MQ 服务恢复正常后，之前降级落盘的消息并不会自动发送，需要一个独立的补偿程序来处理积压的数据。
二、MQ如何保证消息幂等性？
在分布式系统中，由于网络超时、重试机制或客户端重启等原因，消息可能会被重复发送或重复消费。RocketMQ 本身不保证幂等，它只保证消息至少投递一次（At Least Once）。幂等性需要由消费者业务代码自行实现。
1 为什么需要幂等？
消息重复的典型场景
| 阶段 | 重复原因 |
|---|---|
| 生产端 | 同步发送超时，客户端重试，但Broker实际已收到 |
| 消费端 | 消费者处理成功但提交offset超时，Broker未收到确认，重新投递 |
| Broker端 | Master宕机触发自动切换，新选举的Leader可能重复投递 |
不处理幂等的后果
订单系统：同一订单多次创建 → 重复下单
账户系统：同一笔转账多次执行 → 余额错误
库存系统：同一商品多次扣减 → 超卖
2 生产端幂等：防止消息重复写入
业务唯一ID去重：每条消息携带业务唯一ID（如订单号、流水号），放入消息的 key，消费端基于该ID去重（核心在消费端）。
3 消费端幂等：防止重复消费（核心）
这是最关键的环节，因为消费端重复投递是RocketMQ默认行为（At Least Once）。
核心原则：消费幂等 = 根据业务唯一标识判断是否已处理
业务唯一标识（最推荐）
消费时提取业务唯一ID（如订单号、交易流水号），防止重复消费。Redis原子操作
使用SETNX key value EX ttl设置业务ID，
返回1表示首次消费 → 执行业务逻辑
返回0表示已消费过 → 直接ACK状态机法（业务状态驱动）
利用业务对象自身的状态流转，天然幂等。
各方案对比
| 方案 | 优点 | 缺点 | 推荐场景 |
|---|---|---|---|
| 数据库唯一索引 | 绝对可靠，事务可保证原子性 | 性能相对较低，增加DB压力 | 金融、订单等强一致性场景 |
| Redis SETNX | 性能高，毫秒级 | 可能丢失（Redis无持久化），需设置合理TTL | 高并发、可容忍极小概率重复场景 |
| 业务状态机 | 无额外存储，性能最好 | 仅适用于有状态流转的业务 | 订单、审批流等有明确状态变更的场景 |
三、MQ如何保证消息的顺序性？
RocketMQ 本身不保证全局消息顺序，而是通过分区顺序机制来实现局部有序。核心思路是：将需要保持顺序的消息路由到同一个队列中，再由消费者串行处理该队列。
1 为什么MQ需要顺序消息？
| 场景 | 为什么需要顺序 |
|---|---|
| 订单创建 | 同一个订单的"创建→支付→退款→物流"必须按顺序处理，否则状态紊乱 |
| 撮合交易 | 证券/股票交易，相同出价按"先出价先成交"原则 |
| 数据同步 | MySQL binlog同步，下游必须按顺序还原操作 |
2 RocketMQ顺序消息的类型
| 类型 | 原理 | 适用场景 |
|---|---|---|
| 全局顺序 | Topic只有一个队列，所有消息FIFO | 极低吞吐场景（如数据库binlog严格有序） |
| 分区顺序 | 相同消息组的消息进入同一队列，不同组可并行 | 绝大多数业务场景（如按订单ID分区） |
3 如何保证顺序性？
3.1 生产顺序性
生产者通过某种规则（如业务ID）将一组有序消息发送到同一个队列中。
关键点：
同一个业务ID的消息永远进入同一个队列
队列内消息严格FIFO（先进先出）
不同业务ID的消息可以进入不同队列，并行处理
3.2 消费顺序性
消费者使通过顺序消费模式，从同一个消息队列中串行拉取和处理消息。
重试限制
顺序消息的重试次数是有限的（默认16次），超过后:
失败16次 → 跳过该消息 → 继续消费后续消息
跳过的消息不会进入死信队列，会永久丢失！
并发消费 vs 顺序消费
| 对比项 | 并发消费 | 顺序消费 |
|---|---|---|
| 监听器 | MessageListenerConcurrently | MessageListenerOrderly |
| 拉取粒度 | 一次拉取多批，并行处理 | 一次拉取一批，串行处理 |
| 队列锁 | 无 | 有（队列级别锁） |
| 吞吐量 | 高 | 低（约并发消费的30%~50%） |
| 适用场景 | 无顺序要求的普通消息 | 有顺序要求的业务消息 |
四、MQ如何快速处理积压的消息？
80%的积压问题在消费端，要提升消费速度。
核心限制：同一个MessageQueue最多只能被一个消费者消费，因此消费者实例数 <= 队列数。
| 方式 | 原理 | 有效条件 | 效果 | 限制 |
|---|---|---|---|---|
| 增加消费者实例 | 更多实例分摊队列 | 实例数 ≤ 队列数 | 线性提升 | 队列数不够时无效 |
| 增加消费线程 | 单实例内并行处理 | 单实例处理能力有余量 | 提升单机吞吐 | 受CPU/IO限制 |
| 增加队列数 | 扩大可分配队列池 | 需新建Topic或动态扩容 | 突破实例数上限 | 4.x需重建Topic，5.x支持动态 |
消费者实例数 > 队列数 → 多余实例空闲，不分配任何队列
顺序消息场景：增加队列会破坏原有取模路由，消息可能进错队列 →顺序被打破
普通消息场景：可安全操作，Rebalance 会自动调整
处理积压的最优路径：先加实例（队列有余量）→ 再加线程（单机有余量）→ 最后加队列（突破上限）。