springboot-rocketmq整合NOT_CONSUME_YET问题处理

一、测试流程

1.添加POM

    <dependency>
      <groupId>org.apache.rocketmq</groupId>
      <artifactId>rocketmq-spring-boot-starter</artifactId>
        <version>2.2.1</version>
    </dependency>

2.配置属性参数

# 默认的消息组
rocketmq.producer.group=springBootProduceGroup
rocketmq.consumer.topic=DEVICE_CENTER_MSG_DEV
rocketmq.consumer.group=springBootConsumeGroup33

3.添加监听代码

@Service
@RocketMQMessageListener(topic = "${rocketmq.consumer.topic}",consumerGroup ="${rocketmq.consumer.group}",
        selectorExpression = "*",maxReconsumeTimes=2)
public class MsgRecvServiceImpl implements RocketMQListener<MessageExt>, RocketMQPushConsumerLifecycleListener {


    @Override
    public void onMessage(MessageExt messageExt) {
        System.out.printf("messageExt: %s,body:%s \n",messageExt,new String(messageExt.getBody()));
    }

    @Override
    public void prepareStart(DefaultMQPushConsumer consumer) {
        consumer.setConsumeThreadMin(8);
        consumer.setConsumeThreadMax(32);
        consumer.setPullBatchSize(32);

//        consumer.setInstanceName("10.6.33.23@10.6.14.3:9876@33404");

       // consumer.setAllocateMessageQueueStrategy(new );
        System.out.printf(" consumer:%s \n",consumer);
    }
}

二、测试现象

1.问题描述

监听者有时收不到消息。

然后查看消费组配置

发现此主题有4个队列,但是有两个队列没有消息客户端订阅。

三、原因分析

1.原因详细分析

查看消费端负载均衡策略,看到本进程竟然有两个CID客户端在订阅这个TOPIC.

然后我们重启服务,在生成消费客户端实例名的函数断点。

可以看到在自动配置时创建了一个默认的PullConsumer

然后在创建自定义的监听实例时也实例了一个DefaultMQPushConsumer

2.原因总结

是由于springboot-rocketmq-start自动配置里面创建了一个默认的CONSUMER,导致生成了两个CONSUMER,

3.解决方案

因为自动配置是根据rocketmq.consumer.topic,rocketmq.consumer.group来生成的,所以只要在配置文件修改这两个属性的命名即可。

# NameServer地址
rocketmq.name-server=10.6.14.3:9876
# 默认的消息组
rocketmq.producer.group=springBootProduceGroup
rocketmq.device_center_dev_consumer.topic=DEVICE_CENTER_MSG_DEV
rocketmq.device_center_dev_consumer.group=springBootConsumeGroup33

修改完后,消费端负载均衡只找到了一个消费端,

然后查看ROCKETMQ控制台,这个消费客户端也同时消费了4个队列的数据,接收数据正常。

查看消息消费状态,也正常

程序也收到了消息

### RocketMQNOT_CONSUME_YET 消息状态的原因分析 在 RocketMQ 中,`NOT_CONSUME_YET` 表示当前消息暂时无法被消费。这通常发生在消费者接收到消息后认为现在不是合适的时机来处理该消息的情况。 #### 可能原因 1. **时间依赖型任务** 如果消费者的逻辑依赖于特定的时间条件,在这些条件下尚未满足时,可能会返回 `NOT_CONSUME_YET` 来推迟实际的消息处理[^3]。 2. **资源不可用** 当某些外部服务或数据库连接等必要资源暂时不可访问时,为了防止错误发生并保持系统的稳定性,可以选择延迟消息的执行直到资源恢复可用性[^4]。 3. **业务流程控制** 对于一些复杂的业务场景来说,可能需要等待其他前置操作完成之后才能继续下一步骤;此时也可以利用此机制让消息稍后再尝试消费[^5]。 ### 处理方法与最佳实践 针对上述提到的各种情况,可以采取如下措施: - #### 调整 Consumer 配置 确认应用程序中是否存在多个不必要的消费者实例正在运行。例如,在 Spring Boot 应用程序里,默认情况下会启动一个额外的标准消费者,这可能导致重复订阅相同主题的问题。可以通过自定义配置文件禁用默认行为或将两者合并成单一实例以避免冲突。 - #### 实现合理的重试策略 使用 RocketMQ 提供的状态码如 `SUSPEND_CURRENT_QUEUE_A_MOMENT` 或者设置最大允许重试次数等方式来实现更加灵活可控的消息重试机制。对于那些确实不应该立即重新投递给同一队列中的情形,则应考虑将其标记为成功以便后续单独处理[^2]。 - #### 日志记录和监控报警 加强日志输出力度以及引入实时性能指标跟踪工具可以帮助快速定位潜在问题所在,并及时作出响应调整。特别是关注异常状态下(比如 `NOT_CONSUME_YET`)的日志信息,有助于深入理解具体原因并优化相应部分的功能设计[^1]。 ```java // Java 示例代码展示如何正确处理 NOT_CONSUME_YET 场景 public class MyMessageListener implements MessageListenerConcurrently { @Override public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) { try { // Your business logic here... if (shouldNotProcessNow()) { System.out.println("Current message will be consumed later."); return ConsumeConcurrentlyStatus.NOT_CONSUME_YET; } // Process successfully. return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; } catch (Exception e) { logger.error("Failed to process messages.", e); return ConsumeConcurrentlyStatus.RECONSUME_LATER; // Or RECONSUME_SUCCESS depends on your needs. } } private boolean shouldNotProcessNow() { // Implement the condition check that determines whether now is a good time to proceed with processing. return false; } } ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值