蜘蛛人

摘要： 采集数据有个特殊之处：它是一次性的时间序列——昨天的 SERP 今天已经不存在了。所以当「解析逻辑升级」「发现字段解析有 bug」「供应商结构变了」时，你无法重新采集历史，只能「重放」：用当初保存的原始响应，重新跑一遍处理逻辑。这篇讲数据重放的工程实践——它的前提、流程和成本。 什么时候需要重放 三 阅读全文

摘要： 「这个接口能扛多少并发？延迟多少？最优参数是什么？」——这些问题应该在采集系统上线前用基准测试回答，而不是上线后靠事故发现。这篇记录我给搜索数据接口（SerpBase，serpbase.dev）做性能基准测试的实践：测什么、怎么测、结果怎么用。 为什么需要基准测试 搜索数据采集的性能瓶颈在「接口的 阅读全文

摘要： 采集数据最大的风险不是「没采到」，而是「采到了但数据是坏的」——字段空了、类型错了、值域异常，下游分析直接崩。这篇记录我给采集数据加「校验与质量门禁」的实践：校验什么、什么时候校验、不合格怎么办，让坏数据在入口就被拦住。 为什么需要数据校验 搜索数据接口的返回是「活的」——可选字段、结构变化、谷歌布 阅读全文

摘要： 采集系统最怕的三个字：跑重了。任务重复执行，要么数据重复、要么重复扣费、要么状态错乱。幂等（idempotency）就是解决「同一件事执行多少次，结果都一样」的工程手段。这篇把采集任务幂等设计讲透：幂等键、去重表、状态机、重试幂等，一套完整方案。 为什么采集任务必须有幂等 采集场景天然容易「跑重」： 阅读全文

摘要： 采集搜索数据，数据量不大时「存哪都行」，但一进入「每天采集、要查趋势、要回溯、要审计」的状态，存储就成了架构问题。这篇记录我的存储选型过程：从 SQLite 起步，到分库/分层的完整方案，以及 schema 设计和增长管理。 搜索数据的存储特点 先认清搜索数据的数据特征： 写多读少：每次采集大量写入 阅读全文

摘要： 批量采集搜索数据，「并发」是个绕不开的话题：不开并发太慢，开了并发容易触发限流、把上游打挂、自己还崩。这篇记录我怎么从「一把梭全开」进化到「可控并发」的工程实践：并发模型、信号量、滑动限流、背压、超时管理，一套完整做法。 为什么「并发越大越快」是错觉 对搜索数据采集，并发和吞吐不是线性关系： 并发 阅读全文

摘要： 采集代码写完了，很多人的日志是「print 几行 + 一个 log 文件」。直到某天要对账、要排查、要回溯，才发现日志啥都不够用——没有 request_id、没有关键指标、格式对不上。这篇记录我给采集系统搭结构化日志的完整过程：记什么、怎么记、怎么查、怎么和排查/对账配合。 为什么采集日志要「结构 阅读全文

摘要： 采集系统的噩梦之一：依赖的第三方接口改了返回结构。要么字段改名，要么模块消失，要么必选变可选。慌不慌？如果提前做了迁移准备，这只是个「走流程」的活。这篇记录我怎么把「供应商结构变更」从事故变成常规工程：迁移策略、兼容期、双写验证、回滚。 先认清：结构变更挡不住 搜索数据接口的返回结构是「活文档」—— 阅读全文

摘要： 采集搜索数据，一个朴素但容易被忽略的问题：数据是「按天全量重采」还是「只采变化的部分」？ 全量简单，但同一个关键词天天采，大部分结果没变——白花的 credits 和存储越来越多。这篇记录我怎么从全量切到增量采集，以及「版本化」是怎么解决「变化检测」问题的。 先算一笔账：全量为什么贵 假设 100 阅读全文

摘要： 很多人觉得采集代码「调接口 + 解析 JSON，跑起来就行，不用测试」。直到有一天字段解析挂掉、重试逻辑把请求打爆、或供应商改了返回结构——你才发现这些代码是真·生产代码，值得认真测。这篇记录我给搜索数据采集写测试的实践：mock 外部 API、管理 fixtures、测重试逻辑、应对字段变更。 为 阅读全文