📚 课程目录第4章 Connection Pool调优

4. Connection Pool 调优：HTTP 连接池的 MaxRequests、MaxConnections、MaxPendingRequests 参数详解

在 Envoy 的 HTTP 连接池中，MaxRequests、MaxConnections 和 MaxPendingRequests 是控制上游连接行为最核心的三个参数。它们共同决定了连接池的吞吐上限、并发能力以及请求排队策略。理解这三个参数的交互关系，是避免上游过载、提升资源利用率的关键。

4.1 参数定义与作用域

Envoy 的 HTTP 连接池为每个上游集群维护一组连接。当请求到达时，连接池会按以下优先级检查资源：

MaxConnections：限制与上游主机建立的最大 TCP 连接数。
MaxRequests：限制每个连接上可以同时处理的最大请求数（HTTP/1.1 通常为 1，HTTP/2 可复用）。
MaxPendingRequests：当所有连接和请求槽位都被占满时，允许排队的最大请求数。

参数名	作用层级	默认值	典型场景
MaxConnections	连接池 → 上游主机	1024	限制 TCP 连接数，防止上游端口耗尽
MaxRequests	连接池 → 单个连接	1024 (HTTP/2)	控制连接复用度，避免单连接过载
MaxPendingRequests	连接池 → 请求队列	1024	突发流量缓冲，防止请求直接丢弃

实践提示：在 HTTP/1.1 场景下，MaxRequests 通常设置为 1，因为每个连接只能串行处理一个请求。而在 HTTP/2 多路复用场景下，MaxRequests 可以设置为较大的值（如 256 或 1024），以充分利用单连接的并发能力。

4.2 参数交互流程与决策树

当一个新请求到达连接池时，Envoy 会按照以下顺序进行资源检查。理解这个决策路径，有助于定位连接池瓶颈。

  请求准入决策流程：
  检查当前活跃连接数是否 小于 MaxConnections？

      → 是：创建新连接，请求直接发送。

      → 否：进入第 2 步。
检查已有连接上当前请求数是否 小于 MaxRequests？

      → 是：复用已有连接，请求发送。

      → 否：进入第 3 步。
检查当前排队请求数是否 小于 MaxPendingRequests？

      → 是：请求进入等待队列。

      → 否：请求被直接拒绝（返回 503 或触发断路器）。

4.3 参数调优策略与典型配置

不同业务场景下，三个参数的调优方向差异很大。以下表格总结了常见场景的推荐配置与调整理由。

场景	MaxConnections	MaxRequests	MaxPendingRequests	调优理由
高并发短连接（HTTP/1.1）	200-500	1	100-200	每个连接只处理一个请求，需要较多连接；排队深度不宜过大，避免延迟堆积
长连接复用（HTTP/2）	10-50	256-1024	500-1000	少量连接即可承载大量并发流；排队深度可适当放宽，利用多路复用消化突发
上游服务脆弱（保护模式）	50-100	100-200	50-100	主动限制所有维度，防止上游被突发流量打垮；配合断路器使用
低延迟敏感（实时交互）	100-200	50-100	10-50	严格控制排队深度，宁可拒绝请求也不让请求长时间等待

4.4 配置示例与关键代码

以下是一个典型的 Envoy 集群配置片段，展示了如何通过 circuit_breakers 字段设置这三个参数。

static_resources:
  clusters:
  - name: upstream_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: upstream_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: upstream.example.com
                port_value: 8080
    circuit_breakers:
      thresholds:
      - priority: DEFAULT
        max_connections: 200          # 最大连接数
        max_requests: 256             # 每连接最大请求数
        max_pending_requests: 500     # 最大排队请求数
      - priority: HIGH
        max_connections: 400
        max_requests: 512
        max_pending_requests: 1000

避坑指南：

不要将 MaxPendingRequests 设置得过大：过大的排队深度会导致请求延迟急剧上升，甚至引发级联超时。建议结合上游服务的 P99 响应时间动态调整。
HTTP/1.1 场景下 MaxRequests 不要大于 1：HTTP/1.1 不支持多路复用，设置大于 1 的值不会提升并发，反而会造成连接复用逻辑混乱。
注意优先级区分：Envoy 支持 DEFAULT 和 HIGH 两个优先级，可以为高优先级请求分配更大的连接池资源，避免被普通请求饿死。

4.5 监控与调优闭环

调优不是一次性工作。Envoy 提供了丰富的连接池统计指标，用于持续观察参数是否合理。

指标名称	类型	含义	调优信号
`cluster.circuit_breakers.default.remaining_pending`	Gauge	当前剩余可用的排队槽位	接近 0 时说明排队深度不足
`cluster.upstream_rq_pending_total`	Counter	累计排队请求总数	持续增长说明连接池容量不足
`cluster.upstream_rq_pending_overflow`	Counter	因排队满被拒绝的请求数	大于 0 时需增大 MaxPendingRequests 或扩容
`cluster.upstream_cx_active`	Gauge	当前活跃连接数	接近 MaxConnections 时需评估是否扩容

推荐调优步骤：

先设置保守值（如 MaxConnections=100, MaxRequests=100, MaxPendingRequests=100），观察基线流量。
监控 upstream_rq_pending_overflow 和 upstream_cx_active 指标。
如果 upstream_rq_pending_overflow 持续增长，优先增加 MaxPendingRequests（每次增加 50%）。
如果 upstream_cx_active 长期接近 MaxConnections，同时 MaxRequests 利用率较低，则增加 MaxConnections。
如果单连接请求数经常达到 MaxRequests 上限，考虑增大 MaxRequests 或启用 HTTP/2 多路复用。