rocketmq消费端抛自定义异常不直接触发重试，关键在于显式返回consumeconcurrentlystatus.reconsume_later或success；重试次数由broker端maxreconsumetimes配置（默认16次），延迟级别由messagedelaylevel决定，手动发送延迟消息可绕过默认机制。
RocketMQ 消费端抛出自定义 Exception 时，默认会触发重试机制，但重试行为受两个关键因素控制：消费者返回状态（ConsumeConcurrentlyStatus 或 ConsumeOrderlyStatus）以及 Broker 端配置的重试策略。单纯抛异常本身不直接决定重试次数和延迟级别，真正起作用的是消费逻辑返回的状态 + 消费者组的重试配置。
1. 明确消费返回状态才是重试控制的关键
RocketMQ 的并发/顺序消费方法（如 ConsumeMessageService#processConsumeResult）只识别你返回的消费结果状态，而不是你抛了什么异常。即使抛出自定义 Exception，只要你在 catch 块中显式返回 ConsumeConcurrentlyStatus.CONSUME_SUCCESS，就不会重试；反之，若返回 ConsumeConcurrentlyStatus.RECONSUME_LATER（或未捕获异常导致方法异常退出），则进入重试流程。
- 推荐始终显式返回状态，避免依赖未捕获异常的隐式行为
- 自定义 Exception 应在 catch 中处理，并根据业务意图决定返回 SUCCESS 还是 RECONSUME_LATER
- 例如：不要直接 throw new BizException("库存不足")，而应：
try {
// 处理消息
} catch (BizException e) {
log.warn("业务异常，稍后重试", e);
return ConsumeConcurrentlyStatus.RECONSUME_LATER;
}
2. 控制重试次数：靠消费者组（Consumer Group）配置
RocketMQ 的最大重试次数由 Broker 端为每个消费者组统一配置，**不是在消费者代码里设置**。默认值为 16 次（从第 0 次开始算，共尝试 17 次）。超过该次数后，消息将被投递到死信队列（DLQ）。
- 修改方式：在 Broker 配置文件（
broker.conf）中设置maxReconsumeTimes=8（例如设为 8 表示最多重试 8 次，加首次共 9 次） - 重启 Broker 生效，且对所有使用该 Group 的消费者生效
- 注意：客户端 SDK 无法覆盖此值，
DefaultMQPushConsumer#setRetryTimesWhenBroadcast()仅对广播模式生效，且不适用于普通集群消费
3. 控制延迟级别：靠消息重试时的延时等级（delayLevelWhenNextConsume）
当返回 RECONSUME_LATER 时，RocketMQ 会将消息重新写入一个特殊重试主题（%RETRY%{consumerGroup}），并按“延迟级别”设定下次投递时间。这个延迟级别由 Broker 的 messageDelayLevel 参数决定。
- Broker 默认配置：
messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h - 第 1 次重试 → 延迟等级 1（1s），第 2 次 → 等级 2（5s），…… 第 16 次 → 等级 16（30m），第 17 次（超限）→ 进入死信队列
- 可通过修改
broker.conf中的messageDelayLevel自定义各级延迟时间（需重启 Broker） - 消费者端无法为单条消息指定具体延迟等级，只能通过返回
RECONSUME_LATER触发自动逐级递增
4. 进阶：手动控制延迟（绕过默认等级）
如果需要更灵活的延迟（比如固定延迟 10 分钟、或基于异常类型动态定延迟），可放弃自动重试，改用“发送延迟消息回原主题”的方式：
- catch 异常后，不返回
RECONSUME_LATER，而是构造一条新消息，设置message.setDelayTimeLevel(x)（x 对应 delayLevel 中的序号，如 18 表示 2h） - 用同一 Producer 将该消息发回原 Topic（注意避免重复消费逻辑无限循环）
- 需自行保障幂等性，且该消息不再走重试队列，完全由你控制投递时机
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
