Kafka 消费端本地事务表与 offset 提交如何做到原子，崩溃窗口如何对账

【背景】 订单结算服务，Kafka 3.5（3 broker，ISR=3），topic settle-bill 12 分区，消费组 6 实例，max.poll.records=200。单条消费逻辑是「校验 → 写 MySQL 8.0 结算单（本地事务，2 张表：bill + bill_item）→ 提交 offset」。单条 P99 约 45ms，一批 200 条约 9s，lag 平时 0~30。投递语义是 at-least-once，消费端靠「结算单号 out_biz_no 唯一键」做幂等去重。

【现象 / 卡点】 真正卡住我的是「本地事务提交」与「Kafka offset 提交」之间的一致性窗口：

1. 先落库、后提交 offset：进程在两步之间被 kill / OOM 时，数据已落库但 offset 没提交，重启后这批 200 条全部重放，靠 out_biz_no 去重兜底——功能没问题，但高峰期重放 + 去重查询把 MySQL 主库 QPS 打上去，唯一键冲突日志刷屏；
2. 先提交 offset、后落库：反过来就可能在落库前崩溃直接丢数据，这个我不敢用。 核心疑问：Kafka 的 offset 提交本质是 broker 端写 __consumer_offsets，和我本地 MySQL 事务是两个独立提交，没法用单一分布式事务绑死（引入 XA/2PC 代价太高）。业界到底怎么把「业务数据落库 + offset 前移」做成逻辑原子，又不在崩溃窗口里丢数据或大量重放？

【已尝试的排查与结果】

• 纯「先落库后提交 offset + 幂等」：功能正确，但重放时段去重查询 + 唯一键冲突让结算表主库 CPU 从约 40% 抬到 75%，运维不放心；
• 想过用 outbox 模式把 offset 也当事务消息发回 Kafka 再消费，链路变长、延迟 +150ms，没坚持；
• 考虑过本地事务表（同一 MySQL 事务里同时写 bill、bill_item 和一张 consumed_offset(partition, offset, status)），但没想清楚崩溃恢复时怎么对账、status 怎么流转、和 Kafka 端 offset 如何最终收敛。

【期望得到的答案形态】 想请教一个能落地的方案，最好带：

• (a) 本地事务表的具体表结构（字段、唯一键、是否按 partition 分片）；
• (b) 「业务表 + offset 表」在同一个 MySQL 事务里的写法，以及和 Kafka 端 offset 提交的先后顺序（先库后 offset 还是先 offset 后库）；
• (c) 崩溃恢复时的对账流程：重启后如何发现「offset 表已记录、Kafka offset 还没提交」或反过来的情况，怎么补 / 怎么跳过，最好给伪代码或步骤；
• (d) 这套方案下重放窗口能压到多小，去重查询怎么避免打到主库（比如异步落盘 / 缓存 out_biz_no）。 如果你们没上本地事务表，也欢迎直接说「我们就是纯幂等 + 接受重放」，并给一下重放期间的峰值 QPS 和能接受的阈值，帮我做取舍。