Kafka 事务 + Debezium 投递下游 MySQL，at-least-once 重复下消费端幂等怎么做

【背景】 我们做账户余额变动这条链路：Kafka 3.5（3 broker），topic account-credit 24 分区，生产端用 transactional producer（PID 前缀 acct-，transaction.timeout.ms=60000）。业务路径是「读账户表 → 算新余额 → 写账户表 + 写 outbox 表（同库同事务）→ Debezium CDC 把 outbox 投递到 Kafka」。消费端 12 实例消费 account-credit，做两件事：写下游对账表（MySQL 8.0）+ 发短信通知。

【现象】 Debezium 是 at-least-once 投递，下游偶发收到重复消息（同一条 outbox 记录被投递 2 次，单 msgKey 的重复率我们采样到约 0.3%）。我们消费端原本没有幂等，直接后果：对账表出现重复行、短信重复发送（客诉 3 起）。

【已尝试的排查与结果】

1. 给对账表加 (bizId, msgKey) 唯一键，靠 DB 唯一约束去重——能挡住重复落库，但发短信这一步在 insert 之前已经执行了，挡不住，重复短信照发。
2. 想加一张「已处理消息表」存 (msgKey, processedAt)，先查表再处理——但「查表」和「业务处理」不在同一个事务里，高并发下两条相同 msgKey 几乎同时进来，都查不到、都处理了，去重失效（单 msgKey QPS 峰值 50+）。
3. 考虑用 Redis SETNX(msgKey, 1) 做前置去重——但 Redis 与 MySQL 跨存储，Redis 写成功而 MySQL 失败时会「吞消息」，等于把重复问题换成了丢失问题，不敢上。

【期望得到的答案形态】 希望有同学在「下游是 MySQL（不是 Kafka sink）+ Debezium at-least-once」这个前提下，给一套具体到代码结构和索引设计的幂等方案：

1. 消费端幂等的正确姿势是什么：去重表 / DB 唯一键 / 状态机，三选一还是组合？各自适合哪种副作用场景？
2. 「先发短信再落库」这类外部副作用（side-effect）和幂等落库的执行顺序怎么排，才能既不漏发也不重发？副作用本身不可回滚时怎么兜底？
3. 去重表 / 唯一索引在单 msgKey 高并发（50+ QPS）下的锁竞争与性能怎么控制？有没有比「查表 + insert」更稳的写法（比如靠唯一键 insert 冲突来天然去重）？
4. 有没有人贴一下「消费端幂等 + 副作用去重」的最小可复现代码骨架（Java / Spring 事务），以及配套的监控指标（重复率、去重命中率、副作用补偿次数）。

如果能给一个最小 PoC（1 个 topic / 2 实例 / 注入 0.3% 重复投递 + 短信 mock）就更好。