17370845950

真正稳定的爬虫需分层容错：请求层用tenacity实现指数退避重试，解析层用select_one和兜底逻辑防结构变化，调度层通过状态队列实现失败隔离与断点恢复。

爬虫运行中遇到网络抖动、目标服务器限流、超时或页面结构突变很常见，靠简单 try-except 捕获异常远远不够。真正稳定的爬虫需要分层容错：在请求层控制重试逻辑，在解析层防御结构变化，在调度层避免雪崩式失败。

请求层：带退避策略的智能重试

盲目重试会加重服务器压力，也可能触发风控。应使用指数退避（exponential backoff）+ 最大重试次数 + 随机抖动。推荐用 tenacity 库替代手写循环：

• 安装：pip install tenacity
• 基础用法：对可能失败的请求函数加装饰器，指定重试条件（如 RetryError、Timeout、HTTP 5xx）、等待时间（wait_exponential(multiplier=1, min=1, max=10)）和最大次数（stop_after_attempt(3)）
• 关键细节：对 403/429 等明确拒绝类状态码，建议直接退出而非重试；对连接错误、超时、502/503 等临时性错误才启用退避重试

解析层：结构感知 + 默认兜底

网页改版是爬虫失效主因。不要假设 select('div.content > p')[0].text 一定存在：

• 用 .select_one() 替代 .select()，避免索引越界；用 .get_text(strip=True) or '' 替代直接调用 .text
• 关键字段提取后立即校验有效性（如日期格式、数字范围），不满足则记录 warn 日志并跳过该条目，而非中断整个任务
• 对多套可能的 selector 规则做 fallback 尝试（例如先试 class="article-body"，失败再试 id="post-content"），提升适应性

调度与状态管理：失败隔离 + 可恢复断点

批量任务中单个 URL 失败不应阻塞全局进度：

• 将待抓取 URL 存入带状态标记的队列（如 Redis Sorted Set 或本地 SQLite 表），每条记录包含 url、status（pending/running/success/failed）、fail_count、last_updated
• 成功后更新状态为 success；失败时仅增加 fail_count 并延后重试时间（如 30 分钟后），避免反复冲击同一链接
• 程序启动时优先拉取 status=failed AND fail_count 的链接重试，实现故障自愈

监控与快速响应：失败归因 + 告警联动

稳定不是“不出错”，而是“错得明白、修得及时”：

• 记录每次失败的完整上下文：URL、HTTP 状态码、响应头（特别是 X-RateLimit-Remaining）、异常类型、traceback 截断前 200 字符
• 按小时统计失败率、TOP 失败域名、高频异常类型，用 Grafana 展示趋势；当某域名失败率突增 50%，自动发企业微信告警
• 对持续失败的站点，动态降级：暂停该域名所有请求 2 小时，并通知运维检查代理池或 UA 策略