rocketmq的消息重试与死信处理需按业务定制：支付类设5–8次、日志类用默认16次、通知类设3–5次；重试间隔为1–18级阶梯延迟，非固定秒数；dlq需显式订阅处理，且仅集群模式支持重试。
RocketMQ 的消息重试与死信处理不是“开箱即用就高枕无忧”的功能，而是需要结合业务场景主动设计的可靠性保障链路。默认 16 次重试和自动转入 DLQ 的行为，若不加干预，容易掩盖真实问题，甚至引发资源耗尽或监控盲区。
重试次数要按业务类型设，不能全用默认值
16 次是通用兜底值，但不同业务对失败容忍度差异极大：
- 支付类消息：建议设为 5–8 次（总耗时约 10–15 分钟），避免长时间占用队列资源，也给下游服务留出恢复窗口
- 日志/埋点类消息：可保留默认 16 次，这类消息价值密度低、时效性弱，重试成本小
- 实时通知（如短信、IM）：建议 3–5 次，优先保障首条触达，失败后应快速降级或走备用通道
配置方式有两种：
- 客户端代码：consumer.setMaxReconsumeTimes(5)
- YAML 配置：rocketmq.consumer.max-reconsume-times: 5
注意：修改后需同步评估死信堆积速率，避免 DLQ 突然暴增却无告警。
重试间隔不是固定值，而是延迟等级映射
RocketMQ 不直接配置“秒数”，而是通过 delayLevelWhenNextConsume 指定延迟等级（1–18），每个等级对应预设时间，例如：
- 等级 3 → 10 秒，等级 4 → 30 秒，等级 5 → 1 分钟
- 第 13–16 次重试统一使用等级 18 → 2 小时
这意味着：重试不是线性拉长，而是阶梯式跃升。前几次快速响应瞬时故障，后期大幅放缓，防止压垮已异常的服务。
若需自定义节奏（如避开大促高峰），可通过实现 RetryPolicy 接口注入指数退避逻辑，而非硬改 Broker 配置。
死信队列不是“垃圾桶”，而是人工介入入口
消息进入 %DLQ%ConsumerGroup 后，不会被普通消费者自动拉取，必须显式订阅才能处理：
- Topic 名固定为 %DLQ%+消费者组名，例如 %DLQ%pay-consumer-group
- 需单独创建消费者组（如 dlq-pay-handler），避免与主链路共用资源
- 死信消息保留时间默认与普通消息一致（如 3 天），建议在 broker.conf 中为 DLQ Topic 单独设置 deleteTopic=on 或缩短 fileReservedTime
关键动作不是“立刻重发”，而是先做三件事：
- 解析消息体，检查是否因 JSON 字段缺失、时间戳格式错误等可修复问题导致失败
- 核对 Message ID 和 Reconsume Times，确认是否真为终态失败（排除偶发网络抖动）
- 记录到问题工单系统，标记来源消费者组、原始 Topic、失败堆栈（如有）
集群消费模式是重试前提，广播模式不重试
这是常被忽略的基础约束：
- 只有 集群消费（Clustering） 模式下，Broker 才会将失败消息投递到 %RETRY%Topic 并执行重试逻辑
- 广播消费（Broadcasting） 模式下，消息失败即丢弃，不进重试队列，也不进 DLQ
验证方式：查看消费者启动日志中是否出现 register consumer group 后带 clustering 标识；代码中确认是否调用 consumer.setMessageModel(MessageModel.CLUSTERING)。
若误配为广播模式，所有失败都将静默丢失，监控上只看到消费成功率骤降，却查不到重试或 DLQ 流量。
