Kafka consumer 重读消息后多步业务操作（扣款→记账→外部通知）的"半完成态"怎么幂等续做：幂等键落哪一步、TTL 取多少、MySQL 侧用什么结构兜底？

背景

15 年全栈，近两年主责支付/结算链路的消息消费端。Kafka 3.4（3 broker KRaft），topic settlement-event 32 分区，消费组 6 实例，日均 4200 万条。消费逻辑是单条同步处理（非攒批），每条消息内部做三步串行业务操作：

1. 扣款：MySQL 8.0 写 account_balance 表（UPDATE ... SET balance = balance - ? WHERE account_id = ? AND balance >= ?）
2. 记账：写 ledger_entry 表（INSERT，含唯一键 biz_order_id + direction）
3. 外部通知：调风控/清结算 RPC（P99 ≈ 800ms，偶发超时 3s+）

offset 提交策略：三步全部成功后 consumer.commitSync(offset + 1)。

现象（真实踩过的坑）

上个月一次 broker 网络抖动（约 12s），6 个实例中有 3 个在第三步 RPC 返回后、commitSync 前断连，broker 侧 offset 未推进。重启后从旧 offset 重读，这 3 条消息的三步全部已经执行过——但我们的幂等设计只覆盖了第二步（ledger_entry 的 biz_order_id 唯一键）。

结果：

• 第一步重复扣款（account_balance 没有幂等键，纯 UPDATE 无 WHERE 守卫）
• 第二步被唯一键挡住，正确跳过
• 第三步 RPC 重放（下游不幂等，风控规则被重复触发，误冻 2 个账户 3 分钟）

对账脚本 T+1 才发现，人工回滚 3 条扣款 + 联系风控解冻。总损失不大，但暴露了一个设计盲区："幂等"被分散在三个步骤里，每步各管各的，没有一个统一的"这笔业务做到哪了"的状态锚点。

已尝试的方案与问题

方案 A：每步各建幂等键

• 扣款：加 WHERE idempotency_key = ?（需改表结构，account_balance 是高频热点表，加唯一索引怕影响写入吞吐）
• 记账：已有（biz_order_id + direction 唯一键）
• 通知：在 notification_log 表加 request_id 唯一键
• 问题：三张表、三个键、三套 TTL 策略，维护成本高；且如果第一步成功但第二步失败，你无法从"三张表各自查"快速判断"这笔业务到底卡在哪一步"——排查时要跨 3 张表 + 1 个 RPC 日志拼凑。

方案 B：引入本地事务表（outbox 的变体）

• 新增 biz_operation 表：(biz_id PK, status ENUM('INIT','DEBIT_DONE','LEDGER_DONE','NOTIFY_DONE','DONE'), idempotency_key UNIQUE, created_at, updated_at)
• 每步完成后 UPDATE status，重读时先查 status 决定从哪步续做
• 问题：
  1. 每多一步就多一次 DB 写，P99 延迟增加约 1~2ms（可接受，但想确认量级）
  2. status 的 UPDATE 和业务操作的 UPDATE 不在同一个 MySQL 事务里（跨表但同库，可以放同一事务；但如果"扣款"和"状态推进"要原子，那 account_balance 和 biz_operation 必须在同一事务——这没问题，同库）
  3. TTL / 清理策略：biz_operation 表会持续增长，按什么维度归档？按 created_at 定期迁移到冷表？还是按 status = 'DONE' AND updated_at < NOW() - INTERVAL 30 DAY 直接删？删除后如果有一条极晚的重读（比如 offset 卡在 30 天前）怎么办？
  4. 并发安全：同一 biz_id 被两个 consumer 实例同时处理（rebalance 窗口），靠 biz_operation 的 INSERT ... ON DUPLICATE KEY UPDATE 拿锁？还是 SELECT ... FOR UPDATE？

方案 C：Kafka 事务（transactional producer）+ isolation.level=read_committed

• 看了社区里 @江星河 自己写的文章（id=1505）关于 PID+epoch 围栏和 transaction.timeout.ms 的讨论，觉得 Kafka 事务解决的是 producer 端 exactly-once，对我这个"consumer 端多步业务操作"的场景帮助有限——因为我的三步里有 RPC 调用，不可能包在 Kafka 事务里。

期望得到的答案形态

不追求"银弹"，想收集不同规模团队的实际取舍：

1. 幂等键的粒度：你是"每步一个键"还是"一笔业务一个状态机"？状态机的状态是业务自定义还是框架提供（如 Sagas / Temporal）？
2. TTL 与 offset retention 的对齐：你的 offsets.retention.minutes 是多少？幂等键 / 状态表的保留期是否 ≥ offset retention？有没有人踩过"幂等键过期了但 offset 还在"的窗口？
3. RPC 不幂等怎么办：外部通知这类"无法幂等重放"的下游，你们是在 consumer 侧做"先记后发 + 对账补偿"，还是让下游自己加幂等？谁的责任边界？
4. 半完成态的排查效率：有没有人做过"一条命令查清这笔业务卡在哪一步"的工具？biz_operation 表 + 一个 CLI？还是靠 ELK 串日志？

引用

• id=603《Kafka 攒批落库：offset 提交与批量 flush 谁先谁后，决定了你是丢还是重》——那篇讲的是攒批场景的 commit/flush 顺序，我的场景是单条同步但问题本质相同：offset 提交和业务完成之间的窗口。
• id=760《K8s 滚动更新时 Kafka Consumer 优雅停机，in-flight 消息与 offset 提交竞态如何消除》——优雅停机是触发重读的一个场景，我的问题是重读之后怎么安全续做。