备案站点的超时设置与重试策略治理

没有超时的调用，等于把命运交给对方

线上最隐蔽的一类故障是这样发生的：某个第三方接口不返回也不报错，只是一直挂着。你的线程卡在那里，连接池慢慢被占满，几分钟后整站所有接口一起变慢——根因只是一处漏配的超时。很多 HTTP 客户端和数据库驱动的默认超时是「无限等待」，这是最危险的默认值。

关键要点

• 每一次跨进程调用都必须显式设置超时，不要依赖默认值。
• 超时预算要从入口往内拆：上游超时必须大于下游各段之和，否则会产生「幽灵请求」。
• 重试只对瞬时故障有效；对已经过载的下游，重试是压垮它的最后一根稻草。
• 重试的前提是幂等，给非幂等接口加重试等于批量制造重复数据。

超时的三个层次

层次	典型取值	漏配的后果
连接超时	1～3 秒	握手阶段卡死，连接池被占满
读写超时	按下游 P99 加余量	线程被长期占用，吞吐归零
整体业务超时	用户可接受的上限	用户早已离开，服务器还在算

三者缺一不可：只配连接超时挡不住「连上了但不返回」，只配读写超时挡不住「握手就卡住」。反向代理层也要同步配置，否则应用侧断了、代理侧还在等，配置见 Nginx 反向代理配置。

超时预算：从外往内拆，而不是各配各的

假设入口给用户的承诺是 3 秒，那么这 3 秒要在链路上分配完：网关 3 秒 → 服务 A 2 秒 → 服务 B 800 毫秒 → 数据库 300 毫秒，每层都要为自己的处理和重试留出余量。

最常见的反模式是上游超时比下游还短：入口配 2 秒，下游配 10 秒。结果入口早就返回失败了，下游还在继续执行并占着连接和 CPU，这类无人认领的「幽灵请求」在故障时会成倍消耗资源。

取值要基于实测的 P99 而不是平均值——平均值 200 毫秒的接口，P99 可能是 2 秒，按平均值配超时会让正常请求被大面积误杀，压测取数方法见 性能优化与压测。

重试的四条规则

1. 只重试幂等操作：查询、或带幂等键的写入。
2. 只重试可重试的错误：连接失败、503、网关超时；参数错误这类 4xx 重试多少次都是错。
3. 指数退避加随机抖动：1 秒、2 秒、4 秒，并在每次等待上叠加随机偏移，避免所有客户端在同一毫秒集体重试。
4. 次数封顶并计入超时预算：通常 2～3 次，且总耗时不能超过上游给的时间窗口。

第 3 条的抖动常被省略，后果是「同步波峰」：下游抖动一次，成千上万个客户端同时失败、又同时在 1 秒后一起重试，把刚要恢复的下游再打死一次。

重试风暴：一个被严重低估的放大器

如果链路上每一层都配了 3 次重试，三层串起来，下游收到的请求量会被放大到原来的约 27 倍。故障期间压垮系统的往往不是用户流量，而是自家的重试流量。

三个对策：

• 只在一层重试：通常选最靠近故障点的那一层，其余层只做快速失败。
• 配合熔断：错误率超阈值后直接短路，不再产生新的重试，做法见 限流、熔断与服务降级。
• 设重试预算：限制重试请求占总请求的比例（例如不超过 10%），超出部分直接失败，把重试量从「乘法」变回「加法」。

幂等键：让重试变得安全

重试安全的前提是服务端能识别「这次和上次是同一个请求」。落地方式是客户端生成一个唯一请求 ID 随请求带上，服务端用唯一索引或去重表保证同一个键只真正执行一次，重复到达时直接返回首次结果。

这套机制和消息消费端的去重是同一个思路，可以共用同一张去重表，见 消息队列与异步任务运维。

别忘了连接池

超时和连接池是一对：超时越长，池被占满得越快。并发占用量约等于 QPS 乘以平均响应时间，下游从 100 毫秒劣化到 2 秒，占用量就是 20 倍，池必然被打穿。所以调长超时前，先确认连接池能不能扛住对应的并发，也要给不同下游做资源隔离，避免一个慢依赖吃掉全部连接。

上线与验证

改超时是高风险变更：配小了会误杀正常请求，配大了会在故障时放大影响。建议先灰度一小部分流量观察错误率，见 灰度发布与蓝绿部署。上线后要长期盯三条曲线——超时率、重试率、下游 P99，指标采集见 可观测性建设，告警配置见 备案网站监控告警体系。演练与复盘流程见 故障响应、复盘与 SLO 实践。

常见坑

• 使用客户端默认的无限超时：一个慢依赖拖垮全站。
• 上游超时小于下游：制造大量幽灵请求。
• 每层都重试：小故障被放大成雪崩。
• 给非幂等写接口加重试：重复下单、重复扣款。
• 固定间隔重试：形成同步波峰，下游反复被打死。

常见问题

超时到底设多少秒合适？

没有通用数值，但有通用方法：取该调用实测的 P99 耗时，乘以 1.5～2 倍作为读写超时，同时确保它小于上游分配给你的时间预算。两个条件冲突时，说明这段链路本身太慢，应该优化而不是调大超时。

重试次数设几次比较好？

多数场景 2～3 次足够。再多的重试对瞬时抖动没有额外收益，却会显著放大故障期间的流量。前提是整条链路只有一层在重试。

为什么重试一定要加随机抖动？

没有抖动时，所有客户端的重试时刻会对齐，形成周期性的流量尖峰，下游刚恢复就被再次打垮。加入随机偏移能把重试流量摊平到一段时间内。

查询接口是不是可以随便重试？

查询通常幂等，但代价不为零：重试会占用下游连接和 CPU。下游已经过载时，查询重试同样会加剧雪崩，所以仍然需要次数上限和熔断保护。

资料来源

主流 HTTP 客户端、RPC 框架与数据库驱动官方文档中关于连接超时、读写超时与重试策略的公开说明，以及指数退避、抖动与重试预算等通用工程实践资料。本文为通用运维说明，仅供参考，具体以实际框架与依赖情况为准。