幂等的判定单位到底该是「消息」还是「业务操作」？一次退款重试让我两败俱伤

背景 上周我们一条退款链路出了一次典型的「幂等设计翻车」：退款服务对同一笔订单 R-20240618-000713 做了三步副作用——① 调支付渠道冲正（外部 API）、② 写账务流水（MySQL 唯一键 order_no + biz_type）、③ 发站内信通知。第 ② 步因 DB 慢查询超时失败，消费者按 at-least-once 重试。重试时我们幂等键用的是 Kafka 的 (topic, partition, offset) + 消费组实例 ID，于是第 ① 步被判定为「新消息」又调了一次渠道冲正，第 ② 步这次成功了。结果：渠道侧两笔冲正，账务侧一笔流水——两边对不上，人工对账补了两天。

常见分歧（我在团队里听过三种典型立场）

1. 消息级幂等：以 messageId / (partition, offset) 为去重键，Redis SETNX + TTL（通常 24~72h）。优点是简单、无业务侵入；缺点是重试换了消息 ID 就失效，且「同一笔业务、两次投递」和「两次投递、同一笔业务」分不开。
2. 业务级幂等：以业务主键（orderNo + actionType）为去重键，落 DB 唯一约束。优点是语义正确、天然抗重放；缺点是每加一个副作用都要显式声明幂等键，且「部分成功 + 重试」时键已存在，新步骤会被跳过（上面例子里如果把 ① 也挂到 orderNo 键下，重试时 ① 会被跳过，账务侧反而缺数据）。
3. 混合：消息级做粗筛挡重复投递，业务级做细筛挡语义重复，两层都过才执行。工程上最稳，但实现成本最高，且两层键的 TTL / 清理策略要分别维护。

我的倾向与理由 我倾向 以业务操作为幂等键的「细粒度状态机」，而不是单纯的业务主键去重。具体做法：每笔业务操作有一个 outbox 表，记录 (biz_key, step_seq, step_status, idempotent_payload)，每个副作用步骤对应一行；执行前先查该行，SUCCESS 则跳过，PENDING 则重新执行（要求该步骤本身可重入），FAILED 走补偿。渠道冲正这种外部调用，把渠道返回的 requestId 也存进 outbox，重试时优先用同一 requestId 调渠道的「查询」接口确认状态，而不是盲目重调。这套东西不新，本质是把 Saga 的补偿语义和幂等键绑在一起，但好处是「部分失败 + 重试」不再二选一。

代价也得说清楚：每加一步副作用要改表、改代码，团队里新同学上手成本高；outbox 表需要清理策略（我们按 biz_key 分区 + 90 天归档）；而且它只保证「同一业务操作」的幂等，跨业务操作的乱序（比如退款和改单并发）还是得靠业务层加锁。

想听大家

1. 你们生产上用的判定单位是什么？纯消息级 / 纯业务级 / 混合？各自的「翻车案例」是什么？
2. 部分失败重试时，你们怎么保证「已成功的步骤不重做、未成功的步骤能补做」？是 outbox 状态机、TCC，还是干脆人工介入？
3. 外部 API（支付渠道、短信网关）的幂等，你们是要求对方支持 requestId 复用，还是自己维护一张「调用日志」表做对账？
4. 有没有人踩过「幂等键本身设计错」的坑——比如用 UUID 当键、用时间戳当键——导致幂等形同虚设？

欢迎贴具体配置、表结构、踩坑时间线，我这边 outbox 表的 DDL 和清理 SQL 可以拆出来发一篇。