页面权重查询脚本调用限流时怎样保护已有结果
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /585e60974646.html
📄
页面权重查询脚本调用限流时怎样保护已有结果
能保住的结论是：只要把“已拿到的结果”先落盘、再按可重试的错误类型分批续跑，限流只会拖慢进度，不会让整批数据作废。但这条结论有一个失效边界——如果脚本把每次查询结果只放在内存里，等全部样本跑完才统一写文件，那么一旦触发限流中断，前面所有成功结果都会随进程一起消失。此时任何续跑策略都救不回来，必须先改写入时机。
先分清限流是“拒绝”还是“降速”
页面权重查询类接口在限流时通常给出两类信号，处理方式完全不同。一类是直接返回错误码，明确表示本次请求未被受理，这类可以安全重试。另一类是返回成功但内容为空或异常，这类不能简单重试，因为无法判断是目标页面本身没有数据，还是被限流降级了。
- 显式拒绝：带有限流语义的状态码或错误信息，重试通常有效，但要控制间隔。
- 静默降级：返回结构正常但关键字段缺失，重试可能得到同样结果，需要先记录原始响应再判断。
- 连接层失败：超时或连接重置，可能来自限流，也可能来自网络抖动，需要与业务错误分开统计。
实际动作：在脚本里为每个样本保存原始响应体，而不是只保存解析后的权重值。这样做之后，即使后续解析逻辑写错，也能用原始数据重新解析，不必重新请求。这个动作直接决定了限流发生后你还有多少可复用的数据。
写入策略决定限流时能保住多少
个别样本测试时，因为请求量小、间隔长，几乎不会碰到限流，所以“先攒后写”看起来没问题。规模化之后请求密度上升，限流概率随之提高，这个习惯就成了最大风险点。判断标准很简单：进程被强制终止时，磁盘上还剩多少条结果。
可以按下面的顺序调整：
- 把结果写入改成逐条或小批量追加，比如每成功一条就写入一行 JSON Lines。
- 为每条记录带上样本标识和请求时间，便于续跑时去重。
- 续跑前先读取已落盘文件，跳过已成功的样本，只重跑失败和未处理的。
- 把失败样本单独记录失败原因，避免和“未处理”混在一起。
假设有 500 个样本，跑到第 200 个时被限流中断。如果采用逐条追加，磁盘上约有 200 条可用结果，续跑只需处理剩余 300 条；如果采用全部跑完再写，磁盘上是空的，续跑等于从零开始。两者差距不是效率问题，而是已有结果是否存在的问题。
重试要区分错误，不能一律重发
把所有失败都当成限流并立即重试，往往会让限流持续更久，因为你在被拒绝时仍在加大请求密度。更稳妥的做法是按错误类型分流：
- 明确限流：等待一段时间后重试，并适当拉长请求间隔。
- 目标不存在或参数错误：不要重试，直接标记为失败，重试只是浪费配额。
- 解析失败：先保留原始响应，修正解析逻辑后离线重跑，不占用请求配额。
这里有一个容易误判的点：请求量归零或抓取统计下降，不能单独证明你的限流处理是正确的。它也可能来自目标站点临时不可用、脚本提前退出、或网络层问题。要结合失败原因分布来判断，而不是只看总量变化。
什么时候这套做法不成立
如果查询结果依赖一次性的会话令牌，而令牌在限流期间失效且无法自动续期，那么逐条落盘也保不住后续请求，因为续跑时连合法请求都发不出去。这种情况下，保护已有结果只是第一步，还需要把令牌获取和刷新逻辑独立出来，确保续跑能重新建立会话。
另一个反例是结果之间存在顺序依赖，比如后一条查询要用到前一条返回的某个标识。此时简单跳过已成功样本可能导致后续样本无法执行，需要额外记录依赖关系，而不是只记录成功与失败。
下一步动作
先做一次小规模演练：用几十个样本触发一次限流，然后检查磁盘上实际保留了多少条可用结果，再据此决定是继续调重试参数，还是先改写入方式。演练结果会直接告诉你，当前脚本的薄弱点在于存储时机还是重试策略，从而确定下一步该改哪一处。
