背景
我在维护一个订单履约系统，链路大致是：
网关(去重层) → 订单服务(创建) → MQ(事件) → 履约/库存/结算(消费)
去年一次大促复盘，根因不是"幂等没做"，而是幂等做了三遍、三遍口径不一致：
- 网关层：基于
X-Idempotency-Key（客户端生成的 UUID）做 Redis 去重，TTL 设 24h； - 订单服务：基于
orderId（自增）做唯一索引，天然幂等； - 履约消费端：基于
messageId做去重表（MySQL，TTL 7 天清理）。
结果：一次网关 Redis 抖动（主从切换 3 秒），同一个请求带着同一个 UUID 穿透到订单服务；订单服务因为 orderId 是自增的，生成了一条新订单；MQ 投递了事件，消费端用 messageId 去重成功——但此时下游已经多扣了一次库存。
三套幂等，三套 key，三套 TTL，三套"谁说了算"。最终我们花了两周才把口径对齐。
常见分歧（我在不同团队见过至少四种做法）
| 方案 | 幂等判定方 | 幂等键来源 | 典型 TTL/保留 | 适用场景 | |------|-----------|-----------|-------------|---------| | A. 调用方生成 key，被调用方存去重表 | 被调用方 | 客户端 UUID / requestId | 7–30 天 | 支付、下单等"一次性"操作 | | B. 被调用方基于业务语义天然幂等 | 被调用方 | 业务主键（订单号、流水号） | 永久（唯一索引） | 状态机推进、结算 | | C. 网关/接入层统一去重，后端不管 | 网关 | 客户端 UUID + 接口路径 | 分钟~小时级 | 读多写少、防重复提交 | | D. MQ exactly-once + 消费端无幂等 | 消息中间件 | 事务 ID / messageId | 依赖 broker 语义 | 纯 MQ 消费、无外部调用 |
我的观察：大多数团队不是"缺一种"，而是"叠了两种以上、且不知道哪层兜底"。
我的倾向（以及为什么）
我倾向于一个原则：幂等的"最终判定权"应该归被调用方，且优先用业务语义（方案 B）；技术层幂等（方案 A/C）只做"快速短路"，不承担正确性。
理由有三：
- 业务语义幂等是"结构性的"：订单状态机
CREATED → PAID → SHIPPED，重复PAID→SHIPPED直接返回成功，不需要查任何去重表，没有 TTL 问题。 - 技术层幂等是"缓存性的"：UUID 去重表本质是缓存，TTL 一过就失效；Redis 主从切换、MQ rebalance、网关扩缩容——任何一层抖动都可能让"已去重"的判定丢失。
- 叠加越多，排查越难：上面那个事故，如果只有一层幂等，复盘 30 分钟就能定位；三层叠加，光搞清楚"是哪一层放过的"就花了一天。
但我不想把它说成"方案 B 永远正确"——比如一个"发起退款"接口，业务主键是 refundId，如果客户端重复提交但 refundId 不同（每次生成新的），方案 B 就失效了，这时候你确实需要方案 A 的"请求级幂等"兜底。
实战数据补充（2026-10-20 修订）
基于后续在社区问答（#978）中收到的反馈和上线 2 个月的复盘，补充三个原帖未展开的落地细节：
1. TTL 的 key 粒度修正
最初我按 order_id × 30d 估算 Redis key 数量，但实际每个 order_id 平均产生 3.2 个 event_type（CREATED / PAID / SHIPPED / CANCEL / REFUND），真实 key 数比粗估多 22%。修正后的公式：
真实 key 数 ≈ 日均 order 数 × avg_event_types_per_order × TTL_days
把 TTL 从 30d 降到 4d（对齐业务冲正窗口 72h + 24h 安全余量），单 key 内存从 30GB+ 回落到 ~5GB——这才是"对齐业务可变更期"的真正含义，不是拍 24h 也不是拍 30d。
2. event_type 归一化：谁消费谁负责
一个隐蔽的坑：如果网关层做了事件归一化（比如把 cancel_order 和 order_cancel 都映射成 CANCEL），但 MySQL 唯一键存的是映射前的原始值，那幂等键就撞不上了——等于幂等失效但没有任何报错。
解法：枚举字典表必须落在消费端入口，而不是网关层。谁消费谁负责归一化，网关只做路由不做语义转换。
3. "冲突 → ack 跳过"分支的独立告警
当 Redis NX 命中（fast-path 拦截）或 MySQL 唯一键冲突（最终裁决）时，消费端直接 ack 跳过。这个分支的 QPS 曲线就是"幂等拦截率"的直接观测。
建议：
- 该分支单独打点（本地日志/异步批量刷，别依赖 Kafka consumer metrics 聚合——实例 OOM 重启时曲线会断崖）；
- 独立告警：单分钟 > 5 次 且 Redis P99 同时 > 20ms → P2 报警；
- 别等对账，对账是 T+1，告警是 T+0。
4. 一个尚未收口的开放问题
如果业务允许「同一 order_id 先 CANCEL 再重新 CREATED」（冲正后重建），event_type 枚举空间就不闭合了——PK 用 (order_id, event_type) 挡不住「CANCEL → CREATED → CREATED」这种合法序列里的第二次 CREATED。
这种场景下：
- 幂等键的粒度是不是要再加一层
sequence（即(order_id, event_type, seq)）？ - 还是说这种场景根本不该走幂等键，而该走状态机 guard 条件（
CREATED只能从CANCELLED或初始态迁移，重复CREATED直接 guard 拒绝）？
我倾向于后者——把"能不能做这个操作"的判定完全融进状态迁移的 guard 里，幂等键只负责"同一笔操作别重复执行"，不负责"这笔操作合不合法"。但还没有生产验证，想听听大家有没有踩过这个边界。
想听大家聊的
- 你的系统里，幂等到底做了几层？哪层是"真兜底"、哪层只是"快速短路"？ 能不能用一句话描述清楚每层的职责边界？
- TTL 怎么定的？ 去重表/缓存保留 7 天、30 天、还是永久？依据是什么（合规要求？业务窗口？存储成本？），有没有因为 TTL 设短/设长踩过坑？
- MQ 消费端，你们用 messageId 去重还是业务 key 去重？ 如果是 messageId，rebalance 导致同一条消息被两个 consumer 各消费一次（极端 case），你怎么兜？
- 有没有人尝试过"幂等即状态机"的设计——把幂等判定完全融进状态迁移的 guard 条件里，不单独维护去重表？效果如何，有没有遇到"guard 条件本身有 bug"的情况？
- 网关层去重，你们用 Redis 还是本地 Caffeine + 版本号？ 网关无状态多副本下，"同一个 key 先后打到两个实例"这个窗口，你们怎么处理的？
- event_type 的枚举空间谁来管？ 裸字符串 vs 字典表 vs 状态机 guard，你们的实践是哪种？
抛砖引玉，期待听到不同规模、不同技术栈下的实践。特别是"幂等做了但口径没对齐"的踩坑故事，比"我们做得很好"的分享更有价值。