K8s 缩容 1 个 Kafka 消费者实例时，cooperative 分配器的分区交接窗口如何量化与压低

【背景】 我们的对账服务用 Kafka 3.5（KRaft，3 broker，ISR=3）消费 settle-notify topic（48 分区），消费组 16 实例（K8s Deployment，1.29，maxUnavailable=1 / maxSurge=1），assignor 已从 eager 切到 org.apache.kafka.clients.consumer.CooperativeStickyAssignor。峰值约 8000 msg/s，单条消费链路含一次 gRPC 下游调用（P99 80ms）+ 一次 MySQL 写入（P99 40ms）。

【现象】 每次发布或 HPA 缩容时，被驱逐 pod 上的 3 个分区（48/16≈3）要等到剩余实例重新分配后才由新 owner 拉取，实测"分区最后一条旧 owner 写入 → 新 owner 第一条写入"之间有 900ms~1.6s 的静默窗口（用消费侧埋点 + offset 跳变检测出的）。窗口内该分区的 lag 在 broker 视角不涨（生产者在持续写），但下游对账任务出现最多 1 条的乱序感知，触发告警。

【已尝试与结果】

1. 把 session.timeout.ms 从 45s 调到 10s、heartbeat.interval.ms 从 5s 调到 3s：rebalance 触发更快，但窗口只缩了约 100ms，瓶颈不在心跳超时；
2. onPartitionsRevoked 里显式 commitSync()：窗口再缩约 50ms，但偶发 CommitFailedException（pod 被 SIGKILL 时 RPC 来不及回包）；
3. HPA 缩容改走 kubectl scale 而非直接 delete pod：行为一致，没有差别；
4. 怀疑真正的耗时在 onPartitionsAssigned 后新 owner 的第一次 poll() 里 fetch 建连 + 元数据刷新，但没找到 broker 侧对应日志字段可以验证。

【期望得到的答案形态】

• 一个可复现的拆解：从"旧 owner 提交 offset"到"新 owner 拉到下一条"，每一段（leave group → coordinator 触发 rebalance → assignor 计算 → 新 owner 感知 → 首次 fetch）各自的耗时量级和对应日志关键字（consumer 侧 + server.log 里的 GroupCoordinator 行）；
• 如果窗口主要在新 owner 的 fetch 建连，有没有比 session.timeout 更直接的旋钮（比如 fetch.min.bytes/fetch.wait.max.ms 调小、或 pre-assign 策略）；
• 对于"窗口内下游乱序感知"这件事，你们在生产里是靠消费侧序号去重、还是靠上游 at-least-once + 下游幂等吞掉的？给一个具体的幂等键设计。