KRaft controller failover 窗口内 EndTransaction 超时：「commit 超时但事务实际已提交」的边界你们线上碰到过吗？怎么确认、怎么兜底？

背景

我负责一条订单域链路，Kafka 3.5.2（KRaft，3 controller 节点，broker 8 台 16C64G），生产端 8 实例用事务 producer（enable.idempotence=true + transactional.id=order-{shard}，transaction.timeout.ms=60000），单事务跨 3 个 topic：

• order-event（16 分区，RF=3）
• inventory-deduct（8 分区，RF=3）
• audit-log（4 分区，RF=2）

消费端 isolation.level=read_committed，Spring Kafka 3.1.5 + Java 17（G1）。

现象 / 卡点

上个月一次 KRaft controller 切换（controller 日志里看到 KIP-500 leadership transfer，触发原因是 controller 所在 node 的 NVMe 盘连续 3 次 IO timeout），同一时间窗口内 2 个 producer 实例的 commitTransaction() 抛了 TimeoutException（Spring Kafka 侧设的 transaction.timeout.ms=60s，实际等了约 58s 才抛）。

诡异的是：消费端 LSO 日志显示这 2 个事务的数据已经可见——也就是说，commit RPC 从 producer 视角超时了，但 broker 端事务实际已经提交成功。消费端正常处理了这批数据，没有重复（幂等 producer 的 PID+epoch 保住了）。

这暴露了一个我没法完全解释的窗口：

EndTransaction RPC 到达 coordinator broker 后，需要向 __transaction_state log 写入。如果此时 KRaft controller 正在 failover，__transaction_state 的 leader 可能正在切换——这个写入到底是排队等待、被 reject、还是已经写成功了但 ack 回包丢了？

三种情况对 producer 侧的行为完全不同，但我从日志里只看到了 TimeoutException，无法区分。

已尝试的排查与结果

1. 查了 KIP-497 / KIP-500 的 controller 选举流程：理论上 EndTransaction 在 controller failover 期间应该被 reject（coordinator 检测 __transaction_state leader 不可用 → 返回 NOT_LEADER 或 COORDINATOR_LOAD_IN_PROGRESS），但实际看到的是 TimeoutException（等满 58s 才抛），不是快速失败。这暗示请求可能在 broker 侧排队等 controller 就绪，而不是被 reject。
2. 对比了 ZK 时代的行为：ZK 模式下 TransactionCoordinator 挂在 broker 上、不随 controller 切换，EndTransaction 的写入路径短且稳定。KRaft 下 __transaction_state 的 leader 选举依赖 controller，多了一跳依赖——这应该就是问题根源，但我找不到官方文档明确描述这个窗口的行为。
3. commit 失败后的重试：Spring Kafka 的 DefaultKafkaProducerFactory 在 commit 失败后直接抛异常、不自动重试 commit。我们的业务代码 catch 后走了「回滚 + 重新发送」逻辑，但因为事务实际已提交，重试时幂等 producer 的 PID+epoch 把重复消息拦住了——这次侥幸没出事。但如果消费端没有幂等兜底（比如消费端是写外部系统的非幂等操作），这次就会重复执行。
4. 查了 __transaction_state 日志：确认了这 2 个事务的最终状态是 COMPLETE_COMMIT，时间戳与 commit 超时时间差约 2–4s。说明事务确实在超时窗口内完成了提交，但 ack 没回到 producer。

期望得到的答案形态

想听线上真跑过 KRaft + 事务 producer、且碰到过 commit 超时但事务已提交的方案，而不是「理论上 KRaft 应该怎样」：

1. 你们线上有没有碰到过「commit 超时但事务实际已提交」？ 怎么确认的（LSO 日志？__transaction_state 查询？consumer 侧日志？有没有现成的 kafka-tool 命令能查某个 transactional.id 的事务状态）？

2. KRaft 下 EndTransaction 在 controller failover 期间的具体行为：请求是在 broker 侧排队等 leader 就绪（所以表现为 timeout）还是被快速 reject？__transaction_state 的 leader 切换窗口一般多长（你们线上实测过吗）？有没有调过 transaction.state.log.replication.state.check.interval.ms 或相关参数来缩短这个窗口？

3. producer 侧怎么安全判断「这次 commit 到底成功了没有」？ 有没有类似「commit 超时后，查一下 __transaction_state 确认事务状态，再决定是重试还是放弃」的轻量方案？还是说只能靠消费端幂等兜底？

4. 如果你们选择「commit 超时 = 放弃 + 重新发送」，消费端的幂等兜底具体怎么做的？能不能接受「消费端必须做幂等，否则 commit 超时窗口内可能重复」这个前提？你们的幂等方案是什么（幂等表？状态机？先查后做？）？

我自己目前的理解是：KRaft 下 EndTransaction 比 ZK 时代多了一个 __transaction_state leader 可用性依赖，controller failover 窗口（通常 2–5s）会把这个依赖放大成 producer 侧的 timeout。这个窗口在 ZK 时代是不存在的（或极短），所以 KRaft 迁移后这个边界 case 的触发概率可能比 ZK 时代更高。

想看看大家是怎么把这个边界画清楚的——特别是「commit 超时后到底能不能安全地认为事务已 abort」这个问题，我在社区里还没看到有人正面回答过。欢迎拍砖。