RocketMq tag动态设置失效问题

问题:Springboot整合RocketMQ后动态tag设置失效!(最新版本已经解决此问题)

依赖:

<!--    rocketMQ    -->
        <dependency>
            <groupId>org.apache.rocketmq</groupId>
            <artifactId>rocketmq-spring-boot-starter</artifactId>
            <version>2.0.3</version>
        </dependency>

写法:

@Slf4j
@Component
@RocketMQMessageListener(nameServer = "${rocketmq.payment.nameServer}", topic = "${rocketmq.payment.refund.topic}",consumerGroup = "${rocketmq.payment.refund.groupName}"
        ,consumeMode = ConsumeMode.ORDERLY, selectorExpression = "${rocketmq.payment.refund.tag}")
public class RunfundUpdateListener implements RocketMQListener<String> {

    
    @Override
    public void onMessage(String message) {

        log.info("into#class:{}, mesasage:{}", "RunfundUpdateListener", message);
       
    }

排查:RocketMQMessageListener生效的类为:ListenerContainerConfiguration 

@Configuration
public class ListenerContainerConfiguration implements ApplicationContextAware, SmartInitializingSingleton {
    private final static Logger log = LoggerFactory.getLogger(ListenerContainerConfiguration.class);

    private ConfigurableApplicationContext applicationContext;

    private AtomicLong counter = new AtomicLong(0);

    private StandardEnvironment environment;

    private RocketMQProperties rocketMQProperties;

    private ObjectMapper objectMapper;

    public ListenerContainerConfiguration(ObjectMapper rocketMQMessageObjectMapper,
        StandardEnvironment environment,
        RocketMQProperties rocketMQProperties) {
        this.objectMapper =
### RocketMQ 常见问题及解决方法 #### 一、消息幂等问题 在分布式系统中,由于网络抖动或其他异常情况可能导致消息重复发送或多次消费。为了应对这一问题,通常需要实现消费幂等。 - **什么是消费幂等** 消费幂等是指同一条消息无论被消费多少次,其最终的结果是一致的[^3]。 - **消息重复的场景分析** - 发送时消息重复:在网络不稳定的情况下,可能会导致消息重复发送[^3]。 - 消费时消息重复:消费者在处理过程中可能出现异常中断,重新拉取消息后再次消费。 - Rebalance时消息重复:当消费者组成员发生变化时,可能引发消息重复分配和消费[^3]。 - **通用解决方案** 实现消费幂等的关键在于两个要素:幂等令牌与唯一性处理逻辑[^3]。通过记录已消费过的消息ID或者业务流水号等方式,确保同一消息不会被执行两次操作。 --- #### 二、消息堆积问题 消息堆积通常是由于生产速度快于消费速度造成的。以下是常见的原因及其优化措施: - **产生原因分析** - 消息拉取效率低下:可能是由于网络带宽不足或客户端配置不合理所致[^2]。 - 消息消费耗时过长:某些复杂业务逻辑增加了单条消息的平均处理时间[^2]。 - 消费并发度过低:默认情况下消费者的线程池大小有限制,无法充分利用硬件资源。 - **如何避免消息堆积和消费延迟** - 提高消费能力:增加消费者的实例数量以分摊负载;调整`consumeThreadMin` 和 `consumeThreadMax` 参数来动态扩展消费线程数[^4]。 - 调优业务逻辑:减少每条消息的实际执行开销,比如批量提交数据库更新而不是逐条写入[^4]。 - 设置合理的超时机制:对于长时间未完成的任务可以主动放弃并放入死信队列进一步排查[^4]。 --- #### 三、消息清理问题 随着时间推移,存储空间会被大量历史数据占据。因此定期清除陈旧无用的数据成为必要之举。 - Broker提供了TTL(Time To Live)参数用于定义消息存活期限,超过该时间段后的消息将会自动删除[^3]。 --- #### 四、消息过滤问题 根据具体需求筛选感兴趣的内容有助于降低不必要的传输成本。 - **Tag方式过滤**: 使用标签标记不同类型的消息,在订阅阶段指定感兴趣的tag即可达到目的。 - **SQL表达式过滤**: 支持基于属性字段构建复杂的条件语句来进行精确匹配。 示例代码展示两种不同类型的过滤器应用: ```java // Tag 过滤 DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("example_group"); consumer.subscribe("TopicTest", "TagA || TagB"); // SQL 表达式过滤 consumer.subscribe("TopicTest", "price >= 5 AND city='Beijing'"); ``` --- #### 五、消息重试问题 无论是因为瞬态错误还是永久失效都需要有相应的恢复手段保障服务质量。 - 对于普通的乱序消息,默认支持最多16次指数退避式的再尝试机会[^2]; - 如果涉及严格的因果关系维护则需启用有序模式下的特别策略——一旦发现失败即暂停后续项直到当前障碍解除为止[^2]。 特殊情况如超出最大允许范围仍未成功,则转入专门设立的DLQ(Dead Letter Queue)[^4]供人工介入审查。 --- #### 六、如何保证消息不丢失 这是衡量一款中间件产品成熟度的重要指标之一。 - Producer层面可通过开启事务特性确认投递状态后再做下一步动作; - Consumer方面除了常规的心跳检测外还应周期性的向远程汇报进度以防万一中途崩溃遗漏部分已完成的工作成果[^5]。 ---
评论 3
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值