文章简介在构建AI回答采集系统时调用多个大模型API如OpenAI、国产模型经常遇到超时、429限流、5xx错误。本文从工程实践出发设计一套包含指数退避、熔断和降级的重试机制并给出参数选择依据和可运行的单元测试。适合后端开发者、AI应用工程师参考。一、问题背景假设你正在开发一个AI回答采集系统每天需要调用多个大模型API获取回答。实际运行中以下异常频繁出现网络抖动导致连接超时requests.exceptions.TimeoutAPI返回429Too Many Requests不同模型返回的限流头不同例如OpenAI的Retry-After头而某些国产模型在响应体中返回retry_after字段服务端500或503临时不可用响应体解析失败如JSON格式错误如果不对这些异常做处理采集任务会频繁失败。本文聚焦于可重试异常的处理不涉及参数错误或认证失败等不可重试场景。二、异常分类与处理策略2.1 可重试异常网络超时TimeoutError通常由瞬时网络波动引起等待后可能恢复。HTTP 429限流服务端明确告知请求过频需等待指定时间。不同API的限流信息位置不同OpenAI在响应头Retry-After中给出秒数而某国产模型在响应体JSON的retry_after字段中。HTTP 5xx500、502、503、504服务端临时故障通常短暂等待后可恢复。2.2 不可重试异常HTTP 4xx除429外如400、401、403请求参数错误、认证失败等重试无意义需人工介入。三、重试机制设计3.1 指数退避策略每次重试间隔时间指数增长避免对服务端造成压力。base_delay和max_delay需根据API限流策略调整对于OpenAI官方建议初始重试等待1秒最大不超过60秒对于某些国产模型限流窗口可能更短base_delay可设为0.5秒。importtimeimportrandomdefexponential_backoff(attempt,base_delay1.0,max_delay60.0): 指数退避计算带随机抖动。 :param attempt: 当前重试次数从0开始 :param base_delay: 基础延迟根据API限流策略设置OpenAI建议1秒 :param max_delay: 最大延迟防止无限增长 :return: 本次重试前应等待的秒数 delaymin(base_delay*(2**attempt),max_delay)# 增加随机抖动避免惊群效应jitterrandom.uniform(0,delay*0.1)returndelayjitter3.2 最大重试次数设置最大重试次数为3次超过后标记为失败进入降级流程。3.3 熔断机制当连续失败次数超过阈值如5次暂时熔断不再发起请求等待恢复时间如30秒后尝试半开。importtimeclassCircuitBreaker:def__init__(self,failure_threshold5,recovery_timeout30):self.failure_count0self.failure_thresholdfailure_threshold self.recovery_timeoutrecovery_timeout self.last_failure_timeNoneself.stateCLOSED# CLOSED, OPEN, HALF_OPENdefcall(self,func,*args,**kwargs):ifself.stateOPEN:iftime.time()-self.last_failure_timeself.recovery_timeout:self.stateHALF_OPENelse:raiseException(Circuit breaker is OPEN)try:resultfunc(*args,**kwargs)self.failure_count0self.stateCLOSEDreturnresultexceptExceptionase:self.failure_count1self.last_failure_timetime.time()ifself.failure_countself.failure_threshold:self.stateOPENraisee3.4 降级策略当重试耗尽或熔断时返回默认值或从缓存读取历史数据。deffallback(api_name,params):# 从本地缓存获取上次成功结果cache_keyf{api_name}:{hash(frozenset(params.items()))}returncache.get(cache_key,None)四、完整实现以下代码整合了上述策略注意circuit_breaker为可选参数可根据需要启用。importrequestsimporttimedeffetch_with_retry(url,headers,params,max_retries3,circuit_breakerNone):forattemptinrange(max_retries):try:ifcircuit_breaker:responsecircuit_breaker.call(requests.get,url,headersheaders,paramsparams,timeout10)else:responserequests.get(url,headersheaders,paramsparams,timeout10)ifresponse.status_code200:returnresponse.json()elifresponse.status_codein[429,500,502,503,504]:delayexponential_backoff(attempt)time.sleep(delay)continueelse:# 不可重试异常response.raise_for_status()except(requests.exceptions.Timeout,requests.exceptions.ConnectionError)ase:delayexponential_backoff(attempt)time.sleep(delay)continueexceptExceptionase:# 其他异常记录日志log_error(e)break# 重试耗尽降级returnfallback(url,params)五、验证结果5.1 单元测试使用unittest.mock模拟requests.get验证重试次数和退避时间。importunittestfromunittest.mockimportpatch,MockimportrequestsclassTestFetchWithRetry(unittest.TestCase):patch(requests.get)deftest_retry_on_429_then_success(self,mock_get):# 模拟前两次返回429第三次返回200mock_get.side_effect[Mock(status_code429),Mock(status_code429),Mock(status_code200,jsonlambda:{result:ok})]resultfetch_with_retry(http://test.com,{},{})self.assertEqual(result,{result:ok})self.assertEqual(mock_get.call_count,3)patch(requests.get)deftest_retry_on_timeout_then_success(self,mock_get):# 模拟第一次超时第二次成功mock_get.side_effect[requests.exceptions.Timeout,Mock(status_code200,jsonlambda:{result:ok})]resultfetch_with_retry(http://test.com,{},{})self.assertEqual(result,{result:ok})self.assertEqual(mock_get.call_count,2)patch(requests.get)deftest_max_retries_exhausted(self,mock_get):# 模拟连续返回429三次mock_get.side_effect[Mock(status_code429),Mock(status_code429),Mock(status_code429)]resultfetch_with_retry(http://test.com,{},{},max_retries3)self.assertIsNone(result)# 降级返回Noneself.assertEqual(mock_get.call_count,3)if__name____main__:unittest.main()预期输出三个测试用例均通过。5.2 集成测试在测试环境中部署采集任务观察日志正常情况请求成功无重试模拟限流触发重试间隔递增模拟服务端错误触发熔断后续请求直接降级六、常见问题与避坑6.1 重试导致请求堆积当服务端恢复缓慢时大量重试可能加剧负载。解决方案使用熔断和队列限流。6.2 幂等性确保重试的请求是幂等的避免重复写入数据。例如采集请求应为只读操作。6.3 日志记录记录每次重试的原因、次数和延迟便于排查问题。总结本文针对AI回答采集系统调用大模型API时的异常场景实现了基于指数退避base_delay1smax_delay60s、熔断阈值5次恢复30秒和降级的重试机制。该方案适用于大多数API调用场景但存在以下限制未覆盖异步重试和分布式重试不同API的限流头解析需单独适配。实际应用中需根据服务端限流策略和业务容忍度调整参数。
文章简介在构建AI回答采集系统时调用多个大模型API如OpenAI、国产模型经常遇到超时、429限流、5xx错误。本文从工程实践出发设计一套包含指数退避、熔断和降级的重试机制并给出参数选择依据和可运行的单元测试。适合后端开发者、AI应用工程师参考。一、问题背景假设你正在开发一个AI回答采集系统每天需要调用多个大模型API获取回答。实际运行中以下异常频繁出现网络抖动导致连接超时requests.exceptions.TimeoutAPI返回429Too Many Requests不同模型返回的限流头不同例如OpenAI的Retry-After头而某些国产模型在响应体中返回retry_after字段服务端500或503临时不可用响应体解析失败如JSON格式错误如果不对这些异常做处理采集任务会频繁失败。本文聚焦于可重试异常的处理不涉及参数错误或认证失败等不可重试场景。二、异常分类与处理策略2.1 可重试异常网络超时TimeoutError通常由瞬时网络波动引起等待后可能恢复。HTTP 429限流服务端明确告知请求过频需等待指定时间。不同API的限流信息位置不同OpenAI在响应头Retry-After中给出秒数而某国产模型在响应体JSON的retry_after字段中。HTTP 5xx500、502、503、504服务端临时故障通常短暂等待后可恢复。2.2 不可重试异常HTTP 4xx除429外如400、401、403请求参数错误、认证失败等重试无意义需人工介入。三、重试机制设计3.1 指数退避策略每次重试间隔时间指数增长避免对服务端造成压力。base_delay和max_delay需根据API限流策略调整对于OpenAI官方建议初始重试等待1秒最大不超过60秒对于某些国产模型限流窗口可能更短base_delay可设为0.5秒。importtimeimportrandomdefexponential_backoff(attempt,base_delay1.0,max_delay60.0): 指数退避计算带随机抖动。 :param attempt: 当前重试次数从0开始 :param base_delay: 基础延迟根据API限流策略设置OpenAI建议1秒 :param max_delay: 最大延迟防止无限增长 :return: 本次重试前应等待的秒数 delaymin(base_delay*(2**attempt),max_delay)# 增加随机抖动避免惊群效应jitterrandom.uniform(0,delay*0.1)returndelayjitter3.2 最大重试次数设置最大重试次数为3次超过后标记为失败进入降级流程。3.3 熔断机制当连续失败次数超过阈值如5次暂时熔断不再发起请求等待恢复时间如30秒后尝试半开。importtimeclassCircuitBreaker:def__init__(self,failure_threshold5,recovery_timeout30):self.failure_count0self.failure_thresholdfailure_threshold self.recovery_timeoutrecovery_timeout self.last_failure_timeNoneself.stateCLOSED# CLOSED, OPEN, HALF_OPENdefcall(self,func,*args,**kwargs):ifself.stateOPEN:iftime.time()-self.last_failure_timeself.recovery_timeout:self.stateHALF_OPENelse:raiseException(Circuit breaker is OPEN)try:resultfunc(*args,**kwargs)self.failure_count0self.stateCLOSEDreturnresultexceptExceptionase:self.failure_count1self.last_failure_timetime.time()ifself.failure_countself.failure_threshold:self.stateOPENraisee3.4 降级策略当重试耗尽或熔断时返回默认值或从缓存读取历史数据。deffallback(api_name,params):# 从本地缓存获取上次成功结果cache_keyf{api_name}:{hash(frozenset(params.items()))}returncache.get(cache_key,None)四、完整实现以下代码整合了上述策略注意circuit_breaker为可选参数可根据需要启用。importrequestsimporttimedeffetch_with_retry(url,headers,params,max_retries3,circuit_breakerNone):forattemptinrange(max_retries):try:ifcircuit_breaker:responsecircuit_breaker.call(requests.get,url,headersheaders,paramsparams,timeout10)else:responserequests.get(url,headersheaders,paramsparams,timeout10)ifresponse.status_code200:returnresponse.json()elifresponse.status_codein[429,500,502,503,504]:delayexponential_backoff(attempt)time.sleep(delay)continueelse:# 不可重试异常response.raise_for_status()except(requests.exceptions.Timeout,requests.exceptions.ConnectionError)ase:delayexponential_backoff(attempt)time.sleep(delay)continueexceptExceptionase:# 其他异常记录日志log_error(e)break# 重试耗尽降级returnfallback(url,params)五、验证结果5.1 单元测试使用unittest.mock模拟requests.get验证重试次数和退避时间。importunittestfromunittest.mockimportpatch,MockimportrequestsclassTestFetchWithRetry(unittest.TestCase):patch(requests.get)deftest_retry_on_429_then_success(self,mock_get):# 模拟前两次返回429第三次返回200mock_get.side_effect[Mock(status_code429),Mock(status_code429),Mock(status_code200,jsonlambda:{result:ok})]resultfetch_with_retry(http://test.com,{},{})self.assertEqual(result,{result:ok})self.assertEqual(mock_get.call_count,3)patch(requests.get)deftest_retry_on_timeout_then_success(self,mock_get):# 模拟第一次超时第二次成功mock_get.side_effect[requests.exceptions.Timeout,Mock(status_code200,jsonlambda:{result:ok})]resultfetch_with_retry(http://test.com,{},{})self.assertEqual(result,{result:ok})self.assertEqual(mock_get.call_count,2)patch(requests.get)deftest_max_retries_exhausted(self,mock_get):# 模拟连续返回429三次mock_get.side_effect[Mock(status_code429),Mock(status_code429),Mock(status_code429)]resultfetch_with_retry(http://test.com,{},{},max_retries3)self.assertIsNone(result)# 降级返回Noneself.assertEqual(mock_get.call_count,3)if__name____main__:unittest.main()预期输出三个测试用例均通过。5.2 集成测试在测试环境中部署采集任务观察日志正常情况请求成功无重试模拟限流触发重试间隔递增模拟服务端错误触发熔断后续请求直接降级六、常见问题与避坑6.1 重试导致请求堆积当服务端恢复缓慢时大量重试可能加剧负载。解决方案使用熔断和队列限流。6.2 幂等性确保重试的请求是幂等的避免重复写入数据。例如采集请求应为只读操作。6.3 日志记录记录每次重试的原因、次数和延迟便于排查问题。总结本文针对AI回答采集系统调用大模型API时的异常场景实现了基于指数退避base_delay1smax_delay60s、熔断阈值5次恢复30秒和降级的重试机制。该方案适用于大多数API调用场景但存在以下限制未覆盖异步重试和分布式重试不同API的限流头解析需单独适配。实际应用中需根据服务端限流策略和业务容忍度调整参数。
