蜘蛛人

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

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

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

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

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

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

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

摘要： 项目一开始，搜索数据是「各业务各自调 API」：排名功能发一次请求、报表功能发一次、AI 接地又发一次。每个地方都要管 API key、重试、失败处理，谁改了参数别人都不知道。这篇记录我怎么把这些散落调用收拢成一个内部数据服务——统一入口、统一鉴权、统一限流，业务方只调一个接口。 先看问题：散落调用 阅读全文

摘要： 后台接搜索数据接口，第一反应是「怎么把请求发出去」。但跑一段时间你会发现，真正决定体验的是「怎么少发请求」——同一批关键词今天查完明天还查，中间没变化，重复请求就是纯浪费。这篇记录我给 SERP 采集任务加缓存层的完整过程：缓存键怎么设计、TTL 怎么定、怎么和接口的计费机制配合。 为什么需要缓存 阅读全文

摘要： 后台接第三方搜索数据接口这件事，写通一条请求很容易，难的是让它稳定地、按计划地、批量地跑起来，还不烧冤枉钱。这篇记录我把一个「每天批量查几百个关键词」的采集任务做成工程化的过程：调度、批量、去重、失败恢复、成本控制，几个要点一次讲清。 先定位：这篇解决什么问题 输入：一个关键词清单（几百到几千个） 阅读全文