问题现象
在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/
