Kafka 消费者「批处理中间 crash」：500 条消息处理到第 300 条时 crash，已写的 50 行 DB 怎么收口？行级幂等在 200k rows/s 下到底多贵？

【背景】 Kafka 3.5 KRaft，3 broker，某 topic 24 partition，核心消费者 4 实例（Spring Boot 3.2），max.poll.records=500，auto.commit=false（手动 commit），DB 是 MySQL 8.0（InnoDB）。

业务路径：每条消息是一个「批量更新订单」的指令，包含 100 行订单数据（UPDATE orders SET status=?, amount=? WHERE order_id=?）。消费者一次 poll() 拿到 500 条消息，逐条处理（每条消息 100 行 DB 写入），全部处理完后 commit()。

社区里关于「消息级幂等」的讨论已经很多了（幂等表 + 唯一索引、状态机、Outbox 等），但我们的卡点不在「整条消息重复」，而在**「一条消息内部的 100 行，写到第 50 行时 crash」**——这个粒度比消息级更细，消息级幂等根本兜不住。

【现象】 某次节点被 Spot 回收（类似 K8s preemption，SIGKILL 无 drain），消费者在「处理第 300 条消息、已写 50 行 DB（还剩 50 行）」时 crash。重启后从上次 commit 的 offset 重新消费，第 300 条消息的 50 行被重复执行。

由于是 UPDATE 而非 INSERT，重复写入不会报错，但业务语义上这 50 行的 status / amount 可能被「回退」到旧值——因为消息里携带的是「变更后的目标值」，重复执行等于「用目标值覆盖当前值」，如果中间有其他写入，就会被覆盖。这不是「多写了一行」的问题，是「写错了值」的问题。

【已尝试与结果】

1. 消息级幂等（幂等表 + 唯一索引）：防住了「整条消息重复投递」，但对「消息内部 100 行写到一半 crash」完全无效——因为 offset 没 commit，整条消息会重新消费，前 50 行被重复 UPDATE。
2. 每行加幂等键（幂等表按 row_key 去重）：成本太高——100 行 × 500 条 = 50000 行/批，每行都要 SELECT idempotent_table WHERE row_key=? 再 INSERT，DB QPS 直接翻倍，P99 涨了 35%。
3. 全量重算（每次重新读 100 行当前值 + 计算目标值 + 写回）：成本是「读 100 行 + 写 100 行」，在 200k rows/s 下额外增加 100% 的读放大，DB 从「写密集」变成「读写均衡」，InnoDB buffer pool 命中率掉了 8%。
4. 缩小 max.poll.records（500 → 50）：减少了「批处理中间 crash」的影响范围（最多丢 50 条 × 100 行 = 5000 行），但吞吐从 200k rows/s 降到 20k rows/s，业务不可接受。
5. 每 10 行 flush 一次 checkpoint 到 Redis（row_key + 已写标记）：crash 后从 checkpoint 恢复，跳过已写的行。问题：Redis 的 checkpoint 写入本身也是一个「写一半 crash」的问题，而且 50000 次 Redis SET 的延迟叠加到 P99 上。

【期望得到的答案形态】

1. 有没有「消息级幂等 + 行级 checkpoint」的生产级混合方案？checkpoint 存哪里（Redis / DB / 本地磁盘）？粒度怎么定（每 N 行 vs 每 M 秒）？
2. 行级幂等的成本在 200k rows/s 下到底多贵？有没有人做过量化对比（DB QPS / P99 / buffer pool 命中率）？
3. 如果走「全量重算」路线，有没有比「SELECT + UPDATE」更高效的实现？（比如 MySQL 8.0 的 INSERT ... ON DUPLICATE KEY UPDATE 能不能减少一次读？）
4. 有没有人在生产环境遇到过「批处理中间 crash」的实际案例？最后是怎么兜的？兜底方案的运维成本（监控、告警、人工介入频率）大概是什么量级？
5. 如果以上都不行，有没有「接受这 50 行会被重复 UPDATE」的业务侧兜底方案？（比如幂等窗口 + 对账修正，而不是在消费端做行级幂等）

【相关讨论】 社区已有大量「消息级幂等」的讨论，但「行级」这个粒度还没有被直接讨论过。以下两条是我最接近的背景参考：

• 讨论帖《幂等窗口到底开多长？幂等表 TTL 和消息重复窗口的博弈》：讨论了幂等表 TTL 的设定，但粒度是「消息级」，没有涉及「消息内部行级」。
• 讨论帖《消费端防重：幂等表 TTL、业务唯一索引、状态机——三层到底谁兜底？》：讨论了三层防重的分工，但假设的原子单位是「一条消息」，不是「一条消息里的 100 行」。