4. 高并发场景下的连接瓶颈诊断

urllib3 是 Python 生态里最底层的 HTTP 客户端之一。很多上层库，比如 requests，底层用的就是它。所以，搞懂 urllib3 的连接池，就等于抓住了 HTTP 连接管理的命脉。

今天咱们就深入进去，看看 ConnectionPool 和 PoolManager 到底是怎么工作的。我当年刚接触这块时，也踩过不少坑，比如连接池满了导致请求排队超时，或者连接泄漏把文件描述符耗光。嗯，这些经验今天都会聊到。

4.1 从 PoolManager 说起

PoolManager 是 urllib3 的顶层入口。你平时用 requests，其实背后就是它在管理连接。

它的核心职责很简单：为不同的 HTTP 主机和端口，维护一组独立的连接池。

举个例子：

import urllib3

http = urllib3.PoolManager()
resp = http.request('GET', 'https://api.example.com/users')

这段代码背后发生了什么？

  1. PoolManager 解析 URL，提取出主机名 api.example.com 和端口 443。
  2. 它去内部字典里查找，有没有对应的 ConnectionPool 实例。
  3. 如果没有，就创建一个新的 HTTPSConnectionPool，并缓存起来。
  4. 然后从池子里借一个连接，发送请求。

说白了，PoolManager 就是个池子的管理员。它自己不存连接，它只管分发和创建池子。

关键点：PoolManager 内部维护的是一个 dict，key 是 (host, port, scheme) 三元组，value 是 ConnectionPool 实例。每个池子只负责一个目标地址。

4.2 ConnectionPool：真正的连接容器

ConnectionPool 才是干脏活累活的。它负责：

  • 维护一个连接队列（先进先出）
  • 控制最大连接数
  • 管理连接的生命周期
  • 处理连接的借用和归还

urllib3 里有两个具体的实现：

类名 用途 默认最大连接数
HTTPConnectionPool 管理 HTTP 连接 10
HTTPSConnectionPool 管理 HTTPS 连接 10

你可能会问：为什么 HTTP 和 HTTPS 要分开？

因为 HTTPS 多了 TLS/SSL 握手，连接的建立和销毁成本更高。分开管理，可以针对不同协议做不同的优化策略。我在项目中就遇到过，把 HTTP 和 HTTPS 混用一个池子，结果 TLS 连接被 HTTP 请求占用，导致 HTTPS 请求频繁重建连接，性能反而下降了。

4.3 连接池的懒加载机制

urllib3 的连接池是懒加载的。什么意思？

就是池子一开始是空的。只有当你真正发起请求时，它才会去创建连接。

来看个例子：

import urllib3

http = urllib3.PoolManager(num_pools=10, maxsize=5)

# 此时，池子还是空的
# 没有创建任何连接

resp1 = http.request('GET', 'https://api.example.com/users')
# 第一次请求：创建连接池，创建连接，发送请求

resp2 = http.request('GET', 'https://api.example.com/users')
# 第二次请求：复用连接池里的连接

为什么会这样设计？

我个人习惯把这种机制叫做「按需分配」。你想想看，如果你的应用有 10 个目标地址，但启动时只用到 3 个，那提前创建 10 个池子就是浪费。懒加载能节省内存和初始化时间。

具体流程是这样的：

  1. 第一次请求到达时，PoolManager 检查目标地址是否有对应的池子。
  2. 没有？那就创建一个 ConnectionPool 实例。此时池子里连接数为 0。
  3. 请求需要发送了，池子发现没有可用连接，就创建一个新的连接。
  4. 请求完成后，连接不销毁，而是放回池子里，等待下次复用。

小提示：你可以通过 pool_connections 参数控制 PoolManager 能管理的最大池子数量。默认是 10。如果你的服务要访问很多不同的 API 地址，记得调大这个值。

4.4 连接池的工作流程

我把整个流程画了一张图，方便你理解：

urllib3 连接池工作流程 HTTP 请求到达 PoolManager 解析 URL 池子存在？ 创建新的 ConnectionPool 复用已有 ConnectionPool ConnectionPool 获取连接 有空闲连接？ 复用空闲 连接 创建新 连接 发送 HTTP 请求

这张图把整个流程串起来了。你可以看到，池子的创建和连接的创建是分开的。池子只创建一次，连接可以反复创建和复用。

4.5 连接复用与归还

请求发送完后，连接不会销毁。urllib3 会把连接放回池子里，等待下一次使用。

这个过程叫「归还」。但这里有个细节：

  • 如果连接是健康的，直接放回队列尾部。
  • 如果连接已经断开（比如服务端关闭了），urllib3 会丢弃它，然后创建一个新的连接。

我曾经在生产环境遇到过一个问题：某个服务端设置了 60 秒空闲超时，但 urllib3 默认的连接检查间隔是 30 秒。结果就是，连接在池子里待了 60 秒后，服务端把它关了，但客户端不知道。下次请求时，urllib3 拿出这个「死连接」，发送请求，然后超时重试。白白浪费了一次请求时间。

避坑指南：我曾经因为没设置 urlopen 的 retries 参数，导致死连接重试了 3 次才成功。后来我养成了习惯，每次创建 PoolManager 时，都会显式设置 retries=1 或 retries=urllib3.Retry(connect=1, read=1)，避免无谓的等待。

4.6 连接池的配置参数

urllib3 的 PoolManager 提供了几个关键参数，我整理成了表格：

参数 默认值 说明
num_pools 10 最多管理的连接池数量
maxsize 1 每个连接池的最大连接数
block False 连接池满时是否阻塞等待
timeout None 连接超时和读取超时
retries 0 失败重试次数

这里有个容易踩的坑：maxsize 默认是 1。也就是说，每个目标地址默认只能复用 1 个连接。如果你的并发请求超过 1，后面的请求就得排队等。

我建议在高并发场景下，至少把 maxsize 调到 10 或 20。但也不是越大越好，因为连接多了会占用系统资源。具体调多少，得看你的服务端能承受多少并发连接。

4.7 连接池的清理机制

urllib3 不会自动清理空闲连接。连接会一直待在池子里，直到被复用或者程序退出。

这会导致什么问题？

如果你的应用只在一段时间内访问某个 API，之后再也不用了，那这个连接就会一直占用内存和文件描述符。时间长了，文件描述符可能会耗尽。

urllib3 官方推荐的做法是：使用 connectionpool.clear() 手动清理。

import urllib3

http = urllib3.PoolManager()

# 使用连接池
resp = http.request('GET', 'https://api.example.com/users')

# 用完清理
http.clear()

或者，你也可以用上下文管理器：

with urllib3.PoolManager() as http:
    resp = http.request('GET', 'https://api.example.com/users')
    # 退出上下文时自动清理

小技巧：我个人习惯在长时间运行的服务里，每隔一段时间（比如 30 分钟）调用一次 clear()，清理那些长时间不用的连接池。这样可以避免连接泄漏。

4.8 总结一下

urllib3 的连接池设计，核心就是两点：

  • 懒加载：池子和连接都是按需创建的，不浪费资源。
  • 连接复用：请求完成后连接不销毁，放回池子里等下次用。
← 上一章 📖 返回目录 下一章 →