Kafka 消费端「先幂等落库、后 commit offset」的崩溃窗口：宕机卡在两步之间时，到底该保不丢还是不重？有没有可复用的提交顺序模型？

背景

• Kafka 3.4（3 broker KRaft），topic order-pay 32 分区，消费组 12 实例（K8s Deployment，maxSurge=1 / maxUnavailable=0），日均约 4500 万条，峰值 8200 msg/s。
• 消费逻辑顺序：反序列化 → 幂等落库（MySQL 8.0，唯一键 order_no + event_type）→ 手动提交 offset（enable.auto.commit=false，commitSync）。
• 业务约束：资金相关，不能丢；重复可容忍但必须可观测、可对账。

现象（三个具体卡点）

1. 我把 commitSync 放在业务落库之后。若「落库成功、commit 之前」进程被 OOMKilled，重启后 offset 回退到上次提交点，这批消息被重放 → 靠幂等表唯一键挡住，但每天仍出现 200~800 条重复消费日志，对账 job 里全是噪音，很难分辨"真重复投递"还是"业务重试"。
2. 反过来若把 commit 提前到落库之前，一旦落库失败（唯一键冲突之外的异常，比如连接超时、主从切换），消息就真丢且 offset 已前进无法重放——资金场景不可接受。
3. 用 enable.auto.commit=true + auto.commit.interval.ms=5s 时崩溃窗口更大（最多 5s 的量级），高峰期直接可能丢几百条，不敢用。

已尝试

• 幂等表唯一键挡重复：有效，但高峰重试窗口内 DB QPS 多 3~8%，写放大明显，且无法区分重复来源。
• 落库后 commitSync 再 commitAsync 兜底：治标，窗口没缩小。
• 消费端开 idempotent producer + 事务：producer 端幂等解决不了"消费端落库与 commit 的原子性"这个核心矛盾。
• 社区里有人提"本地消息表 / Outbox"，但那些多讲生产侧原子性，消费侧的提交顺序我没找到成体系的量化说法。

期望得到的答案形态

1. 「先落库、后 commit」vs「先 commit、后落库」两种顺序的崩溃窗口到底差多少量级？有没有公式（窗口 ≈ 什么）或可落地的量化方法，好让我去说服业务方？
2. 有没有「落库 + 位移提交」原子化的工程做法（消费幂等表 + 对账补偿 job / 本地消息表反查）的具体落地清单？扫描窗口、补偿频率、去重键怎么定？
3. 资金强一致场景，推荐哪种顺序 + 什么补偿机制兜底？请给具体配置数字（commit 间隔、对账窗口、补偿 job 调度周期）和取舍依据。

想听听踩过这坑的同学给的可复现方案，而不是"用幂等表"这种一句话结论。