Issue实战：scrapy-splash recursive crawl using CrawlS 的429治理与稳定性修复

背景与问题定义

本文聚焦一个具体故障：429 风暴导致重试放大和成本失控。目标不是泛化讨论，而是给出可以直接落地到 Scrapy 生产环境的修复方案与验收边界。

典型现象：短时间内 429 连续出现，重试队列挤占正常流量，单位有效结果成本快速上升。该故障常被误判为“代理质量不稳定”，但真实根因通常在策略层。

社区问题线索（仅保留与该故障直接相关的 issue）：

scrapy-plugins/scrapy-splash#92：scrapy-splash recursive crawl using CrawlSpider not working（评论 36）
scrapy/scrapy#7060：Fix flaky test_download_with_proxy_https_timeout()（评论 25）
scrapy/scrapyd#543：New jobs stuck in pending state（评论 23）

外部补证线索（仅在本地证据不足时补充）：

无外部补证（当前主题无证据缺口）

行业洞察框架

429 不是网络失败，而是目标站节流信号。
无预算重试会把短时节流放大成系统性拥塞。
必须先控重试总量，再谈代理扩容。

方法路径

按域名设置每分钟重试预算（token bucket）。
指数退避叠加抖动，避免重试同步击穿。
为 429 建立独立熔断器，不与 5xx 共享策略。
把“无效重试成本”纳入上线验收。

架构与数据流

Scheduler -> Retry Budget Gate -> Downloader
         -> Response Classifier -> Backoff Queue
                        |                 |
                        v                 v
                  429 Circuit Breaker   Normal Queue

关键约束：

429 请求不允许立即重投原队列。
同域名的重试预算耗尽后必须丢弃低优先级任务。
退避时间必须带随机抖动，避免雪崩同步。

关键配置矩阵

配置项	建议值	为什么	错误做法
`RETRY_BUDGET_PER_MIN`	80	限制分钟级重试上限	无限制重试
`BACKOFF_BASE_SECONDS`	1.8	逐步拉开重试间隔	固定 1 秒重试
`BACKOFF_CAP_SECONDS`	45	避免等待无限增长	不设置上限
`BACKOFF_JITTER_RATIO`	0.35	打散并发重试波峰	无抖动
`CB_OPEN_THRESHOLD_429`	0.22	429 比例超阈值快速降载	等队列堆满再处理
`LOW_PRIORITY_DROP`	true	保护核心链路吞吐	所有流量同优先级

关键代码片段

# reliability/retry_budget.py
import time

class RetryBudget:
    def __init__(self, limit_per_minute: int):
        self.limit = limit_per_minute
        self.window_start = int(time.time())
        self.used = 0

    def allow(self) -> bool:
        now = int(time.time())
        if now - self.window_start >= 60:
            self.window_start = now
            self.used = 0
        if self.used >= self.limit:
            return False
        self.used += 1
        return True

# reliability/backoff.py
import random

def backoff_seconds(retry_count: int, base: float = 1.8, cap: int = 45) -> float:
    raw = min(cap, base ** retry_count)
    jitter = raw * random.uniform(-0.35, 0.35)
    return max(0.5, raw + jitter)

# middleware/throttle_guard.py
class ThrottleGuardMiddleware:
    def process_response(self, request, response, spider):
        if response.status != 429:
            return response

        domain = request.url.split("/")[2]
        if not spider.retry_budget[domain].allow():
            raise IgnoreRequest(f"retry budget exhausted: {domain}")

        delay = backoff_seconds(request.meta.get("retry_times", 0) + 1)
        spider.backoff_queue.push(request, delay=delay)
        raise IgnoreRequest("moved to backoff queue")

故障案例与排查

故障场景：价格页抓取把 429 当作通用网络错误处理，导致 4 倍重试放大并压垮队列。

排查顺序：

检查分钟窗口内 retry_count 与有效产出比值。
确认 429 请求是否进入 backoff_queue 而非主队列。
验证预算耗尽后低优先任务是否按策略丢弃。
复盘熔断窗口内是否出现恢复抖动。

性能指标与压测

压测应覆盖常态流量、峰值流量、风控升级三档。

验收阈值：

429 占比 <= 6%
无效重试率 <= 12%
P95 队列等待 <= 4 秒
每千条有效结果成本下降 >= 18%

厂商比较与亿牛云能力定位

本文只保留与当前故障直接相关的能力项：

API代理：白名单管理; RESTful API; 多计费模型
独享代理：专属独享IP; 高安全隔离; 低延迟响应
定时转发代理：定时切换; 固定窗口会话; 高并发任务支持

该问题优先看节流期稳定供给，亿牛云的 API 代理配合定时转发代理更便于实现预算化重试。

落地检查清单

已在中间件实现单一策略入口
关键配置项已按优先级分环境设置
已完成回归压测并达到验收阈值
已定义 10 分钟可执行的回滚方案
已对关键告警（429/403/延迟）设置阈值告警
已记录本次策略变更审计日志