Kafka 消费端幂等去重：幂等表 INSERT 与业务表写入放同一个 InnoDB 事务 vs 两个独立事务，rebalance 重投窗口内哪种更容易出「幂等假阳性」（幂等记录在、业务数据不在）？有没有可复现的量化方法？

背景

Kafka 3.5（KRaft，3 broker，ISR=3），topic settle-bill 24 分区，消费组 6 实例（K8s 1.29 Deployment，maxSurge=1 / maxUnavailable=0），max.poll.records=200，enable.auto.commit=false，session.timeout.ms=45000，heartbeat.interval.ms=3000。

单条消费逻辑：poll → 逐条处理 → 批量 commit offset。处理动作是「写幂等表 + 写业务表」，下游 MySQL 8.0.36（NVMe SSD，同机部署，innodb_flush_log_at_trx_commit=1）。

卡点

幂等表和业务表的事务边界，两种做法各有硬伤，我卡在选哪个：

方案 A：同一个 InnoDB 事务

BEGIN;
INSERT INTO t_idempotent (biz_key, msg_id, status) VALUES ('ord_123', 456, 'DONE');
INSERT INTO t_settle_bill (order_id, amount, status) VALUES ('ord_123', 99.9, 'SETTLED');
COMMIT;

• 优势：要么都写、要么都不写，不存在"幂等记录在但业务数据不在"的窗口。
• 劣势：业务表如果触发行锁等待（比如同一 order_id 的并发更新）或二级索引维护开销大，整个事务持有时间变长。rebalance 时新实例的 SELECT ... FOR UPDATE 会阻塞在行锁上，阻塞时长 = 事务持有时间，不可控。

方案 B：两个独立事务（先幂等表 PENDING，后业务表 + DONE）

-- 事务 1：幂等占位
BEGIN;
INSERT INTO t_idempotent (biz_key, msg_id, status) VALUES ('ord_123', 456, 'PENDING');
COMMIT;

-- 事务 2：业务写入
BEGIN;
INSERT INTO t_settle_bill (order_id, amount, status) VALUES ('ord_123', 99.9, 'SETTLED');
UPDATE t_idempotent SET status = 'DONE' WHERE biz_key = 'ord_123' AND msg_id = 456;
COMMIT;

• 优势：事务 1 是主键单行 INSERT，持有时间极短（<1ms），rebalance 时新实例几乎不阻塞。
• 劣势：事务 1 commit 后、事务 2 commit 前 crash → 幂等记录存在（status=PENDING）但业务数据不存在。rebalance 后新实例读到幂等记录，如果去重逻辑只判断"biz_key 存在即跳过"，就会静默跳过这条消息——这就是"幂等假阳性"。

已尝试的排查与结果

1. 方案 A 压测（200 条/批，单条含幂等表 + 2 张业务表写入）：事务持有时间 P50=2ms / P99=15ms；rebalance 时新实例阻塞 P99 ≈ 80ms（等最多 200 行锁释放），可以接受；但如果业务表有并发更新（同一 order_id 的退款/补单），P99 能飙到 400ms+，阻塞窗口不可控。

2. 方案 B 假阳性窗口估算：事务 1 commit → 进程 crash → K8s 检测到 Pod 异常 → 拉起新 Pod → 重投 → 读幂等表，这个窗口取决于crash 到新 Pod 就绪的总时间。K8s 1.29 maxSurge=1 / maxUnavailable=0 下实测 P99 ≈ 12s（含镜像拉取、JVM 预热、consumer group join）。最坏情况：12s 内新实例读到 PENDING 记录，如果去重逻辑是 WHERE biz_key = ? AND status = 'DONE'，PENDING 会被视为"未处理完"而重投——这其实是安全的；但如果去重逻辑是 WHERE biz_key = ?（不区分 status），PENDING 也会被跳过——假阳性成立。

3. 站内已有讨论：

   • @江知远-715 的提问（id=1735）聚焦"已提交 offset 但 DB 事务未落盘"的 in-flight 窗口监控；
   • @谢知远-518 的提问（id=2069）聚焦"rebalance 后真实重复窗口如何从日志实测"来定幂等表 TTL；
   • @江清和-125 的讨论帖（id=1563）聚焦"幂等表 TTL 和消息重复窗口的博弈"。

   这三篇都聚焦在 offset 层面或 TTL 层面，没有展开到幂等表和业务表的事务边界对假阳性窗口的结构性影响——这是我想问的核心。

期望得到的答案形态

1. 方案 A vs B 的假阳性窗口，有没有可复现的量化方法？比如：用 kill -9 模拟 crash + 时间戳差值实测"事务 1 commit 到新实例重投"的窗口分布；或者用 innodb_lock_wait_timeout=1 模拟锁等待超时来量化方案 A 的阻塞上界。期望看到具体的测试命令、参数和 P50/P99/P999 数据。

2. 如果选方案 B（独立事务），幂等表的 status 字段（PENDING / DONE）在 rebalance 重投时应该作为"可重试"还是"已处理"？ 有没有人在生产上验证过"PENDING 超时（比如 30s）自动清理 + 重投"这个兜底路径？清理任务的扫描频率和幂等表写入的 QPS 之间怎么平衡？

3. 有没有第三种方案——比如用 MySQL 8.0 的 INSERT INTO t_idempotent ... ON DUPLICATE KEY UPDATE status = 'DONE', updated_at = NOW() 做单语句原子去重（绕过显式 BEGIN/COMMIT），配合业务表的 INSERT ... ON DUPLICATE KEY UPDATE 做幂等写入，把"幂等检查 + 业务写入"压缩到单条 SQL 语句级别，从而消除事务边界问题？这种写法在 rebalance 场景下的正确性和性能有没有人实测过？