问题现象

在Python 3.10环境中，使用requests库调用OpenAI兼容的chat/completions接口时，经常遇到以下异常：

• requests.exceptions.ConnectionError：偶发网络抖动导致连接中断，整个采集任务直接失败。
• requests.exceptions.ReadTimeout：接口响应时间超过预设的30秒超时，导致请求被中断。
• 429 Too Many Requests：触发API限流，后续请求全部失败。

这些异常导致采集任务失败率较高，且没有重试机制时，一次失败就会中断整个任务。本文适合需要稳定调用大模型API的开发者，将给出一个包含指数退避重试、熔断和降级的完整方案，并说明如何验证效果。

运行环境

• Python 3.10+
• requests 2.31.0
• tenacity 8.2.3
• circuitbreaker 1.4.0

原因分析

网络不稳定

公网调用API时，网络波动是常态。从日志看，ConnectionError通常发生在请求发送阶段，表现为Connection reset by peer或Connection aborted。这类错误是瞬时的，重试往往能成功。

限流

API服务端有速率限制，当请求频率超过阈值时返回429。响应头中的Retry-After字段会提示等待时间。如果忽略该字段，持续请求会加重服务端压力，导致限流时间延长。

超时设置不合理

requests默认超时为None，即无限等待。但实际中，如果设置过短（如5秒），一些正常的慢请求会被误判为超时。从日志看，ReadTimeout错误集中在响应时间超过30秒的请求上，说明30秒可能不够，需要根据API的响应时间分布调整。

候选方案对比

综合考虑，我们采用指数退避+抖动，并引入熔断和降级。指数退避能有效应对瞬时故障，抖动避免多个请求同时重试，熔断在服务持续故障时快速失败，降级保证核心流程不中断。

核心实现

1. 指数退避与重试

使用tenacity库实现指数退避和重试。以下代码放在api_client.py中，是核心重试逻辑。

fromtenacityimportretry,stop_after_attempt,wait_exponential,retry_if_exception_typeimportrequests@retry(stop=stop_after_attempt(5),wait=wait_exponential(multiplier=1,min=2,max=60),retry=retry_if_exception_type((requests.exceptions.ConnectionError,requests.exceptions.Timeout)),reraise=True)defcall_api(prompt):response=requests.post("https://api.example.com/v1/chat/completions",json={"prompt":prompt},timeout=30)response.raise_for_status()returnresponse.json()

参数选择理由：

• stop_after_attempt(5)：最多重试5次，避免无限重试。
• wait_exponential(multiplier=1, min=2, max=60)：等待时间指数增长，从2秒开始，最大60秒，并加入随机抖动（默认开启），避免同步重试风暴。
• retry_if_exception_type：仅对连接错误和超时重试，HTTP错误如404、500不重试，因为重试无法解决这类问题。

注意事项：

• 重试可能导致请求重复，需要在业务层做幂等处理。
• 如果API返回429，建议根据Retry-After字段等待，而不是盲目重试。

2. 熔断机制

使用circuitbreaker库实现熔断。以下代码同样在api_client.py中，对call_api进行包装。

fromcircuitbreakerimportcircuit@circuit(failure_threshold=5,recovery_timeout=60)defcall_api_with_circuit(prompt):returncall_api(prompt)

参数选择理由：

• failure_threshold=5：连续失败5次后熔断打开，避免频繁触发。
• recovery_timeout=60：60秒后进入半开状态，尝试放行一个请求，若成功则关闭熔断。

注意事项：

• 熔断阈值应根据API的SLA和业务容忍度调整。阈值过小容易误触发，过大则失去保护作用。

3. 降级策略

当熔断打开或重试耗尽时，降级为返回缓存结果或默认值。以下代码在fetch_ai_answer函数中实现。

deffetch_ai_answer(prompt):try:returncall_api_with_circuit(prompt)exceptExceptionase:# 降级：返回缓存或默认值returnget_cached_answer(prompt)or{"error":"fallback"}

设计说明：

• 降级策略需根据业务场景设计，确保核心流程不中断。例如，如果采集任务允许部分失败，可以返回默认值并记录日志。
• 如果业务对数据完整性要求高，降级可能需要更复杂的处理，如排队重试。

验证结果

在本地模拟环境（使用mock API）测试，模拟10%的随机失败和限流。正常情况下，应当看到以下现象：

• 无重试机制：任务中断，日志中记录大量异常。
• 加入指数退避重试：成功率提升，日志中显示重试次数和等待时间。
• 加入熔断：在持续故障时，日志中显示熔断打开，请求快速失败。
• 加入降级：即使最终失败，也能返回降级结果，流程继续。

验证方法：

• 检查日志中是否出现Retrying关键字，表示重试生效。
• 检查熔断状态变化，如Circuit breaker opened。
• 检查降级结果是否返回。

常见问题与避坑

1. 重试导致请求重复

重试可能造成重复请求，需在业务层做幂等处理。例如，为每个请求生成唯一ID，服务端根据ID去重。

2. 熔断阈值设置不当

阈值过小容易误触发，过大则失去保护作用。建议根据API的SLA和业务容忍度调整。例如，如果API的SLA是99.9%，可以设置failure_threshold为10。

3. 超时设置

超时时间应根据API响应时间分布合理设置，避免过短或过长。可以通过日志统计响应时间，设置P95或P99作为超时阈值。

总结

本文解决了AI回答采集中的异常处理与重试问题，根因是网络不稳定和API限流。最终方案采用指数退避重试、熔断和降级，适用于对稳定性要求较高的采集场景。限制在于：未处理API返回的业务错误（如内容审核），且降级策略需根据业务定制。

参考资料

• tenacity文档: https://tenacity.readthedocs.io/
• circuitbreaker文档: https://pypi.org/project/circuitbreaker/