蜘蛛人

摘要： 采集服务隔三差五报「连接池耗尽」，重启能恢复，两天后又犯。运维的第一反应是「把 max 调大」——这正是连接池最常见的误区。这篇记录一次完整排查：先算账、再定位、最后才调参。 错误现场 报错很直白： TimeoutError: connection pool exhausted (timeout=3 阅读全文

摘要： 一张报表页从 800ms 涨到 23 秒，运营开始抱怨「点开就转圈」。第一反应是数据涨太快——一年涨了三十倍，确实该慢了。但把查询拉出来一看，三十倍的数据量解释不了三十倍的延迟：真正的问题是查询写法，数据量只是把问题放大了。 这篇按当时的排查顺序记录：怎么定位、发现问题、怎么改、怎么验证。 第一步： 阅读全文

摘要： 服务跑了三天，容器 RSS 从 300MB 涨到 2.4GB，最后被 OOM Killer 干掉。运维的标准动作是「重启一下就好了」——重启确实能撑三天，但根因没人知道。这种「重启续命」的习惯，迟早会在某次流量高峰翻车。这篇记录一次完整的排查过程：怎么确认是真泄漏、怎么用工具定位、真凶长什么样。 第 阅读全文

摘要： 上个月排查外部调用成本时，我抓了一段线上调用日志做聚合分析。业务系统每分钟都在向搜索接口发起成百上千次查询，乍看全是不同业务线在拉取市场数据。但把入参拎出来一比对，我直接气笑了： // 实例 A 传的参数 {"q": " wireless mouse ", "gl": "US", "hl": "en 阅读全文

摘要： 每年来问「SERP API 怎么选」的分两种人：预算敏感的个人开发者，和要过采购流程的团队。前者纠结价格，后者纠结 SLA。三条路线我都完整走过一遍——按量付费、订阅制、自建爬虫——这篇把结论和数据摊开讲。 三条路线先看全景 维度 按量付费 订阅制 自建爬虫 代表形态 按次计费的数据 API 传统 阅读全文

摘要： 采集中途没额度，是最贵的一种失败：任务跑了一半，数据缺一块，重跑又要从头开始，告警在半夜响。后来我给管道加了「预算感知调度」——任务前查余额、按类型预留额度、余额不足时降级执行。这篇讲这三层的设计。 第一层：准入——不启动，比跑一半便宜 任务启动前，先估算本次需要多少 credits，和余额比： # 阅读全文

摘要： 以前管道里全是 1-credit 的搜索端点，「控并发」基本等于「控 QPS」，一个令牌桶就完事。后来 catalog 扩到 39 个端点、6 个大类，价格从 1 到 3 credits 不等——地图详情一次 3 credits，是搜索的三倍。这时冒出一个问题：并发数控制得住请求数，控制不住成本。 阅读全文

摘要： 上周二早上 7:10，排名日报的告警把我吵醒。500 个关键词的采集任务，跑了 3 分钟，整体失败退出，只留下一行 traceback。这篇文章是事故复盘：现象、排查、根因、修复、以及我加进代码里的四条规矩。 现象 任务是每天早上的排名巡检，跑了大半年一直稳。那天日志里出现： Traceback ( 阅读全文

摘要： 「脚本太慢了」是采集项目最常见的抱怨，但相当多的「优化」都优化错了方向：有人在优化 JSON 解析，实际瓶颈是每条记录 commit 一次；有人在调正则，实际时间全花在等接口响应上。慢分两种——「在等」和「在算」，先分清，再动手。 这篇用两个剖析工具（cProfile + py-spy）把一次批量采 阅读全文

摘要： 上周凌晨三点，我被报警短信叫醒。监控显示搜索数据采集集群的 32 个 worker 进程全部被挂死，CPU 占用无限接近零，内存却死死卡在高位，待处理队列堆积了三万多个关键词。 排查日志才发现，凌晨骨干网有一段长达 8 分钟的偶发丢包。我们的抓取脚本里只写了老套的 retry(times=3)。当上 阅读全文