异常点（MQ-消息堆积-对于这个异常点）

背景介绍

研发过程中，我们比较注重业务逻辑的设计实现，对于一些异常点往往缺少处理和监控，加上线上环境的复杂性就会造成一些意想不到的故障。

相比于前面两篇消息堆积【MQ-消息堆积-一条SQL阻塞了整个服务线程案例分析】【MQ-消息堆积-JDK Bug导致线程阻塞案例分析】的场景，这篇文章中的场景在我们研发中往往更加普遍一些。

期望对友友们有所帮助，写的可以友友们动动小手点赞、关注，写得不好欢迎评论区指正讨论，感谢友友们的支持。

问题现象

图1 消费者状态

图1中每个Consumer实例的消息堆积量处于正常范围，总体【实时消息堆积量】是13053623则属于异常范围，接下来我们看一下每个Consumer实例的【详细信息】。

分析过程

consumer详细信息

图2 详细信息

图2中【消息失败（条/秒）】是162.52，正常情况下这个数字应该为0。

这种情况通常是两个原因造成的：

业务中有未捕获的异常，导致异常抛到了MQ client框架层业务中捕获了异常当消费顺序消息的时候，返回了：ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT当消费并发消息的时候，返回了：ConsumeConcurrentlyStatus.RECONSUME_LATER

此时我们应该：

检查业务日志是否有异常信息：有则进行异常信息分析没有异常信息，说明业务逻辑没有捕获到相应的异常（业务逻辑需要完善），则需要查看MQ相关日志进行排查。

检查Consumer实例上的MQ日志

日志路径：~/logs/ons.log

过滤关键字：error、fail、exception

图3 异常日志

到此可以定位业务具体异常信息了，根据异常进行业务代码的修复。

解决办法

在消息入口处，一定要catch住所有预期及未预期的异常，并做好异常日志监控报警。

延申阅读

云产品MQ-Broker消息堆积情况

为了进一步确认MQ-Broker上消息堆积情况，可以在MQ-Broker的docker中执行：

sh /home/admin/rmq/bin/mqadmin consumerprogress -t $topic -g $gid

RocketMQ mqadmin消费相关命令

名称

含义

命令选项

说明

consumerProgress

查看订阅组消费状态，可以查看具体的client IP的消息积累量。

-g

消费者所属组名

-s

是否打印client IP

-h

打印帮助

-n

NameServer 服务地址，格式 ip:port

consumerStatus

查看消费者状态，包括同一个分组中是否都是相同的订阅，分析Process Queue是否堆积，返回消费者jstack结果，内容较多，使用者参见ConsumerStatusSubCommand

-h

打印帮助

-n

NameServer 服务地址，格式 ip:port

-g

consumer group

-i

clientId

-s

是否执行jstack

getConsumerStatus

获取 Consumer 消费进度

-g

消费者所属组名

-t

查询主题

-i

Consumer 客户端 ip

-n

NameServer 服务地址，格式 ip:port

-h

打印帮助

updateSubGroup

更新或创建订阅关系

-n

NameServer 服务地址，格式 ip:port

-h

打印帮助

-b

Broker地址

-c

集群名称

-g

消费者分组名称

-s

分组是否允许消费

-m

是否从最小offset开始消费

-d

是否是广播模式

-q

重试队列数量

-r

最大重试次数

-i

当slaveReadEnable开启时有效，且还未达到从slave消费时建议从哪个BrokerId消费，可以配置备机id，主动从备机消费

-w

如果Broker建议从slave消费，配置决定从哪个slave消费，配置BrokerId，例如1

-a

当消费者数量变化时是否通知其他消费者负载均衡

deleteSubGroup

从Broker删除订阅关系

-n

NameServer 服务地址，格式 ip:port

-h

打印帮助

-b

Broker地址

-c

集群名称

-g

消费者分组名称

cloneGroupOffset

在目标群组中使用源群组的offset

-n

NameServer 服务地址，格式 ip:port

-h

打印帮助

-s

源消费者组

-d

目标消费者组

-t

topic名称

-o

暂未使用