在构建一个每天采集数十万条AI回答数据的系统时我们遇到了接口限流、超时和返回格式异常等问题。简单的固定间隔重试不仅无法解决问题反而可能加剧服务端压力。本文基于Python 3.9和tenacity、pybreaker库分享一套完整的异常处理与重试机制设计方案包括指数退避、熔断和降级策略并提供可复用的代码示例和验证方法。本文不涉及具体的AI服务商API细节重点在于通用的重试机制设计。一、问题背景与业务约束我们的采集系统需要定期从多个AI服务商获取回答数据用于后续的分析和处理。业务对数据完整性和时效性有较高要求但上游接口的稳定性不可控。具体约束如下数据量每天需采集数十万条回答高峰期QPS可达数百。接口特性不同服务商的接口限流策略不同部分接口在超时后返回不完整数据。成本敏感调用大模型接口需要付费无效重试会浪费成本。监控要求需要实时掌握采集成功率、失败原因分布以便快速响应。这些约束决定了重试机制必须精准、有界并且能够快速失败。二、异常类型与初步处理在采集过程中我们遇到的异常主要分为以下几类网络异常连接超时、读取超时、DNS解析失败等。HTTP状态码异常429限流、500服务端错误、503服务不可用等。业务异常返回数据格式错误、字段缺失、内容为空等。针对这些异常我们首先实现了基础的异常捕获和日志记录但很快发现简单的重试策略固定间隔重试3次存在严重问题在服务端故障时大量请求同时重试加剧了服务端压力导致恢复时间延长。对于限流错误429固定间隔重试无法有效规避限流窗口。对于格式错误等业务异常重试往往无效只会浪费资源。因此我们需要区分可重试和不可重试的异常并采用更精细的重试策略。三、重试机制设计指数退避与抖动为了解决上述问题我们引入了指数退避策略。基本思想是每次重试的间隔时间随重试次数指数增长并加入随机抖动避免多个请求同时重试。核心代码示例以下是一个使用tenacity库实现的指数退避示例Pythonimportrandomimporttimefromtenacityimportretry,stop_after_attempt,wait_exponential,retry_if_exception_typeclassRateLimitError(Exception):passclassServerError(Exception):passretry(retryretry_if_exception_type((RateLimitError,ServerError)),waitwait_exponential(multiplier1,min2,max60),stopstop_after_attempt(5),reraiseTrue)deffetch_ai_answer(prompt):# 模拟请求responsecall_ai_service(prompt)ifresponse.status_code429:raiseRateLimitError(Rate limited)ifresponse.status_code500:raiseServerError(Server error)returnresponse.json()设计要点重试条件仅对可重试的异常如限流、服务端错误进行重试对于格式错误等业务异常直接抛出。退避策略使用指数退避初始间隔2秒最大间隔60秒并加入随机抖动tenacity库默认实现。重试次数根据业务容忍度设置为5次避免无限重试。选择指数退避是因为它能在短时间内快速重试同时避免对服务端造成持续压力。固定间隔重试在服务端故障时容易导致重试风暴而线性退避又可能等待过久。四、熔断机制防止雪崩即使有了指数退避当服务端持续故障时大量请求仍会堆积在等待重试导致本地资源耗尽。为此我们引入了熔断器模式。熔断器状态机熔断器有三种状态关闭、打开、半开。关闭正常调用统计失败率。打开失败率达到阈值如50%直接拒绝请求快速失败。半开经过冷却时间后允许少量请求探测如果成功则关闭熔断器否则继续打开。实现代码示例我们使用了pybreaker库完整配置如下importpybreaker breakerpybreaker.CircuitBreaker(fail_max5,reset_timeout60,exclude[RateLimitError]# 限流错误不触发熔断因为限流是暂时的)breakerretry(retryretry_if_exception_type((RateLimitError,ServerError)),waitwait_exponential(multiplier1,min2,max60),stopstop_after_attempt(5),reraiseTrue)deffetch_ai_answer(prompt):# 模拟请求responsecall_ai_service(prompt)ifresponse.status_code429:raiseRateLimitError(Rate limited)ifresponse.status_code500:raiseServerError(Server error)returnresponse.json()设计要点失败阈值连续失败5次触发熔断避免频繁抖动。冷却时间60秒后进入半开状态允许探测。排除特定异常限流错误429不应触发熔断因为限流是服务端主动保护熔断反而会加重问题。熔断机制能有效防止雪崩但需要根据服务端的实际恢复时间调整冷却时间。五、降级策略保证核心流程当熔断器打开或重试耗尽时我们需要降级处理避免采集任务完全失败。降级策略包括缓存降级如果之前采集过相同或相似问题直接使用缓存数据。队列降级将失败的任务放入待处理队列稍后重试。默认值降级对于非关键字段使用默认值或空值。降级实现示例deffetch_with_fallback(prompt):try:returnfetch_ai_answer(prompt)exceptExceptionase:# 尝试从缓存获取cachedcache.get(prompt)ifcached:returncached# 放入重试队列retry_queue.put(prompt)returnNone降级策略的选择取决于业务对数据完整性的要求。对于非关键数据可以接受默认值对于关键数据则必须通过队列保证最终一致。六、验证结果与监控为了验证机制的有效性我们进行了压测和故障注入实验。压测结果在模拟限流场景下服务端返回429使用指数退避后成功率显著提升平均响应时间明显下降。具体数据因环境而异建议根据实际压测结果评估。监控指标我们通过日志和监控系统实时跟踪以下指标具体实现可以使用PrometheusGrafana通过埋点采集以下指标采集成功率成功请求数 / 总请求数。重试次数分布不同重试次数的占比。熔断器状态变化打开、关闭、半开的次数。降级触发次数使用缓存或队列降级的次数。例如使用Prometheus的Counter和Histogram记录请求总数、成功数、重试次数等通过Grafana展示趋势。七、踩坑与避坑总结在实现过程中我们遇到了几个典型问题重试风暴最初没有加入抖动导致大量请求同时重试服务端压力骤增。加入随机抖动后问题解决。熔断误判将限流错误也计入熔断统计导致熔断频繁触发。通过排除429错误解决。重试超时重试时未重新计算超时时间导致整体耗时过长。在每次重试时重置超时时间。这些问题的共同点是缺乏对异常类型的细分和全局视角导致机制之间相互干扰。总结本文从AI回答采集的实际需求出发设计并实现了一套完整的异常处理与重试机制。通过指数退避、熔断和降级策略有效提升了采集系统的稳定性和可靠性。该方案适用于对接口稳定性要求较高、成本敏感的场景。需要注意的是重试次数、熔断阈值等参数需要根据实际业务调整且应结合监控系统持续优化。
