Kafka 分区保序链路里「毒消息旁路 + 回放」：消息绕过后主分区已前进，回放怎么重新定位到正确顺序位置，旁路期间被跳过的依赖消息怎么对账？

背景

我负责一条订单履约事件链：Kafka 3.5（KRaft，3 broker，ISR=3），topic order-event 按 order_id 哈希到 64 分区，消费组 32 实例，分区内严格顺序消费（单 partition 单 worker 线程，offset 逐条提交）。下游是 MySQL 8.0 状态机表（uk_order_id_version，version 单调递增），语义要求：同一订单的事件必须按 version 顺序生效，不允许「签收」先于「发货」落库。

我们踩到的坑是经典组合：分区内顺序 + at-least-once + 一条毒消息，三者叠加后出现一个没有标准答案的三角冲突——

• 不跳过：毒消息（一条脏 version 的事件，处理必抛 NPE）把整个分区卡死，lag 从 0 爬到 40 万，下游状态机全部停摆；
• 跳过：保住了吞吐，但毒消息后面紧跟的 3 条正常消息因为依赖它的前置状态（状态机拒绝跳 version）也被连带失败，跳过它们的 offset 等于静默丢了 4 条业务事件；
• 重投：把毒消息重试 N 次后还是失败，问题没解，只是把卡死延迟了。

现象

按社区常见做法（旁路队列降级）我们上了 DLT：消费失败 3 次 → 消息投到 order-event-dlt topic，主分区继续前进。当时看起来问题解决了，但两周后对账系统报出 117 笔订单状态机断档（version 序列有洞，如 1→2→4，缺 3）——根因就是「毒消息被旁路、后续消息被跳过、没有任何回放机制把 DLT 里的消息按正确顺序注回主链路」。

已尝试的排查与结果

1. DLT + 定时批量回放：写了个 job 每 5 分钟扫 DLT 按时间戳批量投回原 topic。结果：投回去的消息落在分区当前 offset 末尾，而主分区里它前后相邻的消息早已处理完——顺序彻底打穿，状态机大面积拒绝，反而制造了更多毒消息（回放消息又进 DLT，死循环）。
2. 回放前查状态机当前 version，只允许「恰好补洞」的消息回放：逻辑上对了一半，但「恰好补洞」的判断依赖读 MySQL 拿当前 version，而同一订单可能有多个洞（毒消息不止一条时），补洞顺序依赖洞的拓扑关系，job 里写成了串行 for 循环，117 笔断档回放跑了 40 分钟才收敛，期间该订单的新事件持续被状态机拒绝——回放窗口越长，新事件被拒越多。
3. 直接在 DLT 消费端做「状态机补偿」（不注回主 topic，DLC 消费时直接调状态机 API）：绕过了顺序问题，但等于旁路链路和主链路两套代码路径，幂等语义不一致（主链路靠 uk_msg_id，旁路靠 uk_order_id_version），对账口径对不上，我们放弃了。

卡点（想问的）

具体到三个问题，期望各位贴线上真实跑过的方案 + 配置/代码片段，而不是「建议用事务消息」这类方向性回答：

1. 回放定位：毒消息被旁路后，如何把它的「顺序位置」信息（原 partition + offset 区间 + 前后相邻消息的 version）持久化下来，让回放时能判断「现在注入是否安全」？你们是把 offset 水位线存哪（Redis / DB / 本地文件）？rebalance 或消费实例重启后这套水位线怎么恢复？
2. 依赖消息的连带失败：毒消息后面 3 条消息因状态机拒绝被 skip 掉，这 3 条的 offset 已经提交了——你们是怎么把这批「被毒消息连坐」的消息和 DLT 里的毒消息关联起来做整体回放的？是靠日志解析，还是消费端在 skip 时主动写一张「待补偿」表？
3. 对账口径：旁路链路存活期间（我们实测最长一次 DLT 积压 6 小时），对账系统怎么区分「合法的状态机跳 version（业务允许）」和「毒消息造成的断档（必须补偿）」？

参考

站内两篇相关经验，我先读了再问的：

• 《RocketMQ 顺序消费被一条毒消息卡到 0 QPS：线程模型、旁路队列与降级策略》（id=781）——旁路队列的思路我认同，但文章没展开回放定位；
• 《Kafka 毒消息：一条坏消息如何拖垮一个分区，以及 DLT 背后你可能没接住的静默丢失》（id=181）——「静默丢失」正是我上面说的 117 笔断档。

期望的回答形态：你们线上毒消息旁路 + 回放的完整链路设计（含水位线存储位置、关联待补偿消息的表结构、对账规则），以及踩过的坑。空对空的「建议引入事务消息 / 用 outbox」如果没落到回放定位这一层，请先回答上面三个具体问题再谈架构选型。