Kafka 幂等生产者「应用重启后 PID 变化」：broker 端幂等直接失效，下游业务表重复落库，这个窗口你们怎么兜？

【背景】 订单履约链路：业务服务（K8s，4 副本）→ Kafka 3.5（3 broker，KRaft，acks=all，min.insync.replicas=2）→ 消费端写 MySQL 8.0 业务表。生产端配置：enable.idempotence=true、linger.ms=5、batch.size=256KB、max.in.flight.requests.per.connection 被幂等钳制为 5。我们一直默认「开了幂等 = broker 保证不重不丢」，下游消费端只做了 offset 管理，没有业务级去重（唯一索引只建在 order_no 上，但业务上同一 order_no 本来就只允许一条）。

【现象（带数据）】 过去 6 周，消费端业务表出现 3 次「同一业务事件落了两条」，逐条复盘根因完全一致，且都不是消费端重复消费：

1. 生产端某副本因 GC 长暂停被 K8s 杀掉重启（或发布滚动），新进程拿到新 PID；
2. 旧进程被杀前，有 1~2 个 batch 已发到 broker 但 ack 未回（或 send 超时后 client 侧重试）；
3. 新 PID 在 broker 眼里是「全新生产者」，sequence number 从 0 重新计数 → broker 端幂等去重完全不认识这批消息，旧进程迟到的重发 batch 被当新消息正常写入；
4. 消费端按 offset 顺序读到两条内容相同的消息，order_no 唯一索引第二次 INSERT 报 Duplicate entry，我们当时的代码是直接吞异常（当作已存在跳过），但有两条记录的业务字段不同（一条是旧快照），对账时才发现。

【已尝试的排查与结果】

1. 确认 broker 端 __transaction_state 无关（我们没开事务，纯幂等）——幂等的去重窗口是 (PID, partition) 维度的，PID 一变，之前所有去重记录对「新身份」无效，这是设计使然；
2. 尝试让生产端 send() 失败后不自动重试（retries=0），改为进本地 outbox 表重投——重复率降了，但引入了新的「消息滞留 outbox」问题，且发布窗口内 outbox 与内存中已发出未 ack 的 batch 之间仍有缝；
3. 消费端想补业务级幂等，但卡住了：业务上没有天然的「消息级幂等键」——同一 order_no 的合法更新（状态流转）和非法重复（同状态重发）长得一模一样，INSERT ... ON CONFLICT DO NOTHING 会把合法更新也吞掉。

【期望得到的答案形态】 想收集大家生产环境的真实做法，最好带配置或 SQL：

• 幂等键该在哪一层定义、怎么取：生产端塞业务侧的 event_id（雪花/UUID）进消息体 + 消费端 (order_no, event_id) 去重表，是不是标准姿势？event_id 的生成时机（业务写事务内 vs send 前）对一致性有什么影响？
• 有没有人踩过「retries=0 + outbox」但 outbox 重投时又因为 PID 变化重复投递的坑？outbox 与幂等的边界怎么切？
• 消费端幂等表的状态机：「收到 event_id → 标记 processing → 写业务 → 标记 done」中间崩溃，重复消息进来时怎么判断该「跳过」还是「续做」？TTL 怎么定？

【相关站内内容】

• 幂等生产者把 max.in.flight 钳制到 5 的机制（id=122）——印证了幂等只覆盖「单 PID + 单分区」的窗口；
• 幂等键定义在哪一层、网关与业务层语义对不齐的讨论（id=1566）；
• 幂等不是加个唯一索引就完事，幂等键设计与去重表落地（id=744）。