【RocketMQ】消息积压判断及解决

一. 定位问题

1. Console入口

主题-->Topic-->Consumer管理-->订阅组

在这里插入图片描述

2. 延迟数量(Delay)

消息积压数量,即当前Topic还剩下多少消息未处理,该值越大,表示积压的消息越多

3. 最后消费时间(LastConsumeTime)

当前Topic消息最后被消费的时间,该值表示消费端有多长时间未拉取消息进行消费

二. 分析问题

1. 查看rocketmq_client.log日志

grep "do flow control" rocketmq_client.log

如果出现 so do flow control 这样的日志,说明触发了消费限流,原因是:消费端积压了消息,即消费端无法消费已拉取的消息,消费端在没有将消息处理完成前,不会再向服务端拉取消息,并打印日志。

2. 消费端业务逻辑

1. 执行了长耗时的逻辑,导致消息处理很慢
2. 第三方接口调用很慢或超时

三. 解决问题

1. 消费端解决

1. 增加消费端的消费线程数或增加消费者数量,提升消费能力
2. 优化代码逻辑,降低执行时间
3. 调用第三方接口时,设置较短的超时时间,避免长时间等待,快速返回错误信息并告警

posted @     阅读(2546)  评论(0编辑  收藏  举报
编辑推荐:
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
阅读排行:
· 单线程的Redis速度为什么快?
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 展开说说关于C#中ORM框架的用法!
· SQL Server 2025 AI相关能力初探
· Pantheons:用 TypeScript 打造主流大模型对话的一站式集成库
历史上的今天:
2015-09-23 Linq To Sql的各种查询
2011-09-23 PL/Sql 中创建、调试、调用存储过程
点击右上角即可分享
微信分享提示