K8s 滚动更新时 Kafka Consumer 优雅停机，in-flight 消息与 offset 提交竞态如何消除

【背景】 我们用 Kafka 3.4（3 broker，topic 64 分区，副本因子 3，acks=all）承载结算对账链路，消费组 12 实例（每实例 5 分区），日均 1800 万条，SLA 要求不丢不重。下游是 MySQL 8.0 写结算记录（非天然幂等）+ 一次外部 RPC 通知，单条处理 P99 ≈ 2.8s。

【现象】 K8s 滚动更新策略：preStop hook sleep 5s + terminationGracePeriodSeconds=30s。每次发版后观察，约 3%~5% 的 Pod 在收到 SIGTERM 时仍有 in-flight 消息（已 poll() 拉取、尚未处理完）。这批消息的 offset 尚未提交，Pod 被 K8s 杀掉后重启，offset 回退到上次提交点，导致下游重复结算。我们按月份统计，每月大约 200~400 笔重复，对账成本很高。

【已尝试的排查与结果】

1. preStop sleep 从 5s 调到 15s——改善有限，因为 in-flight 消息本身处理就要 2~3s，sleep 只是延后了 SIGTERM，close() 窗口内的 poll() 仍可能拉到新消息。
2. 在 close() 前手动调 commitSync()——如果最后一批 poll() 拉到的消息处理超时（外部 RPC 抖动），commitSync 还没执行 Pod 就被 SIGKILL，offset 仍然丢失。
3. 尝试用 Kafka 事务（initTransactions + sendOffsetsToTransaction + commitTransaction）——事务要求 transaction.max.interval.ms 内完成，默认 15min，但 K8s 的 30s 窗口远小于此，事务还没 commit 就被 kill，回滚后 offset 又回到旧值，问题依旧。
4. 把 terminationGracePeriodSeconds 拉到 120s——发版时间从 8min 膨胀到 22min，运维不可接受。

【期望得到的答案形态】 想请教大家在生产环境（K8s + Kafka Consumer + 非幂等下游）下，滚动更新时做到 0 丢失 0 重复的具体方案。最好能包含：

• 信号处理代码片段（SIGTERM → drain in-flight → commitSync → close 的完整顺序）；
• 关键参数（terminationGracePeriodSeconds、preStop、max.poll.interval.ms、session.timeout.ms）的推荐值及理由；
• 如果必须改架构（如下游幂等化 + 异步确认），给出最小改动路径；
• 有没有人踩过 Kafka 事务 + K8s 超时的坑，怎么调参解决的。

有具体数字和配置就更好，谢谢！