Redis 幂等键 TTL 与消息重投窗口不匹配，偶发漏幂等，有效期该跟什么对齐

【背景】 订单履约链路：Kafka 3.5（3 broker，topic 16 分区，acks=all，retention 7 天），消费组 6 实例，at-least-once。消费端幂等用 Redis 7.0：SET idem:{order_id}:{event_type} 1 NX EX 86400，命中即跳过，未命中才处理业务（写 MySQL 8.0 + 调下游扣库存）。

【现象】 监控里出现偶发重复扣库存，特征很规律：重复的两次处理间隔都 >24 小时（多在 25~40h 之间），且只发生在「上游业务超时未 ACK、触发自家重试」的那批消息上。回查 Redis 发现那把幂等键已经过期被清掉，所以第二次 SET NX 又成功了，被当成全新消息处理，于是重复扣了。

【已尝试的排查与结果】

1. 先排除 Broker 侧重复投递：topic retention 7 天、消费 offset 正常推进，确认重复不是 Kafka 重投，而是上游业务侧的超时重发窗口（它自己最长可重试到 ~40h）；
2. 把 EX 从 86400 临时拉到 2592000（30 天）后重复消失，但单 key 数量涨到 2000 万级、内存从 6GB 飙到 30GB+，运维不接受长期这么跑；
3. 想过把幂等表落 MySQL（唯一索引 order_id + event_type），但担心高并发下每次消费多一次 DB 往返，P99 会被顶上去，一直没拍板。

【期望得到的答案形态】

• 幂等键的有效期到底该跟什么对齐？是消息 retention、上游重试窗口，还是业务流水的「可变更期」？有没有一个能推导的口径，而不是拍脑袋定 24h/30 天；
• 如果最终必须落库做幂等，怎么在保住 P99 的前提下把「查/写幂等」这一步成本降下来（比如本地缓存 + 唯一索引兜底）？
• 有没有人踩过「幂等键 TTL 与重投/重发窗口错位」这个坑？最后是怎么收口的、代价是什么？