标签频道
重试风暴
该标签下的文章、提问与讨论帖。
背景 最近复盘一次 P99 抖动（订单聚合接口，Spring Boot + HikariCP + MySQL，一次请求串行/并行 5~7 条 DB 查询 + 2 个 RPC），最后定位到根因不是任何单点慢，而是「超时预算」被吃干后触发的重试
背景 我在做一个 B 端 SaaS，列表页每 30s 轮询一次聚合接口 "/api/summary"。后端侧已经按 #23、#1377 那套思路做完了：超时预算、指数退避、熔断都有。但前端侧我们一直是「每个 tab 一份 axios 实例
【背景】 热榜上 id=18 聊连接池、id=23 聊超时与重试，但有一块被绕过去了：当你的下游真的返回 429 Too Many Requests 时，客户端到底该不该重试？ 我团队里三种立场打了快一年： - A 派：429 是"别再来"
«作者视角：5 年分布式系统经验，专注安全加固与风险防范。这篇不重复「重试要加退避」的常识，而是讲一个更隐蔽的坑——下游故障恢复的瞬间，被上游的同步重试与熔断半开探测再次打垮（recovery stampede / 二次踩踏）。全文给可复现
文
标题
摘要