关键词热度查询脚本限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d60a0028f3b6.html
📄
关键词热度查询脚本限流时怎样保护已有结果
限流本身通常不会直接毁掉已经拿到的数据，真正危险的是脚本在收到429或超时后重试、覆盖或退出时把中间结果丢掉。保护已有结果的核心不是继续硬请求，而是先让已获得部分落盘、可续跑、可判定完整性，再决定保留、改写还是退出。
先判断限流发生在哪一层，决定保护动作的优先级
同样是“被限流”，处理方式并不一样。先确认请求被拒绝的位置，再决定把精力放在保存还是重试上。
- 如果脚本在请求发出前就被本地并发控制拦住，已有结果通常完整，优先做落盘和断点记录。
- 如果服务端返回429或明确的重试提示，说明请求已到达但被拒，此时继续重试只会放大风险，应先保存当前批次并记录被拒的查询项。
- 如果表现为连接超时、读取中断，无法确认服务端是否已经处理，盲目重放可能产生重复记录，应先按查询键去重再续跑。
这三种情况的共同动作是：在捕获异常的分支里先写文件，再决定是否重试。把“保存”放在“重试”之前，是保护已有结果最便宜的一步。
保留、改写、退出：三种取舍各自成立的前提
限流后不必只选一条路，但每条路都有适用条件，选错会浪费已经拿到的数据。
保留：结果已覆盖大部分目标且可标注缺口
当已完成的查询项占比高、缺失项可以明确列出时，保留是合理选择。动作是输出两个文件：一个是已成功的结果，一个是未完成的查询清单。这样后续可以直接对清单续跑，而不是重跑全量。前提是你必须能区分“没查到”和“没请求到”，否则保留的结果会带着隐性缺口进入分析。
改写：请求节奏或批次结构本身触发限流
如果限流在固定时间窗口内反复出现，说明问题出在节奏而非偶发。改写包括降低并发、拉长间隔、把大批量拆成可独立完成的小批。改写的代价是总耗时上升，因此只适合结果时效要求不高、且你能接受分批交付的场景。改写后要验证第一批是否完整落盘，再放开下一批。
退出：限流伴随鉴权失败或额度硬性耗尽
当返回信息指向凭据失效、配额已用尽或需要人工确认时，继续重试没有意义。退出的正确姿势不是直接终止进程，而是先执行一次落盘，再以非零状态退出，让调度方知道这次运行不完整。前提是你已经记录了最后成功的查询位置，否则下次只能从头开始。
用查询键和批次日志实现可续跑，而不是靠重跑兜底
保护已有结果的关键数据结构是“查询键 → 状态”。每个查询项至少记录三种状态：已完成、被限流、未请求。续跑时只处理后两类，已完成项直接跳过。
一个假设例子：假设你有一千个待查词，脚本在第400个时被限流。若日志只记了成功数量，你无法知道第401到1000中哪些已经发出、哪些还没发。若日志按查询键记录状态，续跑时就能精确跳过前400个，只补发剩余部分。这里的数字仅用于说明比较方法，不代表真实规模。
落盘时机也要注意：不要等全部跑完再写。每完成一个小批就追加写入，或使用临时文件加原子替换，避免进程中断留下半截文件。这样即使限流导致退出，已有结果仍然可读。
哪些现象不能单独证明处理正确
限流后看到请求量归零、日志不再增长，并不等于保护动作生效。请求量归零的合理解释至少有三种：脚本已按预期退出、重试逻辑进入了长等待、或进程被外部终止。要区分它们，需要同时看退出码、最后一条日志时间戳和落盘文件的行数是否一致。
同样，抓取量下降也不能单独说明限流被绕过。它可能只是批次变小、间隔变长的自然结果。判断依据应落在“已完成查询项是否可枚举”上，而不是落在请求数量上。
把保护动作落到下一次运行
限流处理是否合格，看下一次运行能否只补缺口。具体动作是：读取上次的查询键状态文件，过滤出未完成项，重新估算批次大小和间隔，再启动。如果这次能跳过已完成项且不产生重复记录，说明保护生效；如果仍然从头请求，说明落盘或状态记录环节存在遗漏。下一步应优先修复状态记录，而不是调整重试次数。
