Kafka 消费端按时间戳重放历史消息做数据补偿，如何与实时消费并行且不重复不丢失

【背景】 我做订单履约服务，Kafka 3.5（3 节点），topic order-fulfill 16 分区，实时消费组 8 实例，日均约 4000 万条，消费逻辑是「读 batch → 写 MySQL 8.0 → 提交 offset」。平时正常，但偶发需要重放历史消息做数据补偿：比如下游 DB 主从切换丢了 30 分钟 binlog、或某版本 bug 把一段订单状态写错，需要把过去 30~60 分钟的消息重新消费一遍。

【卡点 / 现象】

1. 一开始直接在实时 group 上 seek 到目标 timestamp，结果把整个 group 的 committed offset 拉回去了——实时链路被「倒退」拖回 30 分钟，重复消费了约 12 万条，下游出现重复落库；
2. 后来改成开一个独立的 replay consumer group，但 offset 初始化为 0 后是从 topic 头部开始重放，量太大根本跑不完；想按 timestamp 定位 offset，又和分区保留期（7 天）、offsetsForTimes 返回的近似值耦合，定位不准；
3. 重放消息和实时消息会在同一分区上交错，幂等键（目前只有业务订单号）在「重放窗口内同一业务键被重复投递」时挡不住——因为实时那条已经提交、重放这条是「迟到的重复」，去重窗口按时间算已经过期；
4. 重放期间如果不限速，下游 DB 连接池（max 50）会被打满，反过来又拖垮实时消费。

【已尝试的排查】

• 同 group seek 重放：失败，offset 倒退，重复消费；
• 独立 replay group + offset=0：量太大；
• 独立 replay group + offsetsForTimes 按时间戳定位：能定位，但不确定返回的 offset 是「严格 ≥ 目标时间」的近似值，边界 ±1 条不确定；
• 幂等：目前靠 MySQL 唯一索引（订单号）+ INSERT ... ON DUPLICATE KEY，但「迟到重复」落在去重窗口外时仍会重复执行副作用。

【期望得到的答案形态】 希望有做过类似「重放补偿」的同学给具体方案：

1. replay 与实时消费的隔离策略——独立 group 还是同 group 副本？各自 committed offset 怎么互不影响？replay group 用完后如何优雅回收（删 group 还是保留）？
2. 如何按 timestamp 精确 seek（offsetsForTimes 的语义、边界 ±1 条怎么兜住），且完全不碰实时 group 的 offset；
3. 幂等键设计：在「迟到重复」场景下，业务键之外还要不要加版本号/消息时间戳/单调递增 seq？去重窗口到底按「时间」还是按「版本/seq」判定才稳？
4. replay 限速与下游背压：消费端拉取速率、max.poll.records、DB 连接池怎么配，才能既把 30 分钟消息放完、又不把实时链路和 DB 打垮；
5. 最好给 2~3 个可复现的定位步骤 + 关键 JMX / broker 指标（比如怎么确认 replay group 和实时 group 的 offset 真的各走各的）。

我接受「至少一次 + 幂等」的路线，不追求 exactly-once，重点是重放期间实时链路不中断、不重复、不丢失。