在做网络相关的开发时，超时问题是绕不开的一环。无论是调用第三方接口、访问数据库，还是服务之间的RPC通信，都可能出现请求迟迟没有响应的情况。超时本身不可怕，可怕的是没有应对预案：用户反复点击、数据重复提交、服务雪崩，往往都是超时处理不当引起的。本文围绕重试机制和备用路由这两个核心手段展开，聊聊怎么把超时造成的损失降到最低。
网络超时的成因与超时时间的合理设置
先弄清楚超时是怎么产生的。一次网络请求的时间主要由几部分组成：客户端组装数据的时间、网络传输的往返时延（RTT）、服务端处理时间以及响应返回的时间。任何一环变慢，整体耗时就会上升。常见原因包括网络抖动、服务端负载过高、连接池耗尽、DNS解析缓慢，以及中间代理层排队等。
面对超时，第一件事不是急着加重试，而是检查超时时间设置得是否合理。很多默认值并不适合生产环境，比如某些HTTP客户端默认超时是无限等待，一旦对端hang住，调用方的线程就会被长期占用。一般建议把超时拆成连接超时和读超时分别设置：连接超时可以设得短一些，比如1到3秒，因为TCP握手失败大概率是网络或服务不可用；读超时要结合服务端的正常响应时间来定，可以参考历史耗时的P99再留出余量。
// 以Java的OkHttp为例，拆分设置连接超时与读超时
OkHttpClient client = new OkHttpClient.Builder()
.connectTimeout(3, TimeUnit.SECONDS) // 连接超时3秒
.readTimeout(10, TimeUnit.SECONDS) // 读超时10秒
.writeTimeout(10, TimeUnit.SECONDS) // 写超时10秒
.retryOnConnectionFailure(true) // 连接失败时内部自动重连
.build();另外要注意超时的传递性。在一个调用链里，如果上游的超时时间比下游还长，一旦下游卡住，上游的请求会堆积，最终拖垮整个服务。比较通行的做法是让每一层的超时预算逐层递减，例如网关给服务A留500毫秒，服务A调用服务B时最多留400毫秒，这样能保证失败快速向上传递，不会形成积压。
重试机制的设计：不是简单地再发一次
重试是应对瞬时故障最直接的手段，网络抖动、偶发的服务重启，重试一次往往就成功了。但重试设计不好会适得其反：服务端已经压力过大时，大量重试等于火上浇油，这就是所谓的重试风暴。所以一个健壮的重试机制需要考虑几个关键点：哪些错误可以重试、重试几次、每次间隔多久、重试是否安全。
首先是错误分类。连接超时、连接被重置这类错误通常值得重试；而像HTTP的4xx错误（比如参数错误、鉴权失败）重试一万次也不会成功，属于不可重试错误。读超时要格外谨慎，因为请求可能已经到达服务端并执行成功，只是响应没来得及返回，盲目重试可能造成重复下单之类的业务问题。
其次是退避策略。固定间隔重试在并发场景下容易形成同步冲击，推荐使用指数退避并加入随机抖动，让重试请求在时间上打散：
import random, time, requests
def request_with_retry(url, max_retries=4):
for attempt in range(max_retries):
try:
resp = requests.get(url, timeout=(3, 10))
if resp.status_code >= 500:
raise IOError("server error")
return resp
except (requests.Timeout, requests.ConnectionError, IOError):
if attempt == max_retries - 1:
raise
# 指数退避 + 随机抖动：1s、2s、4s基础上最多再加50%
backoff = (2 ** attempt) * (1 + random.random() * 0.5)
time.sleep(backoff)最后是幂等性保障。重试的前提是同一个请求执行多次和执行一次效果相同。对于写操作，可以通过客户端生成唯一请求ID、服务端做去重记录来实现幂等，或者使用带版本号的乐观锁。没有幂等保障的重试等于埋雷，这一点在支付、订单等场景尤其重要。
- 重试次数建议控制在3到5次，过多意义不大且放大流量
- 务必设置总超时上限，避免重试本身耗尽整个请求预算
- 只对幂等操作或已做幂等处理的接口开启自动重试
- 记录每次重试的日志，便于事后分析故障特征
备用路由：单条线路靠不住就准备多条
重试解决的是瞬时抖动，但如果某个服务节点或某条网络线路彻底不可用，重试多少次都没用，这时候就需要备用路由。备用路由的核心思想是为请求准备多条可达路径，主路径故障时自动切换，常见形态有多接入点容灾、多机房部署以及服务发现层面的故障转移。
一种典型实现是维护一个地址列表，按优先级依次尝试。下面的例子展示了简单的故障转移逻辑：
package main
import (
"errors"
"net/http"
"time"
)
var endpoints = []string{
"https://api-primary.ipipp.com/v1/data",
"https://api-backup.ipipp.com/v1/data",
"https://api-dr.ipipp.com/v1/data", // 灾备节点
}
var client = &http.Client{Timeout: 5 * time.Second}
func fetchWithFallback() (*http.Response, error) {
var lastErr error
for _, ep := range endpoints {
resp, err := client.Get(ep)
if err == nil && resp.StatusCode < 500 {
return resp, nil
}
if resp != nil {
resp.Body.Close()
}
lastErr = err
}
if lastErr == nil {
lastErr = errors.New("all endpoints failed")
}
return nil, lastErr
}更成熟的方案是结合健康检查与动态摘除。通过定时探测各节点的存活状态，把连续失败的节点从路由表中暂时移除，过一段时间后再放回流量做探测恢复。很多服务发现框架本身就带这类能力，比如常用的注册中心都支持健康检查失败自动下线。需要注意的是，切换本身也要考虑幂等与请求是否已发出，避免切换路由后造成重复执行。
在跨机房或多运营商线路场景下，还可以按线路质量动态择优。客户端持续统计每条线路的RTT和错误率，用加权的方式把流量倾斜到质量更好的线路上，主线路指标恶化时自然完成切换。这种方案实现成本略高，但对稳定性要求高的系统值得投入。
重试与备用路由的配合及降级兜底
重试和备用路由不是二选一的关系，而是分层配合。一个合理的调用策略是：先对当前节点做有限次数的带退避重试，全部失败后切换到备用路由，在新节点上同样执行受控重试，同时设置整体耗时上限。一旦总预算耗尽，就不要再尝试，直接走降级逻辑，比如返回缓存数据、默认值或友好提示，把核心链路保护住。
降级是最后一道防线。电商大促期间，推荐服务超时就返回兜底商品列表，评论服务超时就隐藏评论区，这些做法比让用户盯着报错页面好得多。配套的熔断器也建议加上：当某个下游的错误率超过阈值时，一段时间内直接快速失败，不再发起真实请求，给下游喘息恢复的机会，半开状态再放少量流量探测恢复情况。
总结一下，应对网络超时的完整思路是：合理设置并逐层传递超时时间，用带退避和抖动的受控重试应对瞬时故障，用备用路由应对节点级故障，最后用降级和熔断保护整体可用性。把这些手段组合起来，系统面对网络抖动和局部故障时才能做到用户无感、业务不损。