17370845950

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

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://www./link/5f69e19efaba426d62faeab93c308f5c"]  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。

• 遇到 429，优先检查响应头里的 Retry-After 或自定义限流字段，而不是调大连接池
• 业务限流建议用 ratelimit 这类库做装饰器级控制，或者在请求前加 time.sleep() 计算间隔（简单场景）
• 连接池调太大反而可能触发服务端连接拒绝（如某些云 API 对单 IP 连接数硬限制）

连接池参数和业务限流策略得分开设计，而且都要根据实际压测结果调，不是堆数字就能解决问题。