打开网易新闻 查看精彩图片
Retries 被当成系统故障时的救命稻草——失败了？再试一次。再试一次。这种直觉式的解法写进代码只需要两行，却在流量高峰时变成定时炸弹。
工程师 Yuvraj S 在博客中复盘了一个典型场景：下游服务响应变慢，上游系统自动触发重试，请求量瞬间翻三倍。下游还没恢复，就被自己的"保护机制"冲垮。「Retries don't just handle failure — they amplify it under load.」
问题藏在"静默"二字里。重试逻辑通常埋在 SDK 或框架底层，开发者甚至意识不到它在运行。直到监控面板飘红，才发现某个接口的 QPS 从 200 飙到 600，而成功率从 99% 跌到 12%。
更隐蔽的是指数退避的陷阱。很多人配置了退避策略，却忘了设置上限——退避时间越拉越长，连接池被占满，正常请求反而排队饿死。Yuvraj 提到一个案例：某团队把最大退避设成 64 秒，结果故障期间 80% 的线程都在睡觉。
评论区有人贴出自己的修复方案：给重试加熔断，错误率超过阈值直接短路。底下回复："我们试过，熔断阈值调了 7 版才稳定。"
热门跟贴