RocketMQ 消费组在 K8s 扩缩容时 rebalance 窗口内 offset 回退导致重复消费，如何把重复率压到 0.1% 以内

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载「订单状态变更 → 推送下游营销/风控」链路：topic order-status 32 个 queue，消费组 6 实例（K8s Deployment，1 副本 = 1 实例），日均约 8000 万条，P99 单条处理 120ms（主要是 2 次下游 HTTP 调用）。消费模式是 MessageListenerConcurrently，默认拉取。

【现象】 每次 HPA 触发扩缩容（通常 1~2 个 Pod 变更）后 10 分钟内，下游会收到一批重复事件，按 msgId 去重统计，重复率约 0.3%~0.8%。我们抓到一个具体 case：缩容时旧 Pod 被 SIGTERM，优雅退出期间它仍在拉取并处理消息，但它的 offset commit 与新接管实例的 commit 存在竞态，broker 上该 queue 的 consumerOffset 被回退了几百条，新实例重投后旧 Pod 已经处理过的那段被二次处理。另外观察到 rebalance 前后 PullMessage 日志里同一 queueId 短时间内出现两个 clientId 在拉取。

【已尝试的排查与结果】

1. 把 Pod 的 terminationGracePeriodSeconds 从 30s 调到 120s，并在 preStop 里 sleep 15s，重复率从 0.8% 降到 0.3%，没有根治；
2. 消费端用 Redis SETNX(msgId, 24h) 做幂等，重复率降到 0.05%，但 Redis 压力涨了 35%，且 24h 窗口外仍有极少量漏网；
3. 调小 consumeConcurrentlyMaxSpan（默认 2000）到 500，影响不明显；
4. 看了 broker 侧 consumerOffset.json 的更新时间戳，确认回退确实发生在两个实例 commit 交错的时间点。

【期望得到的答案形态】

1. 从 RocketMQ 客户端源码角度，rebalance 时「旧实例还在拉取 + 新实例已接管 + 两边各自 commit」的竞态窗口具体由哪些参数和时序决定（rebalance 周期、commit 周期、broker 端 offset 存储）？
2. 有没有不改业务代码、只调参数/部署策略就能把窗口压到可忽略的方案？比如 rebalance 时强制旧实例先 suspend 拉取再退出的做法是否可行、怎么实现？
3. 幂等方案上，Redis SETNX、本地 DB 唯一键、以及「消费端本地 offset 文件 + commit 前校验」各自在 8000 万/日量级下的成本和踩坑点？
4. 如果接受用「顺序消费 MessageListenerOrderly」来换掉并发消费，在 32 queue / 6 实例的规模下吞吐和延迟大概会怎么变？有没有量化过的经验值？

欢迎带版本号和具体配置来答，数字比结论更有用。