背景

收到开发人员反馈，延迟30s的消息，到时间还没有正常被消费，于是登陆到broker节点上去查看日志，有个ERROR级别的报错：

#vim  rocketmq-log/stats.log
ScheduleMessageService, a message time up, but reput it failed, topic: SCHEDULE_TOPIC_XXXX msgId 016F513245602A9F00904695B4CF4074

报错内容的提示消息体大小超过64K，导致30s刻度的延迟消息全都卡住了，通过报错的内容，拿SCHEDULE_TOPIC_XXXX和msgid去broker节点上消息检索，得到的消息大小为65k，以及偏移量

RocketMQ手动跳过延迟消息offset_延迟消息跳过offset

SCHEDULE_TOPIC_XXXX为延迟消息的内置topic，msgid为内置topic发送的msgid并非原topic的msgid

注：对于普通消息、顺序消息和延迟消息，RocketMQ的消息大小限制分别为4MB、4MB和64KB


解决方法


 禁止broker节点的消息写入

bin/mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.x.x:9876 -k brokerPermission -v 4

通过控制台查看此broker节点的intps，等待intps为0后，开始操作

关闭broker节点服务

#bin/mqshutdown broker

修改延迟消息的offset值 

根据消息检索查来的offset值及延迟30s的刻度，为4:7719226366，此文件为延迟消息18个刻度的offset对应的列表值

#备份delayOffset.json文件

#vim delayOffset.json
{
	"offsetTable":{1:91625937,2:2061777241,3:201533923,4:7719226366,5:182055943,6:49920923,7:632285234,8:42647772,9:192776111,10:24531702,11:21768583,12:31576379,13:16927368,14:61560066,15:30910937,16:42416890,17:44778445,18:43648973
	}
}

修改4:7719226367，跳过4:7719226366这条消息体大小为65k的消息。保存退出。

启动broker节点服务

# nohup bin/mqbroker -c /安装目录/xxx.properties &

当broekr节点服务启动后，积压在30s刻度的消息都会全部被成功投递，等待InTps为0时，

开启broker节点的写权限

bin/mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.x.x:9876 -k brokerPermission -v 6


最后检查

通过msgid去broker节点上消息检索，此前延迟30s没有被正常消费，查到的结果为被消费者正常消费完了。

bin/mqadmin queryMsgById -n 192.168.x.x:9876  -i 0A85BBBD0001764C12B61BE1C862827B