RocketMQ 事务消息半消息长期未提交、堆积告警，如何区分是回查卡住还是消费侧问题

【背景】 我们用 RocketMQ 4.9（3 节点集群）承载订单扣减库存这条关键链路，采用事务消息保证「扣库存」与「发通知」的最终一致。本地事务执行成功后会 commit，失败/超时则回滚；Broker 侧配置了 transactionCheckInterval=60s、transactionCheckMax=15，回查接口走本地事务状态表查询。

【现象】 近两周出现 3 次半消息（half message）堆积告警，单次峰值约 3000 条，持续 5~10 分钟后自行恢复，期间没有明显流量尖峰，CPU/内存/网络都正常。堆积时 commit 消息的发送成功率反而正常，说明本地事务大多是成功的，但「提交确认」这一步迟迟没落到 Broker。

【已尝试的排查与结果】

1. 看了 Broker 日志，transactionChecker 线程在堆积时段有频繁的「check message」打印，但对应回查结果多为 COMMITTED，说明状态表里其实已经是提交态；
2. 给回查接口加了耗时监控，发现堆积时段回查 P99 从 2ms 飙到 800ms+，疑似本地状态表查询或锁等待；
3. 怀疑是 commit 的 RPC 超时被吞，但 Producer 端没看到明显的 send timeout 日志。

【期望得到的答案形态】 希望有踩过类似坑的同学帮忙拆解：

• 半消息堆积到底该从哪条链路切入定位（Producer 提交 RPC / 回查线程 / Broker 事务表）？有哪些关键日志字段和指标能直接区分「回查慢」还是「commit 确认丢失」？
• 回查 P99 飙高时，本地状态表查询/锁等待是常见根因吗？你们的事务状态表是怎么建模的（单表 + 唯一键？还是引入了额外的状态机字段）？
• 有没有推荐的告警阈值和兜底策略（比如回查超时后是否要主动补偿 commit），避免靠 60s 轮询硬扛？