已采纳
回答正文
回复
讨论正文
该问题的正文与回答。
order-event 48 分区,消费组 16 实例(3 分区/实例),峰值约 2 万 msg/smax.poll.records=500,按 batch 提交 offset(处理完整批再 commit,非逐条)t_msg_dedup(msg_id, biz_key, processed_at),TTL 目前拍的是 24h上月一次 Full GC 停顿 6s,实例被 GroupCoordinator 判定 max.poll.interval.ms 超时踢出组,rebalance 后它正在处理中的那个 batch 被新实例从上次 committed offset 重新消费——幂等表挡掉了绝大多数,但有一小撮「RPC 已执行、offset 未 commit、且 biz_key 守卫没覆盖到」的消息产生了双写,对账系统报了 3 笔重复。
事后复盘时我按最坏情况算了个理论窗口:单 batch 500 条 × P99 3.5s ≈ 29 分钟;如果叠加「上一 batch 处理中 GC + 本 batch 已被新实例开始处理」,窗口可能更大。但 24h 的 TTL 到底是不是过度防御、能不能压到 2h 甚至 30min,我目前给不出有数据支撑的答案。
max.poll.records × P99 单条耗时 算了理论上限(≈29min),但这只是单 batch 的界,没考虑「in-flight 未提交 batch 数」与「rebalance 后新实例从 committed offset 重放的范围」GROUP_COORDINATOR topic + 日志)确认了 rebalance 事件时间点与涉及的 partition,但拿不到「被踢瞬间该实例 committed offset vs 已处理到的 offset」的差值Processed batch of N records 和 Committing offsets,没有记录「commit 时该 batch 从 poll 到 commit 的总耗时」commitTs - pollTs 的 P99;或 consumer 本地维护 lastCommittedOffset vs lastProcessedOffset 的差值并打点)?请给出你们实际在用的指标名 / 日志字段 / 采集方式__consumer_offsets / group coordinator 日志)就能估算窗口的方法?打个比方:
max.poll.records像火车每节车厢的座位数,max.poll.interval.ms像发车时刻表。被踢出组 = 列车在站台上被调度员换司机,新司机从「上次停靠记录」(committed offset)重新开,中间那节没写进停靠记录的车厢(in-flight batch)就是重复窗口——我的问题是:这节车厢到底多长,怎么量出来,而不是按「最长车厢」拍 24h 的保险。