【背景】 做了 15 年分布式系统，幂等大概是"人人都懂、但每个人做法都不一样"的典型。我见过三种极端：
- A 团队：网关层用 Redis SETNX（key = userId + path + md5(params)），TTL 5 分钟，应用层完全不管幂等。
- B 团队：网关不做，应用层维护一张 dedup 表（biz_key + request_id 联合唯一），DB 层再加一道唯一索引兜底，三层都有。
- C 团队：只在 DB 层靠唯一索引 + INSERT IGNORE，网关和应用层"裸奔"。
三种都能"跑通"，但线上出问题时表现完全不同：A 的 Redis 一抖，重复请求直接打到业务；B 的 dedup 表半年后涨到 2000w 行，清理策略没人敢动；C 的 INSERT IGNORE 把"真正的重复写入"和"并发撞唯一键"混在一起，日志里根本分不清。
【常见的几种分歧】
-
幂等 key 的粒度：是 (userId, endpoint) 还是 (userId, endpoint, hash(关键参数))？后者更精确但参数一变 key 就变，等于没防住。
-
TTL 怎么定：5 分钟够吗？如果用户 10 分钟后手动刷新，算重复吗？如果消息中间件重投（Kafka rebalance 窗口可达分钟级），5 分钟 TTL 根本兜不住。
-
幂等表 vs 幂等 token：
- 幂等表：服务端维护，客户端不需要配合，但表会膨胀。
- 幂等 token：客户端生成（或网关下发），服务端校验后删除——无状态、无膨胀，但要求客户端"配合"，跨端（App / Web / 第三方）很难统一。
- 你们线上到底用哪个？混合用？
-
幂等"成功"的定义：请求处理完写 DB 成功，算幂等成功？还是等下游 MQ 也 ack 了才算？如果"写 DB 成功、发 MQ 失败"，重试时是"重发 MQ"还是"整个请求重放"？
【我的倾向与理由】
我倾向于 "主幂等放应用层，网关做防重放，DB 做最后防线"的三层结构，但有一个关键纪律：幂等表必须有生命周期管理。
- 网关层：只做"防网络抖动导致的重复 TCP 重传 / 客户端重发"，key = (userId, path, hash(body))，TTL 30s~2min，够用。
- 应用层：业务语义最清楚的幂等在这里做。比如"同一订单号只能创建一次"，用 biz_key（订单号）做唯一键，dedup 表 TTL 7 天 + 每天凌晨清理过期行。
- DB 层：唯一索引兜底，但 INSERT IGNORE 的日志里必须打出"是幂等命中还是并发撞键"（用 INSERT ... ON DUPLICATE KEY UPDATE + 影响行数区分）。
核心原则：幂等的"语义"归业务，幂等的"机制"归基础设施。别把"订单不能重复创建"这种业务约束塞进网关的 Redis 里——那是业务逻辑，不是网络问题。
但我最想听大家聊的是：你们线上的"幂等表"到底多大？清理策略是什么？有没有"幂等表爆炸"过（千万级甚至上亿行，没人敢清）？
【想听大家在什么场景下怎么选】
- 你的系统里，幂等 key 的粒度是怎么定的？有没有"参数组合爆炸"导致 Redis 内存暴涨的经历？
- 幂等表的清理策略：按 TTL 删？按业务状态（已完成/已取消）删？还是"不清"？
- 消息中间件重投场景（Kafka rebalance、RocketMQ 重发），你们的幂等窗口够不够？有没有"重投时幂等已过期"导致重复写入的事故？
- 跨端（App / Web / 第三方 API）的幂等，你们怎么统一？还是说"各端各管各的"？
- 一个尖锐问题：如果"幂等表"和"业务表"在同一个 DB 实例，幂等表的读写会不会反过来影响业务表的 P99？你们把幂等表放独立实例了吗？
这个问题没有标准答案，但"没想过"和"想过但没做"是两个完全不同的风险等级。你们现在在哪一档？
0赞
0收藏
0楼层