Kafka 消费端按 (transactional.id, producer_epoch) 做幂等，epoch 回绕后幂等表如何不失效

【背景】 我们用 Kafka 3.6（3 broker，KRaft）承载支付事件链路。生产者侧 enable.idempotence=true + 事务，transactional.id 固定为 pay-evt-{shard}（按订单分片，约 64 个）。消费端做幂等去重：把 (transactional.id, producer_epoch, first_offset) 三元组写进 Redis/DB 幂等表，收到消息先查表，命中即丢弃。日均约 1800 万条，消费组 8 实例。

【现象 / 卡点】

1. 我们默认假设 producer_epoch 是「单调递增且永不回绕」，所以幂等表里只存「见过的最大 epoch」。但翻 Kafka 源码（ProducerStateManager / KafkaApis）发现 epoch 是 int：达到 Integer.MAX_VALUE 会回绕到 0，revert 场景还会回退到负值；
2. 一旦回绕，「见过的最大 epoch」判断会放过回绕后新 epoch 的合法消息、同时把回绕前旧 epoch 误判为过期——也就是幂等表可能既漏放重复、又误杀合法；
3. 更麻烦的是：同一 transactional.id 在「长事务持有期间」与「事务回滚后重新 init」之间 epoch 会推进，但 offset 不连续，三元组去重与「按 offset 判断新旧」两套逻辑互相打架。

【已尝试与结果】

1. 幂等表只存 (transactional.id → 最大 epoch)：压测下回绕路径触发不了（epoch 距 MAX_VALUE 还很远），但长期运行边界不放心；
2. 想改成「存最近 N 个 epoch 的滑动窗口」，但 N 取多少、淘汰策略、以及和 offset 判断如何合并，没有把握；
3. 考虑直接改用业务幂等键（orderId + seq）去重、彻底不依赖 epoch，又担心丢掉 epoch 天然带来的「同一 producer 内顺序 + 去重」能力。

【期望得到的答案形态】

1. 给明确结论：在「消费端用 epoch 做幂等」这个用法下，producer_epoch 回绕到底会不会真的发生、在什么条件下发生（revert / 长时间空闲 / epoch 耗尽），给一个可判断的量级与触发路径；
2. 给一套「回绕安全」的幂等键设计：用 (transactional.id, epoch, offset) 还是业务键，如何与「见过的最大 epoch」共存，窗口淘汰策略怎么定；
3. 如果结论是「别用 epoch 做消费端幂等」，请给替代方案的取舍（延迟、存储成本、一致性），并指出我第 3 点里丢掉的能力如何补回来。