Kafka 消费端「已提交 offset 但 DB 事务未落盘」的 in-flight 窗口：怎么把这段不可见区间变成可监控的「未确认消息量」指标？

背景

我负责订单履约链路，Kafka 3.5（KRaft，3 broker），topic 16 分区、峰值 4k msg/s，消费组 8 实例。消费端是 at-least-once：拉取批次 → 逐条写 MySQL 8.0（业务表 + 幂等表）→ 批量提交 offset。社区已经把幂等表、状态机、中间态回滚聊得很透（#1594、#742、#940），但我最近复盘一次事故时发现一个还没被认真掰扯的盲区：offset 提交成功 ≠ 消息真正处理完成，两者之间存在一个「in-flight 窗口」，而我们对这个窗口完全是盲的。

现象（带数据）

上周一次 broker 切主，消费组触发 cooperative rebalance。事后对账发现：

• 有 3 个分区出现「offset 已前进 200+ 条，但幂等表里查不到对应业务记录」的窗口——这些消息的 DB 写事务在 commit 前被 rebalance 打断，靠下游 T+1 对账才捞回来，补跑了 40 分钟；
• 期间 lag 指标完全正常（甚至显示 0），因为 offset 已经提交了；
• 我们没有任何指标能回答「此刻有多少条消息『看起来已交付』但实际上还没确认落库」。

已尝试的排查与结果

1. 调小 max.poll.records（200→50）：窗口从 200+ 条缩到 50 条以内，但治标不治本，且吞吐掉了 30%；
2. 改逐条 commitSync：窗口理论上缩到 0，但 4k msg/s 下 commit 请求量翻了 10 倍，broker 端 __consumer_offsets 压力明显，pass；
3. 想加「未确认消息量」指标：在内存里维护 inflight = 已拉取未提交 offset 的条数，rebalance 时上报。但发现两个坑：(a) 进程被 kill -9 时内存值直接蒸发，指标断崖归零，反而误导；(b) 多实例下 in-flight 是每实例本地状态，聚合到组维度只能靠上报，窗口期数据不完整。

期望得到的答案形态

想请教社区有几种落法，最好能给出可复现的取舍依据：

1. 水位线方案：把「已确认落库的最大 offset」（per partition）作为 watermark 单独持久化（比如写进幂等表或 Redis），监控 committed - watermark 的差值作为「未确认消息量」——这个差值在 rebalance 前是有意义的吗？多实例抢分区时 watermark 语义会不会乱？
2. 幂等表反推：用「幂等表里 status=pending 且创建时间 > N 秒」的条数近似 in-flight——精度如何，对账成本可接受吗？
3. Kafka 原生：transactional producer / EOS 能不能覆盖消费端这个场景（我知道它主要解决生产端，但想确认没人拿它做过消费端 in-flight 观测）？

另外想听大家拍砖：你们线上「offset 已提交但业务未完成」这个窗口，到底有没有被当成一等公民监控过？ 还是说大家都默认「幂等表 + T+1 对账」兜底就完事了？如果是后者，那 rebalance 高频的集群（比如我们这种 8 实例 16 分区、每天 2~3 次 rebalance）的兜底成本你们算过账吗？