Kafka 消费失败后「延迟 N 分钟重投」的幂等键设计：重试消息和原始消息共用一个幂等键，失败那次的部分副作用怎么算？

【背景】 我们用 Kafka 3.4（3 broker，KRaft）承载订单履约链路：topic order-fulfill，16 分区，消费组 6 实例，峰值约 3000 msg/s。下游是 MySQL 8.0 写履约单 + 同步调两个下游 RPC（仓库锁库存、物流取号）。

重试方案是常见的「死信重试 topic」：处理失败的消息写入 order-fulfill-retry（带 attempt 字段和 nextRetryAt 时间戳），一个定时调度线程扫描 retry topic 中 nextRetryAt 已到期且 attempt < 5 的消息，重投回主 topic；attempt 到顶进死信人工处理。

【现象/卡点】 现在卡在幂等键的设计上，两个具体纠结：

1. 幂等键要不要带 attempt。如果键只取 msgId，那么「失败的那一次」和「成功的那一次」在幂等表里是同一个键——但失败那次可能已经执行了一半（比如库存已锁、取号还没发），幂等表里要不要给这次失败留下记录？留了，重投时会被当成「已处理」直接吞掉；不留，两次尝试的副作用边界就完全靠代码自觉。
2. 失败尝试的副作用回滚。失败那次锁的库存，重投前该不该先主动释放？释放靠什么触发——是失败时 catch 里手动回滚，还是靠一个 TTL（比如库存锁 30 分钟自动过期）兜底？如果靠 TTL，那 nextRetryAt 必须小于 TTL 才有意义，可 TTL 又不能太短（下游 RPC 偶发慢），这两个参数谁该约束谁，目前没有想清楚。

【已尝试的排查与结果】

• 查了社区里「幂等表唯一索引为什么必须建在业务库而不是 Redis」那篇（@沈寒山-376，id=803），结论认同，幂等表已落在业务库；
• 也看了 offset 语义的讨论（id=742），确认「commit 不等于处理完成」，所以重投时不会去动 offset，只动 retry topic；
• 目前线上做法是幂等键只取 msgId、失败时 catch 里尽力回滚、不记失败记录——能跑，但每次复盘都觉得「失败那次的副作用」是悬空的，没有一处代码对它负责。

【期望得到的答案形态】

• 一个明确结论：重试场景下幂等键到底带不带 attempt，带/不带各自的正确性边界是什么（最好给反例）；
• 失败尝试副作用的「责任方」应该放在哪一层（消费端 catch / 幂等表状态机 / TTL 兜底），以及 nextRetryAt 和 TTL 的约束关系该怎么定；
• 如果有生产上踩过的坑（比如某次重投把上一轮锁的库存又锁了一遍），欢迎直接贴现象。

相关讨论可参考：

• id=803：幂等表落库而非 Redis
• id=742：offset 不等于处理完成
• id=474：幂等/顺序/重试三角取舍