当前位置：首页 > 文章列表 > 文章 > python教程 > Python连接池与限流策略全解析

Python连接池与限流策略全解析

2026-01-28 13:42:30 0浏览收藏

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《Python并发控制：连接池与限流策略详解》，聊聊，我们一起来看看吧！

requests.Session()默认连接池maxsize=10、block=False，易因连接耗尽抛MaxRetryError；需通过HTTPAdapter显式配置pool_maxsize、pool_block等参数并mount生效。

Python请求并发控制_连接池与限流策略解析【指导】

requests.Session() 默认连接池怎么配置才不踩坑

默认情况下 requests.Session() 用的是 urllib3.PoolManager，但它的连接池参数是隐藏的——你不显式配置，就只能靠默认值硬扛。常见问题比如「并发一高就报 ConnectionError: Max retries exceeded」，其实是底层连接池满 + 重试策略叠加导致的。

maxsize 默认是 10，意味着单个 host 最多复用 10 个连接；如果发往同一个域名（如 api.example.com）的请求超过这个数，后续请求会排队或新建连接（取决于 block 设置）
block=True 才会让新请求阻塞等待空闲连接；默认是 False，此时直接抛 MaxRetryError
要改必须通过 mount 注入自定义 HTTPAdapter，不能直接改 Session 实例属性

import requests
from urllib3.util import Retry
session = requests.Session()
adapter = requests.adapters.HTTPAdapter(
pool_connections=10,      # host 级别连接池数量（影响 mount 的 key）
pool_maxsize=20,          # 单 host 最大连接数
max_retries=Retry(
total=3,
backoff_factor=0.3,
allowed_methods={"GET", "POST"}
),
pool_block=True           # 关键：让请求排队而不是立刻失败
)
session.mount("https://", adapter)
session.mount("http://", adapter)

asyncio + httpx 怎么做真正的并发限流

用 asyncio.gather() 直接扔几百个 httpx.AsyncClient().get() 请求，很容易触发服务端限流或本地文件描述符耗尽。真正可控的并发得靠信号量（asyncio.Semaphore）或 httpx.LimitPool。

httpx.LimitPool 是更轻量的选择，它限制的是「同时发起的请求数」，不关心连接复用
如果还要控制每秒请求数（QPS），得自己套一层时间窗口计数器，httpx 不内置令牌桶
注意 httpx.AsyncClient 实例本身不是线程安全的，但可在单个协程内复用；不要在多个 task 里共享未加锁的 client

import asyncio
import httpx
sem = asyncio.Semaphore(10)  # 同时最多 10 个请求
async def fetch(url):
async with sem:
async with httpx.AsyncClient() as client:
return await client.get(url, timeout=5)
urls = ["https://httpbin.org/delay/1"]  50
results = await asyncio.gather([fetch(u) for u in urls])

requests + threading 混用时连接池失效的真实原因

很多人以为开了 20 个线程、每个线程 new 一个 requests.Session() 就能并发 20，结果发现 QPS 上不去甚至比单线程还慢——根本原因是每个 Session 都有独立连接池，而目标服务端对单 IP 的并发连接数有限制（比如 Nginx 的 limit_conn），大量短生命周期 Session 还会导致 TIME_WAIT 堆积。

线程间复用同一个 Session 是危险的（Session 不是线程安全的）
正确做法是每个线程持有一个专属 Session，且提前配置好连接池（见第一个副标题），并确保长期复用（比如用线程局部存储 threading.local）
更稳妥的替代方案是改用 concurrent.futures.ThreadPoolExecutor + 预热好的 Session 实例池

别把连接池和业务限流混为一谈

连接池管的是「TCP 连接复用与数量上限」，限流管的是「单位时间内允许多少次请求」。前者是客户端资源管理，后者是服务端契约或反爬策略。你配了 pool_maxsize=100，不代表你能每秒发 100 个请求——如果目标接口要求每分钟最多 60 次，你还硬发，照样被 429 Too Many Requests。