Python并发请求接口方案_多线程与协程对比【指导】

应优先选用 asyncio + httpx 协程方案，因其连接池自动适配协程调度、无锁开销、吞吐高；若含大量同步阻塞或 CPU 密集操作，则选多线程并需为每个线程配置独立 Session 和线程安全连接池。

requests + threading 为什么经常卡死或报错

直接用 requests 配合 threading.Thread 发并发请求，大概率会遇到连接池耗尽、Max retries exceeded 或 ConnectionResetError。根本原因是 requests 底层的 urllib3.PoolManager 默认只维护有限连接（通常 10 个），多线程争抢同一连接池，又没做线程安全配置。

实操建议：

• 必须显式创建带足够 maxsize 和线程安全配置的 PoolManager，并绑定到每个 Session
• 每个线程应持有独立的 requests.Session() 实例，避免共享状态
• 加 threading.Semaphore 控制并发数，别盲目开几百个线程

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def make_session():
    session = requests.Session()
    retry = Retry(total=2, backoff_factor=0.3)
    adapter = HTTPAdapter(
        pool_connections=50,
        pool_maxsize=50,
        max_retries=retry
    )
    session.mount("http://", adapter)
    session.mount("https://", adapter)
    return session

asyncio + httpx 是目前最稳的协程方案

httpx.AsyncClient 原生支持 asyncio，连接池自动适配协程调度，没有线程锁开销，内存占用低，吞吐高。相比 aiohttp，httpx API 更接近 requests，迁移成本小，还支持 HTTP/2 和同步/异步混用。

常见错误现象：

• 忘记 await client.get(...)，直接调用返回 coroutine 对象，后续报 TypeError: object is not async
• 在非 async 函数里调用 asyncio.run() 多次，导致 event loop 已关闭
• 没限制并发数，asyncio.gather(*tasks) 一次性扔几千个请求，触发服务端限流或本地文件描述符耗尽

import asyncio
import httpx

async def fetch(client, url):
    try:
        r = await client.get(url, timeout=5.0)
        return r.status_code, r.text[:100]
    except Exception as e:
        return -1, str(e)

async def main():
    async with httpx.AsyncClient() as client:
        tasks = [fetch(client, "https://httpbin.org/delay/1") for _ in range(50)]
        results = await asyncio.gather(*tasks, return_exceptions=True)
    return results

什么时候该选多线程，而不是协程

不是所有 IO 场景都适合协程。当你的“请求逻辑”里混杂了大量同步阻塞操作（比如本地文件解析、CPU 密集型处理、调用不支持 async 的第三方库），强行塞进 async def 反而降低性能，甚至引发死锁。

适用多线程的真实场景：

• 接口响应快（
• 调用的是封装在 .so/.dll 里的闭源 SDK，它内部是阻塞式网络+计算
• 已有成熟线程安全的缓存模块（如 threading.local + redis 连接），改造成 async 成本过高

此时用 concurrent.futures.ThreadPoolExecutor + loop.run_in_executor 混合调度更实际。

超时、重试、限流必须按层配置

并发下，单点超时不等于全局可控。网络超时、连接超时、读取超时、重试策略、客户端限流、服务端限流，这五层必须分开看、分别设。

关键参数对照：

• requests：用 timeout=(connect_timeout, read_timeout)，别只写一个数字
• httpx：timeout=httpx.Timeout(5.0, connect=3.0, read=5.0)，支持细粒度控制
• 重试：urllib3.Retry 或 httpx.Limit 配合 AsyncClient 的 event_hooks
• 客户端限流：用 asyncio.Semaphore(n) 包裹请求逻辑，比靠服务端 429 更可靠

最容易被忽略的是 DNS 解析超时 —— 它不包含在 connect 超时里，httpx 需额外设 httpx.Limits 的 max_keepalive_connections，requests 则依赖系统 resolver 行为。