RocketMQ 顺序消费（MessageListenerOrderly）单条慢消息阻塞整队列，如何快速定位到具体 queueId 和 msgId

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载支付清结算的状态机流转：topic settle-state，16 个 queue，消费组 4 实例，使用 MessageListenerOrderly 保证同一笔结算单内严格顺序。下游是 MySQL 8.0（一主两从）+ 一次 Redis 写 + 一次外部风控 HTTP 调用（P99 约 350ms，偶发 8s 以上超时）。

【现象】 过去两周出现 3 次「顺序消费整体停摆」：表现为该消费组 lag 从 0~30 一路涨到 50 万+，且所有 16 个 queue 同时出现 lag（不是某一个 queue 慢），消费侧线程全部卡在 MessageListenerOrderly#consumeMessage 内部的 synchronized（看 jstack 能确认），业务上结算单状态停滞 40~90 分钟，最终靠重启消费实例恢复。

【已尝试的排查与结果】

1. 控制台看 lag：只能看到 group 级别的总 lag 和各 queue 的 offset，但看不出是哪个 queue 在卡、卡在哪条消息；
2. jstack 抓 3 次：线程都停在 MessageListenerOrderly 的锁上，但锁对象是 per-queue 的 ConcurrentHashMap，没法从堆栈直接读出 queueId 和 msgId；
3. broker 侧 mqadmin：用 consumerProgress 能看到每个 queue 的 consumerOffset / brokerOffset，但卡住时所有 queue 都「落后」，无法区分「谁是根因 queue、谁是被动阻塞」；
4. 怀疑是外部风控 HTTP 偶发 8s 超时 + 没有超时中断机制，把单条消息的锁持有时间拉到了分钟级，但无法证明。

【期望得到的答案形态】

1. 一套可复现的定位命令序列：如何从 brokerOffset / consumerOffset / queryMsgById / consumerProgress 里，在不停机的前提下锁定「根因 queueId + 卡住的那条 msgId」？
2. 如何确认是「单条消息处理慢」而非「rebalance / 网络抖动 / GC」导致的整体停摆？（比如 broker 端 consumeTimeSpan 怎么查？）
3. 有没有在 MessageListenerOrderly 里加「单条消息处理超时熔断 + 告警」的轻量做法，不破坏顺序语义？（比如 Future.get 超时、或把外部调用挪到消息外？）
4. 16 queue / 4 实例这种 1:4 的部署，顺序消费场景下是否合理？还是应该 1:1？