关键词研究工具脚本调用遇到限流时怎样保护已有结果
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /151a5f43d99e.html
📄
关键词研究工具脚本调用遇到限流时怎样保护已有结果
先保住已经拿到的数据，再决定是改写请求节奏还是换调用方式。限流本身不意味着结果作废，真正危险的是把未落盘的数据留在内存里、又用重试覆盖了旧记录。下面按“保留、改写、退出”三种取舍展开，每种都给出可核对的判断依据。
先做一次落盘检查，确认哪些结果真的已经安全
限流发生后，第一动作不是调参数，而是把当前批次写入独立文件并记录时间、请求参数和返回状态。判断“已有结果是否安全”不看工具提示，而看三个可核对项：数据是否已写入磁盘、写入是否带批次标识、重试是否会写到同一位置。
- 如果结果只存在于内存或界面表格里，它随时可能因进程退出而消失，应视为未保留。
- 如果已落盘但没有批次标识，后续重试可能追加成重复行，需要先按请求参数去重再继续。
- 如果落盘文件带完整请求参数，即使部分请求失败，也能只补失败的那一段，不必整批重跑。
假设一个场景：脚本分页抓取，第 40 页触发限流。若前 39 页已按页号写入单独文件，恢复时从第 40 页继续即可；若全部写进一个文件且没有页号字段，就只能重跑并承担重复风险。这个差别决定了下一步是补抓还是重跑。
保留：适合限流是暂时性、且数据成本高的情况
当限流表现为短时间拒绝、稍后恢复，而单次抓取成本较高（例如需要多步拼接、人工清洗），优先选择保留现有结果并延后补齐。适用前提是：你能确认失败范围、能定位断点、且等待不会让数据本身过期。
实际动作是给脚本加退避等待和断点记录：每次请求前写入“待请求”标记，成功后改为“已完成”，失败则保留原标记并记录状态码。恢复运行时只处理非“已完成”的项。这样做的结果是，限流只影响未完成部分，已完成部分不会被再次请求，也就不会被新返回覆盖。
需要留意一种误判：请求量突然归零，不一定说明限流已解除，也可能是脚本提前退出、参数被服务端静默忽略，或本地网络中断。把归零当作“可以全速重跑”的信号，容易在恢复后立刻再次触发限流。
改写：适合限流频繁、且请求方式本身可调整的情况
如果限流反复出现，说明当前调用节奏与对方允许的节奏不匹配，这时保留数据的同时要改写请求策略。可调整的方向包括：降低并发、拉长间隔、缩小单次请求范围、把批量查询拆成多次小查询。
判断该不该改写，看两个证据：一是失败是否集中在并发高的时段，二是降低并发后失败率是否下降。如果降低并发后仍然同样频繁失败，问题可能不在节奏，而在请求本身不被接受，此时继续调间隔收益有限。
改写的风险是拉长整体耗时。假设原来 10 分钟能跑完的任务，降低并发后变成 40 分钟，而数据时效只允许 15 分钟，那么“改写”就不是合适选项，应转向退出或换数据来源。这个比较需要你事先知道自己的时效底线，而不是跑完才发现来不及。
退出：适合限流指向规则变化、继续重试没有意义的情况
当限流伴随明确的拒绝说明、或多次调整节奏后仍无改善，继续重试只是在消耗时间。退出的含义不是放弃全部结果，而是停止对该接口的依赖，保留已落盘部分，并改用其他获取路径或人工抽样。
退出前应做一次差异核对：把已获得的结果与另一来源或人工抽查的少量样本对比，确认已保留部分没有系统性偏差。如果偏差集中在某个时间段或某类查询，说明缺失不是随机的，补抓的优先级要高于换来源。
这里有一个容易混淆的点：抓取量下降或某项统计变小，不能单独证明“退出是对的”。它也可能只是查询范围缩小、去重规则变严或时间窗口变化。要证明退出合理，需要的是“调整后仍失败”这一重复证据，而不是单次数量变化。
把分歧转成可核对的项目记录
多个角色对“结果是否还能用”常有不同理解：有人看界面还有数据就认为没事，有人看报错就认为全废。把分歧转成项目记录，可以按下面几项逐条核对，而不是靠口头结论。
- 记录限流发生的时间点与当时的请求参数。
- 列出已落盘范围与未完成范围，标明断点位置。
- 写明本次选择保留、改写还是退出，以及对应的前提条件。
- 约定复查时点：到点后核对失败率是否下降、数据是否仍满足时效。
复查结果直接决定下一步：失败率下降就继续补齐；没有下降就执行退出并切换来源；数据已过期则无论失败率如何都要重新获取。这样每个角色面对的是同一份可核对记录，而不是各自的印象。
