无节制并发会引发雪崩效应，因重试风暴导致后端压力倍增、依赖服务全盘崩溃；须通过Semaphore限流、指数退避重试、合理连接池与超时配置、熔断降级四层防护应对。
为什么无节制并发会触发雪崩效应
并发数失控时，失败请求不是安静地退出，而是立刻重试、再重试——所有客户端在同一毫秒内重发请求，后端压力瞬间翻倍。这种“重试风暴”会让原本只是抖动的服务彻底卡死，甚至把依赖的数据库、缓存、下游API全拖垮。
典型现象包括：429 Too Many Requests 大量出现、ConnectionRefusedError 频发、数据库连接池耗尽（sqlalchemy.exc.TimeoutError）、日志里反复刷出 httpx.ReadTimeout 或 aiohttp.ClientConnectorError。
必须设置并发上限和退避策略
不靠运气，靠硬约束。并发数不能凭感觉设，得结合目标服务的承载能力反推——比如对方限流是 60 QPM，那单机并发数建议 ≤ 10（留足余量应对延迟波动）。
- 用
asyncio.Semaphore控制协程并发数，别只靠asyncio.gather堆任务 - 重试必须带指数退避：第一次等 0.1 秒，第二次 0.2 秒，第三次 0.4 秒……上限建议设为 2–3 秒
- 禁用无条件重试，对
400、422这类客户端错误直接放弃，只重试429、502、503、504和网络异常
示例（httpx + 退避）：
import asyncio import httpx import random <p>sem = asyncio.Semaphore(8) # 全局并发上限</p><p>async def fetch_with_backoff(client, url, max_retries=3): for i in range(max_retries + 1): try: async with sem: # 拿到信号量才发请求 resp = await client.get(url, timeout=5.0) if resp.status_code in (429, 502, 503, 504): if i i) + random.uniform(0, 0.1), 3.0) await asyncio.sleep(delay) continue return resp except (httpx.TimeoutException, httpx.NetworkError): if i (2 ** i) + random.uniform(0, 0.1), 3.0) await asyncio.sleep(delay) continue return None </p>
连接池与超时必须显式配置
默认配置在高并发下极易失效：httpx.AsyncClient 不设 limits 会无限开连接；aiohttp.ClientSession 不配 connector 可能撑爆文件描述符；requests.Session 在多线程里若没复用，会疯狂建 TCP 连接。
httpx.AsyncClient(limits=httpx.Limits(max_connections=100, max_keepalive_connections=20))aiohttp.TCPConnector(limit=100, limit_per_host=30, keepalive_timeout=30)- 所有请求必须设
timeout，且分三段：connect、read、pool 各自独立控制
超时值要略大于 P95 延迟——比如实测平均响应 800ms，就设 timeout=2.0，而不是拍脑袋写 timeout=30。
熔断与降级是最后一道防线
当失败率持续超过阈值（如 5 秒内 50% 请求失败），应主动暂停对该服务的调用，避免把问题扩散。这不是可选功能，是生产环境必需项。
简单实现可用 tenacity 库的 stop_after_attempt + wait_exponential，但更推荐集成 pybreaker 这类专用熔断器。关键点：
- 熔断器状态需跨协程共享（用全局变量或依赖注入的实例）
- 半开状态必须限制试探请求数量（例如只放行 1 个请求验证是否恢复）
- 降级逻辑要真实可用——比如返回缓存数据、空结果或兜底模型，而不是抛
BreakerError让上游崩溃
最容易被忽略的是：熔断状态本身需要持久化或至少进程内共享。协程里每个请求都新建一个熔断器实例，等于没做。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
