RocketMQ消费接口设计实战：为什么HTTP回调接口必须吞掉所有异常，始终返回成功？

问题背景

昨天遇到一个生产问题，日志里刷了几千条重复消息，排查下来是个典型的设计坑------记录一下，给自己也给遇到同类问题的人一个参考。

问题是怎么触发的

某教育系统里，有个接口专门接收三方推送的日程数据。接口用的是标准 Spring MVC 写法：

java 复制代码

@RequestMapping("/v1/mq/third")
public GlobalResponse mqThird(@RequestBody CalendarThirdMqDTO dto) throws Exception {
    calendarThirdMqConsumerService.consumerMessage(dto);
    return GlobalResponse.success(null);
}

看起来没问题，但有一天，三方推送的数据里 alarmTypes 字段为空，业务逻辑执行到 dto.getAlarmTypes().split(",") 时抛了 NPE。

NPE 本身不可怕，可怕的是它之后发生的事：

异常冒泡到全局 ExceptionHandler，返回 HTTP 400
对接方的 MQ 消费者收到 400，判定"这次推送失败了"
按照重试策略继续推同一条消息
同样的数据再次触发同样的 NPE
循环往复，消息永远消不掉

为什么这个设计是错的

这里有个认知误区：觉得"接口返回失败码"是诚实的表现，告诉对方"我没处理成功"。

但对于 MQ 消费场景，这个"诚实"代价极高。消息队列的重试机制是框架级的保障，目的是应对临时性故障（网络抖动、下游短暂不可用）。如果是业务数据本身有问题，重试再多次也没用，只会不停地消耗资源。

正确写法（Spring Boot + RocketMQ HTTP 模式）

java 复制代码

@RequestMapping("/v1/mq/third")
public GlobalResponse mqThird(HttpServletRequest request) {
    String rawBody = null;
    try {
        rawBody = StreamUtils.copyToString(request.getInputStream(), StandardCharsets.UTF_8);
        CalendarThirdMqDTO dto = objectMapper.readValue(rawBody, CalendarThirdMqDTO.class);
        calendarThirdMqConsumerService.consumerMessage(dto);
    } catch (Exception e) {
        // 消费失败只记日志，不向上抛出
        log.error("[mqThird] 消费失败, rawBody={}", rawBody, e);
    }
    return GlobalResponse.success(null);  // 始终返回成功
}

关键点：

用 HttpServletRequest 手动读体，避免 @RequestBody 反序列化失败时直接报 400
try-catch 包裹全部消费逻辑
失败时记完整 ERROR 日志（原始报文 + 堆栈），方便后续排查
无论成败，始终返回成功，让消息框架确认消息、停止重试

配套的数据修复

修复代码之后，还要处理 Bug 期间写入的脏数据：

sql 复制代码

-- 清理 alarm_types 为 null 的存量记录
UPDATE zhgl_zx_calendar_calendar SET alarm_types = '0' WHERE alarm_types IS NULL;

别忘了这一步，否则存量脏数据还会触发同样的 NPE。

设计铁律总结

MQ 消费接口里，所有异常都应该在消费者内部消化，不要让消息框架感知到失败。

真正需要重试的逻辑（如下游服务临时不可用），交给死信队列和人工运营处理，而不是依赖框架的自动重试把同一条坏数据无限刷。

适用场景：

RocketMQ HTTP 消费模式
Webhook 回调接口
钉钉/飞书事件推送接口
任何"外部系统主动推送"的 HTTP 接口

更多 Java 中间件实战内容，欢迎关注「Java转AI实战内参」知识星球。