3. 应用层超时设计：HTTP请求超时、数据库连接超时、RPC调用超时

应用层超时是ReplyTimeout体系中最贴近业务的一环。传输层的重传由内核控制，而应用层的超时由业务代码或中间件客户端驱动。如果应用层超时设置不合理，轻则导致请求堆积、线程池耗尽，重则引发雪崩效应。本节将剖析三种最常见的应用层超时场景：HTTP请求、数据库连接、RPC调用，并给出可落地的调优参数。

3.1 HTTP请求超时设计

HTTP客户端通常提供三个独立的超时控制点：连接超时(ConnectTimeout)、读取超时(ReadTimeout/SocketTimeout)、写入超时(WriteTimeout)。三者必须分别设置，不能混用。

以下是一个基于Java OkHttp的推荐配置示例：

OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(2, TimeUnit.SECONDS)      // 内网服务，2s内连不上直接放弃
    .readTimeout(5, TimeUnit.SECONDS)         // 接口P99为3s，留2s缓冲
    .writeTimeout(3, TimeUnit.SECONDS)        // 请求体小于10KB，3s足够
    .retryOnConnectionFailure(true)           // 允许对幂等请求自动重试
    .build();

3.2 数据库连接超时设计

数据库超时分为两个层面：连接池层面的超时和JDBC驱动层面的超时。两者必须协同配置，否则会出现连接池未超时但JDBC已挂死的情况。

3.2.1 连接池关键超时参数

3.2.2 JDBC驱动超时参数

MySQL JDBC驱动中，socketTimeout是最容易被忽略的参数。默认值为0（无限等待），一旦网络异常，线程将永久挂起。

# MySQL JDBC URL 推荐配置
jdbc:mysql://dbhost:3306/mydb?
  connectTimeout=3000&          # 连接超时3s
  socketTimeout=5000&           # Socket读取超时5s
  tcpKeepAlive=true&            # 启用TCP保活
  autoReconnect=false           # 生产环境关闭自动重连，由连接池管理

3.3 RPC调用超时设计

RPC框架（gRPC、Dubbo、Thrift）的超时设计比HTTP更复杂，因为涉及调用链传播和超时漏斗。一个上游RPC超时设置不当，会导致下游所有服务同时超时重试，引发流量放大。

3.3.1 超时漏斗模型

在微服务调用链中，超时时间必须逐层递减，形成漏斗状：

• A服务（网关层）：总超时 5s
• B服务（业务聚合层）：总超时 3s
• C服务（基础服务层）：总超时 1.5s
• D服务（数据库/缓存层）：总超时 800ms

3.3.2 gRPC超时配置示例

// gRPC客户端拦截器设置超时
public class GrpcTimeoutInterceptor implements ClientInterceptor {
    private static final long DEADLINE_MS = 3000; // 3s

    @Override
    public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
            MethodDescriptor<ReqT, RespT> method,
            CallOptions callOptions,
            Channel next) {
        // 如果调用方未设置deadline，则使用默认值
        if (callOptions.getDeadline() == null) {
            callOptions = callOptions.withDeadlineAfter(DEADLINE_MS, TimeUnit.MILLISECONDS);
        }
        return new ForwardingClientCall.SimpleForwardingClientCall<>(
                next.newCall(method, callOptions)) {};
    }
}

3.3.3 Dubbo超时参数矩阵

3.4 三种超时场景对比总结