同一个请求被重试了 3 次：你们的幂等设计到底做在哪一层？

【背景】

高并发场景下，幂等不是一个"加个唯一索引"就能收工的事。网络抖动、客户端 SDK 重试、网关重试、MQ 重投——同一个业务请求可能以不同形态到达后端 2~5 次。我见过最离谱的一次：客户端重试 + 网关重试 + MQ 重投叠加，一笔订单被处理了 4 次，其中 2 次来自不同 IP、不同 traceId，DB 层唯一索引根本拦不住（因为每次重试都重新生成了 order_no）。事后复盘，根因不是"谁重试了"，而是幂等边界没有统一定义。

【常见分歧 / 几种做法】

1. DB 唯一索引派：幂等的最终兜底在存储层，业务键做唯一约束，重复写入直接拒绝。简单、可靠、不依赖外部组件。但坑在于：唯一键怎么定？如果每次重试都重新生成 ID 或流水号，唯一索引就形同虚设。
2. Redis 幂等 Token 派：请求前生成 token 存 Redis（TTL 5~10 min），处理时 SETNX 消费。灵活、可跨服务复用。但追问两个问题：Redis 挂了怎么办？token 过期了但请求还在飞行中呢？
3. 网关层统一拦截派：在 API Gateway 做 (tenantId + bizType + bizId) 去重，后端无感。优点是后端不用改；缺点是网关要维护"哪些接口需要幂等"的白名单，而且网关本身挂了幂等就没了——你等于把单点从后端搬到了网关。
4. 应用层状态机派：不依赖任何外部去重，用状态机保证"同一状态只能被驱动一次"（PENDING→PAID 只能发生一次，PAID→PAID 直接 no-op）。最彻底，但状态机建模成本高，业务复杂时状态爆炸。

【我的倾向与理由】

我倾向于分层做，状态机是最终兜底：

• Redis token 做快速拦截（挡住 99% 的重复请求，省掉下游计算）；
• DB 唯一索引做存储层防线（Redis 挂了也能兜住）；
• 状态机做业务语义兜底（前两层都漏了，至少不会把 PAID 再变成 PAID 两次）。

三层各管各的故障模式。但说实话，三层全做的团队我见过不超过 20%，大多数团队只做其中一层就觉得自己"幂等了"。问题不在于做哪一层，而在于你有没有想清楚：你的幂等 key 到底是什么？是请求维度的（requestId）还是业务维度的（orderId + action）？ 这两个维度的幂等边界完全不同，混着用就会出上面我说的那种"4 次都过了"的事故。

【想听大家聊聊】

1. 你们团队目前幂等做到哪一层了？是"觉得够了"还是"做到哪算哪"？
2. 有没有被重试坑过、事后才补幂等的真实案例？补的时候花了多大代价？
3. 状态机方案在你们的业务里落地成本有多大？是"值得"还是"过度设计"？
4. 幂等 key 你们用 requestId 还是业务键？有没有踩过"key 选错了"的坑？

欢迎带着具体场景来聊，越具体越好。