操作速览
- 观察变化速度:按来源记录有效变更。
- 调整请求间隔:结合缓存与错误退避。
- 标记数据新鲜度:旧快照与当前结果分开。
先查看采集时间,再决定是否需要刷新
1. 把最近尝试、最近成功采集、价格实际变化三个时间分开记录。一次定时任务启动,不能证明数据已经更新。
2. 遇到 429、超时或解析为空,降低请求频率并保留上一份成功记录。恢复后再核对来源,而不是清空旧数据。
3. 本站价格任务每 6 小时尝试更新,属于固定周期采集;本文的自适应策略是进一步建设方法,不把设计方案说成已全部实现。
按来源变化概率设置基础频率
官方模型价格页通常变化较慢,可从每日或每小时条件检查开始;中转促销和卡网库存变化更快,但也要受 robots、页面负载和来源稳定性约束。基础频率来自历史变更间隔,不来自“越实时越好”的口号。
调度记录应包含 source_kind、base_interval、min_interval、max_interval、last_changed_at、last_success_at 和 next_run_at。新来源先用保守频率观察,积累变化数据后再调整。
- 官方、聚合与原店分层调度
- 新来源从低频开始
- 频率变化记录原因
本节参考:RFC 9110 HTTP SemanticsRFC 6585 Additional HTTP Status Codes
让成功与变化共同反馈
连续多轮 304 或业务指纹不变时,可以逐步拉长间隔;检测到真实价格变化时短期缩短间隔,确认页面稳定后再恢复。随机抖动可避免大量域名在整点同时请求。
自适应算法必须有上下限,不能因为促销连续变化而无限加速。对于同一域名的多个 URL,使用域名级令牌桶控制总并发,任务优先级在桶内排序。
- 未变化逐步降频
- 真实变更短期加密
- 域名级令牌桶限流
本节参考:RFC 6585 Additional HTTP Status CodesGoogle Search Central 关于 sitemap lastmod
HTTP 反馈覆盖调度计划
429 出现时遵循 Retry-After;503 携带 Retry-After 时也按服务端建议等待。无明确时间则使用带抖动的指数退避,并设置熔断阈值,避免每个失败任务各自重试造成放大。
robots 规则变化、重定向到新域名、挑战页和登录墙都应暂停正常计划,进入人工核验。调度器的目标是获得可靠证据,不是维持固定请求次数。
- Retry-After 优先
- 失败退避带抖动
- 身份或规则变化触发熔断
本节参考:Google Search Central 关于 sitemap lastmodRFC 9110 HTTP Semantics
抓取频率与前台新鲜度分开
前台 freshness 取决于最后一次成功业务核验,而不是最后一次任务启动。Google 对 sitemap lastmod 的说明也强调时间应对应重大变化并持续真实;同理,AI 价格页不能每次技术检查都改成“刚刚更新”。
风险边界包括来源长期不变、缓存返回旧页和调度成功但解析失败。本文协议证据核验于 2026-08-29,具体频率没有通用答案;页面应公布 last_verified_at、TTL 和陈旧原因。
- 任务时间不等于价格更新时间
- 解析失败不刷新新鲜度
- 过期原因对读者可见
本节参考:RFC 9110 HTTP SemanticsRFC 6585 Additional HTTP Status Codes
参考来源
价格、规则和产品状态可能变化,可通过这些原始页面确认当前信息。
RFC 6585 Additional HTTP Status Codes
Google Search Central 关于 sitemap lastmod
常见问题
官方大模型价格页多久抓一次合适?
从低频条件检查开始,根据历史变更率和业务需要调整;没有证据支持时,不应默认分钟级抓取。
收到 429 后可以切换节点继续抓取吗?
调度器应尊重来源的限流反馈和 Retry-After,降低域名级频率;切换节点会掩盖负载并破坏证据可信度。
