必须使用tenacity 8.0+版本并在async def函数上加@retry装饰器，显式配置wait_exponential、stop_after_attempt|stop_after_delay及retry_if_exception_type；需手写带asyncio.Lock保护的状态机熔断器，并通过retry_error_callback传递原始异常，同时监控circuit_breaker_state和retry_count_per_endpoint指标。
asyncio 里用 tenacity 实现带退避的重试
直接在 async def 函数上加 @retry 装饰器是最省事的路径，但必须确认你用的是 tenacity 8.0+ 版本——旧版本不支持原生协程，会静默降级为同步重试，导致整个事件循环被阻塞。
常见错误现象：重试期间 CPU 占用飙升、其他协程响应变慢、asyncio.wait_for 频繁超时。这是因为旧版 tenacity 在重试时用了 time.sleep，而它会阻塞当前线程。
- 必须显式指定
wait=wait_exponential(multiplier=1, min=1, max=10)，避免默认的固定间隔造成雪崩 - 用
stop=stop_after_attempt(3) | stop_after_delay(30)组合策略，防止某次请求卡死拖垮整条链路 - 捕获具体异常，比如只对
httpx.HTTPStatusError或asyncpg.exceptions.ConnectionDoesNotExistError重试，别无脑重试ValueError
示例：
@retry(
wait=wait_exponential(multiplier=1, min=1, max=10),
stop=stop_after_attempt(3) | stop_after_delay(30),
retry=retry_if_exception_type(httpx.HTTPStatusError)
)
async def fetch_data(url: str) -> dict:
async with httpx.AsyncClient() as client:
resp = await client.get(url)
resp.raise_for_status()
return resp.json()
手动实现熔断器：状态机 + 异步锁防并发穿透
没有现成的异步熔断库能完全信任，aiocircuit 已归档，circuitbreaker 不支持协程。最稳的方式是手写一个轻量状态机，核心是三个状态：closed（正常）、open（熔断）、half_open（试探），且必须用 asyncio.Lock 保护状态切换，否则高并发下多个请求同时触发 half_open 尝试，会绕过熔断。
立即学习“Python免费学习笔记（深入）”；
容易踩的坑：把熔断计数器存在局部变量或实例属性里——协程切换后状态丢失；或者用普通 threading.Lock，在 asyncio 环境下会死锁。
- 失败计数和时间窗口（如 60 秒内失败 ≥ 5 次）必须存于类实例的属性中，并在每次调用前检查是否已熔断
-
half_open状态下只允许一个请求通过，其余全部快速失败（raiseCircuitBreakerError），成功则恢复closed，失败则重置为open并延长熔断时间 - 熔断持续时间建议用指数退避，比如首次熔断 30 秒，连续失败则翻倍到 60、120 秒，避免下游还没恢复就被狂轰
重试 + 熔断组合时的异常传递陷阱
当 tenacity 的重试逻辑包裹在熔断器内部时，熔断器看到的不是原始异常，而是 tenacity.RetryError。如果你只判断 isinstance(e, httpx.HTTPStatusError)，那永远进不了熔断逻辑。
正确做法是在重试装饰器里用 retry_error_callback 提取底层异常：
@retry(
retry_error_callback=lambda future: future.exception().cause,
# ... 其他参数
)
async def fetch_data(...):
...
这样熔断器收到的就是原始的 httpx.HTTPStatusError，而不是包装后的 RetryError。否则你会观察到：明明上游服务已宕机，熔断器却始终不触发，因为它的失败计数器根本没被递增。
另一个关键点：重试耗时必须计入熔断的时间窗口统计。例如 3 次重试共耗时 28 秒，那这 28 秒要算进“过去 60 秒”的失败率计算里，不能只算最后一次调用的时间戳。
生产环境必须监控的两个指标
光有机制不够，得知道它是不是真起作用。最需要埋点的是：circuit_breaker_state（当前状态变更事件）和 retry_count_per_endpoint（按 URL 或函数名维度聚合的重试次数）。
别依赖日志 grep——高并发下日志丢事件、时间不准、难聚合。直接用 aiometer 或 asyncio.Queue 推送指标到 StatsD 或 OpenTelemetry。
特别注意 open → half_open 的转换频率：如果每分钟触发十几次，说明熔断阈值设得太激进，或者下游恢复太慢；如果一周都没触发过，那大概率配置错了，或者异常根本没被捕获进熔断路径。
