重试策略

背景 我主导过 5 个分布式系统架构升级，处理过 37 次生产级重复消费事故。最惨的一次是某支付系统因未校验幂等键，导致 12 万笔订单被重复扣款。这促使我系统性整理幂等性设计的边界问题。 原理 幂等性本质是消除副作用的数学保障，在分布式系

«结论先行：MySQL 返回的 "1213 (ER_LOCK_DEADLOCK)" 和 "1205 (ER_LOCK_WAIT_TIMEOUT)" 在 InnoDB 里是两个完全不同的失败路径——前者是「检测器选中了你、立即回滚、锁当场释放

«结论先行：客户端重试策略（退避 + jitter + 次数上限）写进 fetch 封装只需 20 行代码，但没有任何指标能回答「这套重试到底救了多少请求、又放大多少流量」，它就是一台黑盒。我在 B 端 SaaS（React 18.2 +

«结论先行：错误响应体不是「给人看的道歉信」，而是「给客户端机器读的决策信号」。服务端怎么设计这个 body，直接决定了客户端能不能正确做三件事——该不该重试、该不该降级、该不该把提示透传给用户。我做了 10 年技术 PM，经手过 3 起「

哪些错误码可以重试：一份带具体参数和预算公式的 SDK 重试决策清单 «结论先行："这个错误码能不能重试"不是一个网络问题，而是一个产品语义问题。同一个 504，对"查询订单"是安全的，对"创建订单"可能就是重复扣款。我 5 年技术 PM

结论先行 2024 年 Q3 我们一个 B 端数据平台的网关 502 比例从基线 0.4% 飙到 3.2%，值班同学以为是网关挂了。排查后发现根因在前端：请求层没有超时上限、失败后无条件自动重发，在弱网场景下形成了「请求堆积 → 网关过载