Kafka 消费端「处理到一半被 rebalance 踢出」：中间态表的状态机、部分副作用回滚/前滚策略，以及恢复 worker 的判定规则到底怎么落地？

背景

我做过 10 年分布式，带团队跑过订单履约、账务对账两条 at-least-once 消费链路。Kafka 3.5（KRaft，3 broker），topic 16 分区、峰值 4k msg/s，消费组 8 实例，单条消息的业务处理分四步：

1. MySQL 8.0 写业务表（订单状态流转）；
2. 同步调下游 WMS 锁库存（RPC，P99 约 180ms）；
3. 同步调物流取号（RPC，P99 约 320ms）；
4. 发一条站内通知（走 outbox）。

幂等键是 biz_id（订单号 + 事件类型），用唯一索引挡重复写业务表。这套方案在「整条消息重复投递」的场景下没问题，但处理进行中被 rebalance 踢出这个窗口，我们一直没有一个被验证过的工程方案。

现象

去年一次 broker 扩容触发滚动重启，消费组 8 实例里有 3 个被踢出。事后从日志里捞到的数据：

• 3 个实例里，2 个实例有「步骤 1 已写库、步骤 2 RPC 已发出但响应未收到」的中间态；
• 其中 1 条消息，WMS 侧确认库存已扣，但消费端日志里步骤 2 显示「timeout」；
• 恢复后新实例重新消费这条消息，幂等表挡住了步骤 1 的重复写，但步骤 2 又调了一次 WMS，WMS 侧幂等键是它自己的，扣了两次库存；
• 最后靠人工对 WMS 流水、手动冲正才救回来。

复盘时发现：我们团队没有一张「中间态表」，所有状态都靠日志和 RPC 侧流水对出来，这在 8 实例 × 16 分区的规模下根本对不全。

已尝试的排查与结果

1. 调大 session.timeout.ms（默认 45s → 120s）：rebalance 窗口变宽，但被踢实例上正在处理的消息依然可能在 120s 内走到「半完成」，问题只是概率下降，没有消失。
2. 把四步改成「先全部 RPC 再统一写库」：步骤 2、3 的 RPC 没有本地事务可回滚，先调后写反而让「RPC 成功但写库失败」的窗口变大，放弃。
3. 在消费端加一个「处理中标记」字段到业务表：步骤 1 写库时标记 status=PROCESSING，完成后改 status=DONE。问题是：步骤 2、3 的中间态没有落任何地方，恢复 worker 看到 PROCESSING 也不知道该从哪一步续，只能整条重跑，于是又回到「WMS 扣两次」的坑。
4. 考虑用 Kafka 事务（exactly-once）把 DB 写和消息原子化：但步骤 2、3 是外部 RPC，不在 Kafka 事务边界内，exactly-once 不解决外部副作用重复的问题。

期望得到的答案形态

我不想要一篇「幂等的重要性」综述，想看到具体到表结构和判定规则的方案：

1. 中间态表的 schema：状态字段怎么枚举（比如 RECEIVED / DB_WRITTEN / WMS_CONFIRMED / LOGISTICS_CONFIRMED / NOTIFIED / DONE / ROLLED_BACK）？版本号还是状态机？乐观锁还是 CAS？恢复 worker 用 SELECT ... FOR UPDATE 还是 UPDATE ... WHERE status = ?？
2. 回滚 vs 前滚的判定规则：恢复 worker 看到 DB_WRITTEN 状态时，怎么决定是「回滚业务表 + 冲正 WMS」还是「跳过步骤 1、继续执行步骤 2」？哪些状态适合回滚、哪些适合前滚？判定依据是什么（RPC 侧是否有查询接口？业务表是否可逆？）？
3. 恢复 worker 和正常消费的竞态：rebalance 后新实例可能立刻重新消费同一条消息，恢复 worker 同时也在处理它，怎么保证两者不冲突？是「恢复 worker 优先、新实例跳过 PROCESSING 状态的消息」还是反过来？
4. 有没有人踩过「回滚时发现 WMS 已经冲正不了」（下游不支持反向操作）的坑？你们的兜底是什么——人工工单、还是预生成冲正凭证？

我引用三条我觉得相关的站内内容，希望回答者能看到上下文：

• 讨论帖 1365《幂等的判定依据到底是「业务状态机」还是「消息/请求 ID」？》——我认同状态机是更可靠的判定依据，但「判定依据」和「中间态落盘 + 恢复规则」是两层事；
• 提问 1367《Kafka 消费失败后「延迟 N 分钟重投」的幂等键设计》——那个问题聚焦「重试消息共用幂等键」，我这个问题聚焦「rebalance 导致的中间态」，场景不同；
• 讨论帖 742《消费位点 offset 到底算不算「已处理完成」？》——我认同 offset 不等于完成，但「不等于完成」之后，中间态该落在哪、怎么恢复，那一帖没有展开。

期待看到具体表结构、状态枚举、判定伪代码，以及真实踩坑后的修正方案。